 So, hi everybody. It's, you know, 245, so we should get rolling. Welcome to be a developer experience super hero, robust dev scripts for peace and joy. Joy, happiness, you know, fill in your adjective. I'm Dustin, Dustin the Blanc. I work at Pantheon as a customer success engineer. Oh, and actually before I start, I forgot Amanda reminded me. If anybody has an empty seat next to them, you want to raise your hand. Anybody who's waiting to come in, if there's anybody out there, we've got some empty seats. So feel free to come on in, sit on down, and yeah, have fun. Anywho, moving on, yeah, I made it so all my accounts are easy to remember. It's just my name. So find me on Twitter, GitHub, LinkedIn, Drupal.org. I'm other places too, but those are the ones you probably care about. That's my email in case you want to send me email. So we know who I am. Who are you? Who, who, who, who. Yeah, I, when I'm thinking about this conversation, there's a certain subset of people who immediately come to mind. And to me, it's mostly applicable to, you know, agency CTOs and leads, or you know, if you're an internal team at a company that's not a digital agency, you know, somebody who's leading the team, someone who's taken responsibility for the processes your team uses. So it could be lead developer on a particular project, or even people who that's not your job title, but you know, your team needs some leadership. They need someone to say how to get things done, how it should be done. Maybe that's you. Maybe you don't have any official title, but you know, so that's who I'm thinking of when I talk about these topics. It's applicable to other people, but that's the concept in my head. So why would you want to care about developer experience? Because we're not just building websites. We're building teams. We're, we're, we're, whether you're at an agency or like I said, you've got an internal team or you're, you're the developer of one. I know everybody's out there, you know. You're, you're building processes for building websites so that you can have a great organization so that you can build a great business, not just the sites. When you think about just the sites, it becomes very easy to just get things done, to skip all the stuff that doesn't go into just getting it done, make it as cheap as possible, as fast as possible. And when we find those bugs later, you know, then they can pay us more to fix them, right? So we're building teams. So we want to think about the experience of what it's like to be a developer on your team rather than just what sites you end up building. And developers have some of the highest job mobility in the marketplace. This is from Stack Overflow's recent developer survey from 2017. If you can't read that real well, the summary is 75% of developers are either actively looking for new positions or if one just so happens to drop into their lap, you all know the recruiters on LinkedIn, they're everywhere. But people are listening. Your dev shop should be the place that they want to be. That experience that you're providing should be the best it can be, not just the end products you're building. So what do developers want? And I mean, you guys know, or at least most of you, how many people here are actually you are a developer. You write code, you build sites. Yeah, most of you. And so you kind of know all of this already. But some of the top things, Glassdoor did a survey in 2014. And this is a picture I could find, so it was the easiest way to summarize the data. But if you look at those top four categories, I think that some of the stuff I'm talking about today goes directly to those categories. We're talking about compensation, career growth opportunities, the type of work people are doing, and the company culture. So Westime spent on manual testing. Yeah, we want to be automating that testing. Workstation configuration and project setup. Setting up the individual project. This one uses PhantomJS. This one uses Selenium. This one uses PHP 4.7. I don't know, whatever. All that stuff eats up time. And every time you onboard a new developer, they have to go through that crap every single time. And if they're not doing that, they can spend more time on billable work. Everybody likes to get paid, and you can't pay developers well if you're not making money in the first place. Fancy pants, fun stuff. That's the, oh, check out my automated super cool testing with my CircleCI and all my integration testing. And I made a new module because I have all this time that I'm not spending on doing repetitive stuff that everybody has to do anyway. And open source contribution. We were using Drupal. I love the concept of getting to contribute to Drupal, but I have a day job. And that day job takes up an awful lot of time doing things. So the more time I can make to contribute back to the community, the better. It's very hard to fit in sometimes for many of us. So when you're automating things and you're getting out of your team's way, they can contribute back to Drupal in a much bigger way. And building better organizations, of course. So, you know, they can contribute to making sure that your dev shop or team, whatever you're doing, is the best that's out there. So it means you can pay them more. You should anyhow. Maybe you don't. But if you're making more money, that's where it should go. You can bug them about making money less. Who's ever stood in a stand-up meeting where the only point was how much money did you make the shop yesterday? I know I have. And it was the most irritating thing that I think I did throughout my week doing that. So, yeah. Okay, hopefully I've sold you that it's important to at least consider. So let's talk about how you do these things. So I think of three main components of really making this come together. There's a lot more that you can do, but this is kind of what comes to mind for me. So minimal local dependencies and making them cross-platform, if you can. Not always possible. But, you know, most of us using Mac or Linux, that's just the fact of reality. But I cannot say the amount of people who stopped by the booth in the past couple days who are Windows developers that I would have never expected it, but it's growing. So, you know, you don't want to have to dictate what your developers are using. Let them use what they're most comfortable with. Automated tests, builds, and deployments. Those steps really don't change every time it needs to happen. Don't make a human do it. It's boring. They're supposed to be doing something creative. And a third part of it is accessible, reliable, and reusable scripts, which I think there are some things you can do to make scripting for your project set up accessible to your entire team so that they can contribute to it and so that they can actually read them and understand what's going on. So the first part of that, local dependencies. And the example that I'm using, the only thing that you need is Composer, which is arguable. You don't necessarily need to have Composer installed on your system if you're using Docker and Docker Compose. I'm using Composer as an actual dependency so people can use Composer to script Docker Compose commands. It's kind of this Turducken thing that you get going on where, you know, you've got your PHP globally calling Docker, calling PHP inside the container. You could probably then again put Docker inside that or something. But the way I'm setting it up, boom Composer, then Docker Compose. I noticed when I was putting this together, it's like, we've got a lot of music love going on with our DevTools here. But yeah, so they shouldn't need anything more than this. You shouldn't need to care what PHP version your developer or a themeer or designer or anybody is running on their local system. It should be declarative as part of the project. You know what it's going to be in production, so why don't you tell them what it's going to be in development? Okay, so dependable, testable, repeatable builds. So QA is still regression testing and setting up CI integration and all that stuff. It's easier now than it ever has been and it's getting easier every year. Manual testing hasn't gotten any easier. You still have to click through the same stuff over and over and over again to test your application manually. But setting up can still be a pain, especially since there are so many ways to skin that cat. You have to pick what works for your team. This is the first time I tried to set up automated testing on a Drupal site myself before consulting with anybody else who's smarter than me. You can see the first passing build was number 74. That was not fun doing that. So, you know, it's not always easy, but the good news is it's getting easier. So I work at Pantheon and one of the things we're really excited about is some work that Greg Anderson and Steve Perche and some of our team members have worked on lately called the Terminus Build Tools plugin. So, hopefully you guys know a bit about Pantheon and how awesome it is to spin up new sites, like, you know, it's a business all day long every day. This is a Terminus extension that works on your local system. You provide it a GitHub API token. You provide it a CircleCI API token and an upstream name. And it spins up your site, your repo, your CircleCI instance. It has some basic B-hat tests that are part of our scaffolded repository. Of course, the real magic happens when you take that repository, put your team's specific build process into that, use this kind of tool to spin up new sites, boom. You have testing. You have all of that set up out of the box. So you can get it at that URL. If you have any questions, come talk to me later and I can show you the link. And there's an example at the bottom of running the build step to just create, boom, all that stuff instantly. So this is afterwards. In this particular case, there's still an alpha testing, so some weird stuff happened. The first build failed, but by build two, you know, that's a lot faster than build number 74. So things are getting better. And we encourage everybody to contribute to keep making it better. Best practices are emerging in the community. We picked the horse of CircleCI, GitHub, and Behat because that's the most common. I've also had experience with Codeception, which is great automated test framework. So there's other options, but this way you kind of have something rolling right out of the gate. So what do you want to do in CI? There's some really obvious stuff, like building your assets, compiling your SAS. Most people are using SAS less, stylus something these days, or some JavaScript compiler. So don't bother with committing that to your source repository, it belongs in production. You need to see it while you're developing, but no one needs to see your compiled CSS on your GitHub repository. It's not important. And patches, if anybody's ever used the composer patching library, you can do that automated so that those patches get reapplied every time it builds on the CI server, and you don't have to remember to do it every time you update Drupal Core. And yeah, checking your code style, you can do scrutinizer or symphony. They have a tool, I can't remember what it's called at this point, but a code style checking tool. You can have code coverage run, code complexity stuff run while it's running in CI. That way, you as lead developer don't have to have it out with your developers every time their code doesn't pass CI. A computer can tell them to go fix it. And it's very simple. It's very declarative, everyone knows that you need to follow Drupal coding standards, so on and so forth. So you can have all that done in CI. Yeah, and a couple more things. My favorite is especially the last one. Everything that you need to do before you're going to ship your project that you can't remember to do when you do it manually. So the third component, kind of the last thing and the thing that I get excited about is what scripting really should be for developers. It should be easy to contribute, easy to understand, and easy to extend. I know early in my career developing, we would have one guy on the team who was a Ruby developer and he wrote a bunch of stuff in Ruby because who doesn't like writing in Ruby, it's fun. We had some other guys who really hardcore knew their bash and would write some really complex bash scripts. And then there was me who was the new guy who was happy that I knew some PHP so that I could contribute to our back-end Drupal development. And I think the one thing that you can say about pretty much every shop is you have people who know PHP. They may not know bash scripting, they may not know Ruby, they may not know JavaScript all that well, but everybody's going to know some PHP. So here's a good example of sort of the first type of thing that sort of blew my mind as I started Devscripts. This is an example of everyone knows you're working on your local machine, you've got some content changes the client's doing in the live site and you need to get them down. Drush SQL sync to the rescue, we all love it and maybe there's some other things that you need to do though, maybe you need to disable some modules, maybe you need to enable some development modules, maybe you need to sanitize the database. So this was just a good quick example and it's just PHP. You can write it in PHP storm and get all your nice syntax highlighting and all your IntelliCode completion magic. It's great, at least in my opinion. So Robo, which is what we just showed here, it's actually what I'm using to create this, it's sort of like the grunt or rake or gulp of PHP for modern PHP projects. It allows you to have a single file and it just spits out symphony console commands. So if you've used symphony console, you've used Drupal console, it's very familiar. And this is, you know, a snippet of what one of the Robo files looked like. It's a single class, every public method is a script that you can run. Then you can have your private methods so that when you have something repeated that every one of them needs to use that private method with your variables and all that good stuff. So people who are writing Drupal code, this is very simple to them. There's no context switching, they only really have to pay attention to the one language that they know very well. Most of us know some JavaScript too hopefully if we write code but PHP is what Drupal's written in so don't make people context switch to something else. Some other cool things you can do is you can call Drupal's API from your dev scripts. You can't really do that from bash. You may not really need to ever but it's certainly cool that you can for automated tests and things like that. Not using, you wouldn't usually do it within Robo but in the concept of using PHP to write your scripts you can directly create users in your database using Drupal's methods for doing so and things like that. So this is the example project that I created. Talking about these concepts is a very minimal it was spun up with the build tools plugin that I showed earlier and then after that I added some Robo scripts to it using Docker compose for local development to basically get you to, well ultimately I think the experience should be for every developer on your team when you onboard that new person five commands and that includes clone seeding into the directory composer install all that stuff, all fits on one screen when you pass the quiet flag so you don't see all the other stuff but yeah that developer has cloned that repository they've built their local development environment and they've passed the acceptance test and they're ready to commit code there wasn't two days of onboarding none of that I think that's the experience that every developer on every team should be having when they want to contribute to your project that's kind of what I'm arguing for that's the end state make it easy for people to contribute to your projects, make it hard for them to do something that you don't want them to do we have the tools to do this it does take time to do it but I think that as a lead developer or someone who's responsible for the practices of your organization that's on us so that's the end of what I think we should be striving for and some helpful tools especially if you're developing on Pantheon and you don't know how to do your own Docker compose setup stuff and you're not there yet and you just want some really basic local the main thing that everyone needs for local development Calbox is great it's Docker and a really great UI and super awesome if you're using Pantheon they also support other projects you can run non Pantheon Drupal sites, you can run WordPress they have a whole plugin system for if you were you want to spin up a Laravel app doesn't matter you can do it with that tool so it's really great I recommend it highly what I used for setting up the example repository is something called Docker for Drupal the guys at Wadby have made it's super awesome the stack that they end up with with the default the default compose file that they have is very similar again to what Calbox and what Pantheon would do a lot of the same services Varnish Redis they even have like Memcache available all that stuff so that's another great tool if you're really looking into doing the straight up get your Docker compose setup which is really useful if you're doing things like for instance in my example I have a PhantomJS container to run our JavaScript tests if we have them so rather than making your developer install PhantomJS on their machine just give them a container configure it how you want it and they're never going to come to you and say my PhantomJS version is wrong so all the tests fail or their node version I have the wrong version of these node packages I can't compile SAS the same way you guys do never again hopefully and if you know the container stuff is like not your thing Drupal VM is great for doing the exact same thing with Vagrant and it's very popular in the community and it serves a lot of the same purposes for local development just a different approach so don't forget their sprints on Friday so if you're around go do them help improve Drupal core help work on a contribute project or something show up if you're going to be here and dig in and help out you don't have to be experienced you don't have to be new you can be anybody so if you have any feedback make sure to go check out the session on the conference website and let me know how much I ramble and all that stuff so I thank you guys very much for being here and giving me your attention for my presentation this is my first Drupal Con first presentation it was a lot of fun and if anybody has any questions feel free to ask them now thank you it wasn't clear when you were talking about keeping in already compiled CSS in your production code or I'm sorry I missed that what was that again you mentioned which was kind of unclear you said that you should not keep already compiled or CSS code in your production repository or you should so in production so in your production artifact which in the case of Pantheon for instance that's the Git repository that lives on Pantheon that should have all of your composer vendor code it needs to in order to run production it should have all of your compiled SaaS what doesn't need those things is your GitHub or Bitbucket source code repository I mean it's not the end of the world for you to put those compiled resources but they're not necessary if you have a good CI pipeline so you'll end up with things like doing code reviews on GitHub where not only do you have the SaaS that your front-end developer is submitting this pull request to review but you also see all the compiled CSS there's no reason for you to have to look at that there's no need for that to be downloaded when you download the repository for GitHub yeah it's not the end of the world the shop I worked at before I came to Pantheon that was our life because we hadn't built CI infrastructure yet so that's just how things worked it's not the end of the world you can still get a lot of benefit from a lot of this stuff if you don't even use a CI server it's just you know while you've got it you might as well compile your SaaS and make that experience of managing that source repository that much better for the people who are contributing no problem yeah yeah yeah yeah I've personally using it I've updated several times and I've kind of like my version of what they do like they're using traffic now in front of the containers and I don't bother I just expose the ports it's a it's like a sort of a DNS proxy kind of thing yeah so it sits in front of your containers and can assign them host names and stuff which you could do DNS masks similarly if you wanted to you know I don't have the local host but what I do is I've gotten so used as local host port 8000 runs my dev site local host port 8100 runs the test instance which is another thing in this setup you have two separate sites on your local machine and because you're just spinning up containers it's super fast to spin up a whole set of dev containers a whole set of test containers and when you execute your test suite it bootstraps the test site so you can keep working on your dev site that's the way I like to do it but again it's all personal preference yeah glad you like it you're welcome anybody else any questions doxel yes doxel it's called I haven't seen it yet is it something very similar awesome very cool it is so if you're using a Mac it's a project called docker sync I think that's what it's called docker sync.io it's a ruby gym and it basically what it does is it uses NFS or unison or rsync to share your code directory because especially with symphony based projects what you end up with is a massive dependency or massive like vendor folder with a bunch of files and the problem is that the docker defaults driver they call it doesn't work well with massively populated directory so that's what slows it down and if you check out docker for drupal they've already integrated it but it's a lot faster on linux that's for sure