 All right, go ahead and get started. I said the slides are here. Here to talk about the benefits of continuous integration. My name's Andrew Taylor, A-Taylor-ME on GitHub and Twitter, so links to the slides are on Twitter. If you wanna grab them there, it's a lot easier than trying to type in this crazy Google Shortener URL which are apparently going away now, so. Andrew at pantheon.io, I'm gonna try and leave some time for questions at the end, but if not, shoot me an email or come find me at the booth later on. So I wanna start with just this high level sort of what is continuous integration and maybe talk about some misconceptions and some things. So continuous integration to me is really just thinking about what pieces of your workflow can you automate? Can you take from doing manually and bundle those into a lot of CI services live on the cloud, they can run with every pull request or run once an hour or whatever you wanna set that up, but I like to take CI and not in that very narrow view where I'm just going to install composer dependencies on every code pitch. While you can certainly do that, we wanna expand it and think about all of the things in our workflow that we can automate. So it's really about what sort of value are you going to get out of continuous integration, so why would you wanna do this? And it's really taking a step back and looking at CI as a state of mind. So going in and thinking about certain problems in different ways and taking a different perspective about what sorts of things are we doing now that we can automate? And it doesn't have to be an immediate process. This could be things where you were manually going in and clicking buttons and doing things on a command line or sorry, doing things in a dashboard in a UI that now you're doing in the command line. That could be the first step towards this path down continuous integration. It's not taking this plunge into full automation immediately. There's lots of small steps along the way. So we just had a great talk on looking at code sniffing and these sorts of static analysis things. So here's PHP code sniffer. We kinda saw the live demo in the talk before is going to check your code for errors and then show you sort of what's wrong. But if we zoom in at the bottom here, it says that this complimentary tool to the code sniffer, code beautifier can fix these two marked things automatically. Okay, so normally if we're using something like this, we'll go in, we could run this tool locally, we get these notifications and before we push to GitHub or wherever, then we're gonna go in and say, I need to fix these five things that are listed here. I need to go fix these errors. I can run the beautifier and it will fix two of them automatically, but I need to clean up the other three. Well, what if instead of having to have a developer run this tool and check every commit? We're busy, we're doing things. Instead of making your team do this every time, we can offload that and that's where continuous integration comes into play. So it's automating this process, maybe moving it to the clouds. When you make that commit on GitHub, then we now have a script that's going to run, run these checks and we can mark the pull request and say thumbs up, thumbs down if this has these errors or not, but we could go a step further. So looking at it can automatically fix two things. So what if not only did it tell us that these are wrong, but then we ran the beautifier and it fixed the two items that this tool can already fix automatically. That's two less items that we have to go in and fix ourselves, right? It's taking these things that are repetitive tasks that we might be doing in part of our daily process or if you're not on the technical side, if you're on the business side, maybe this is something that your team is doing, finding where those pain points are, those kind of repetitive tasks and offloading those. So it's like what happens after a code change? What happens after commit? What are all of these things? And so it's keeping that state of mind and approaching ideas because we want our developers to take their brain power and do critical tasks and do deeper thinking and not do these redundant tasks, right? Compiling CSS into a minified thing, it might be a quick, easy step. I'm just gonna open my terminal and run this command or I'm gonna have some application open that's gonna do it for me. It might seem like a trivial thing, but we only have so much brain power in the day. So if you're sitting there spending it on, I have to remember to do these 10 things after every code change or I have to remember to do this before every commit or every deploy, all those sorts of things add up. So it's really taking that stuff that we're doing and unburdening ourselves and automating that process. So some items that you can use with CI, we can install dependencies. Drupal 8 is very composer heavy. I'd use composer elsewhere, but not with Drupal and then I went to install address module and it was like, you can't, right? I can't just go in and use Drush and install it. You have to do some of these things with composer. And that might be all right for a more experienced person, but what happens if you're onboarding a junior developer who's never touched composer? What happens if someone's out sick and you gotta pull somebody else into this project and they're not experienced with these tools rather than having this big burden for them to overcome in this giant learning curve just to get into your workflow if you have these steps automated and all they have to do is update their code and push and this next step is going to happen automatically. That's one less thing for you to worry about that you know how to do it, but it's one less thing for everybody else to worry about and it takes that barrier to entry from getting involved in your projects and lowers that so that other people can get involved. We can also build source files. Compiling CSS, minifying assets. Maybe you're working with React or things like that. You wanna take your JSX and you need to run Babel and all those things. And things that aren't code related necessarily like deployments. So maybe I have this nice process where my composer dependencies get installed, all of my assets get minified, all that's happening automatically, but I still have to open a ticket for IT to spin up a server. Or I still have to go in and log into my hosting provider and click some buttons and wait a few minutes for a new environment to be provisioned and then FTP my code up. These are the sorts of things that we can take this entire pipeline and automate it. And so it's keeping that state of mind to think about what are areas in your workflow that you can offload. Communication, a lot of the tools we use and so not just thinking about your development workflow, but think about other folks on the team, some things you might be doing. So if you have project managers that need to know when your developers have shipped code, if you primarily communicate in Slack, well guess what, Slack has an API. Every time you deploy code, you can go in and call the Slack API and just have a running channel for every project. I've actually seen this be done in a really, really efficient way where every time code was pushed to the production server, we looked at the get commit logs, the messages that went along with that code, parsed through it, and if there's a JIRA ticket number, call back to the JIRA API and close the ticket because it's now in production. So that's something that your project managers don't have to go hunt down developers and ask them, hey, did you ship this thing? Is this done? Can I close it? It's already done. The developers don't have to worry about, oh, I have to log in here because they've shipped this and they're already moving on to the next task. They don't have this additional overhead of all the things I have to do after I ship the code. So it can help everybody on the team. This isn't just for developers. This is really about taking those items that are weighing down your team and unloading them so they can be more productive with their time. Testing in QA is right along that process. So we looked at kind of the code sniffing, but there's all sorts of tools we'll take a look at. You can do B-hat testing. So if we have a contact form or a donation form or those business critical parts of our site, then let's run a test and make sure that every code change we introduce is going to not break these items. And that might be QA that people are doing manually. That's a giant pain. What if we have to go in and change configuration because we want to test a shopping cart and if we have our live stripe info in there and people make mistakes, might not forget to change that configuration before you test something. Now we've actually done some actual billing or created a real order. When you take advantage of continuous integration, you can offload this to the cloud and you can automate those steps so that we can go in and say, okay, let's import dummy config and then test this and then put our old config back, right? So that configuration import right in there along with that. And so raise a hand. Has anyone forgotten to run update.php after you do a deployment? Like ever, right, that's a thing. We're all human. We're not perfect. And so when you have this big list, it's just going in and taking those items so you don't have to think about it and making sure it happens every time. And I like to tell people that this isn't, you're not gonna go from zero to full automation. This is a process and a nice way to start with this process is I bet a lot of people in the room have some documentation or even if it's just in your head, some idea of the things you need to do, start with writing them down, find the most painful one and it can be something as small as pinging update.php after every deploy and automate that one thing and that starts you down this path, right? And that's something that the continuous integration can help with because it can, you know, these services, I'm gonna show CircleCI, there's Jenkins and Travis and all these. Pick what everyone's best for you. It could even be a deployment script you write and you share with everyone on your team so that every deployment it, you know, SSH is in, does the deployment, runs update, like all these steps. So CI doesn't have to necessarily be moving things in the cloud in this grand fashion. It can be something as simple as writing down your steps and automating one piece. If you do wanna go for the big shebang and move everything to the cloud, this is kind of the process that I've tuned that works well for me and a lot of the agencies I've worked with. So we have some version control system. This is where custom code lives, especially with Drupal 8 and Composer. So we have our composer, Jason, and all of our vendor is not in this repository. Drupal Core is not there. All the contrib modules, everything we're pulling in, the only thing that's there is our custom code. So maybe some modules we've written, some theming, things like that. Every time you make a code change, then our continuous integration server chimes in, it downloads all the dependencies, it compiles CSS, turns that into production code, and then spins up an environment and ships that code. And once it's deployed out, then it can go in, the CI server can pick back up and it can run some of this testing, right? We can go in and make sure, even before our staging environment spun up, we could have run this code testing and stop the process that far if our code tests don't pass. We could do the automated testing. We talked about testing contact forms or donation forms or whatever. Reporting and analytics, so this was like going back in and notifying slack or jeer of what's going on, so kind of taking your entire workflow and offloading it. And so that's kind of what a complete picture looks like, but there's lots of little steps along the way. And now I wanna dive into kind of what the title of the talk was, the benefits. So these are things that I've seen working with agencies adopting automation and adopting automation myself, some of the things that come out of this. So you get that consistency for getting to run update.php is not a thing that happens when the robots do it every single time. We get that nice consistency. So here's just an example of a CircleCI configuration file. Like I said, there's tons of other tools out there, but basically you just list out, like I have a script to do building the site or deploying or testing or whatever. You just list the order. You can list dependencies. So I can say in order to test my contact form, the code needs to be deployed. That's the first step, that's a requirement. And so you can set up these workflows. This is what kind of that looks like visually within the interface. And so every time I push code, all of these steps happen. And if we come in and look in here, each of these has a timer. And the total time is not that much. This is like five minutes for the full run. But if it was me doing it manually, this would take about 15 minutes because I'd have to be like, oh, I need to open up my terminal and run this and fix these things and check for this and analyze the results. And that's all something that is wasted time and brainpower for me that I've now offloaded. And this is what it looks like if it fails. So we had one step here, kind of in the middle fail that had to happen before the others. So our build fails, we get notified of that and all of these other tests don't even run. We mitigate risk because we're running this in an automated fashion. There's less room for error within our workflow, within our pipelines, and within our code we can check for errors earlier. So if you're doing that code sniffing, if you're testing that form on every single commit, that really ups your level of, that increases your level of confidence as well, which we're gonna talk about, but mitigating that risk because we have this full coverage and I don't know, this might just be me, but as a developer, I can be lazy. So going in and if it's some QA, like we're supposed to test this full shopping cart process, I just changed a menu item. That's not gonna affect the cart, right? Maybe I'm just gonna not test that this time. Well, when you automate these things, you mitigate that risk because it's gonna be tested every time and I don't have to worry about it. So that's some risk that was introduced because you weren't previously testing it. Now you've lowered that barrier of entry to doing all of these things that they can happen more frequently. So this is just a screenshot of CircleCI downloading dependencies. Here is like installing assets and compiling things with Gulp, kind of a task runner set up here. And this is a Lighthouse report. I don't know if you guys have seen this. It's in Chrome developer tools now. Lighthouse is pretty cool. It also has an NPM package. You can run it on the command line. So we can come in and audit performance. So we can come in and say, hey, if this new code change decreases performance by a certain threshold, then let's not allow this change and we can go back and refactor and catch those things earlier in our process. Confidence, we talked about that a little bit. If we come in and look and I see here a test has failed, this, why am I talking about this with confidence? Well, it's still automated testing and adopting this continuous integration ups my confidence that I'm not shipping bugs because we have test coverage and it's running every single time. I'm confident that I'm gonna catch things and when all the lights are green, then I'm confident that I'm shipping quality code that I'm not introducing a bug. Members of my team are confident, the project managers can go in and they're confident that when they tell a client something is done, it's actually done and it's not broken and they're not gonna get a phone call later on. And this can show up right in GitHub or Bitbucket or wherever you're working. We can have all of these green check boxes and especially if you're transparent with your clients, if they're coming in and they're watching a repository, seeing what you're doing, maybe you're introducing this pull request on something they own and you've set up this sort of testing and all the lights are green, it's gonna give them confidence that you're doing quality work. It's coming in and saying like, oh, trust us, our code is good. They can actually go in and look at the test and know that the code is good. We have communication as well, so we talked earlier, this is a screenshot of kind of the running Slack message. So we come in and see that these tests are running and I can see like red and green, pass or fail. I have little buttons in here that if one fails, I can click on it and actually go view the full report, those sorts of things. So you can set this up so that if something fails, then members of your team get notified. If it's a general test, maybe a project manager gets notified and they can go in and look at that and kind of keep tabs on the project. If it's something more critical that fails, let's say that I'm the developer who maintains the shopping cart, that test fails even when someone else introduced, we talked about a menu code change. Some tests with the shopping cart fails, it could message me because I own that component. So you can go in and keep these lines of communication really open and clear. And then also you can post these results back to GitHub. So this was the lighthouse test we talked about if the performance drops a certain threshold, we can block this being merged. So we can come in and see that this test failed. The performance score was 37. And I expected a score of 81 because our previous score was 86 and I have a level of tolerance of five. You can configure all of these things. We can go and say, whoa, maybe all of the other tests pass, the form still work, the code looks okay, but our performance tanked. So when you have that broad coverage, then you're mitigating risk, building that confidence and that's communicated back as well. And we can see review required. So this is something that is not actually see it itself. This is something you can do with GitHub but you can go in and say, hey, our process is that we do code reviews and maybe currently that's something you're just saying out loud. Well, maybe, like I said, someone new comes on or you bring in a contractor to help with a project and they don't know your processes. Even if it's written in some wiki somewhere, maybe they still don't know that you do code reviews because nobody told them. But if GitHub gets angry and says, no, this test failed or this code needs reviewed, you're enforcing your process and you're keeping that consistency and that communication. So you don't have to remember that every time you onboard someone, oh, you have to do all of these things and we do code review, it's baked in the system. They know you do code reviews because it's right there in front of them. In reduced overhead, we've talked about all these things take time from different people on your team. So here is just an example where we have a new pull request open, we've changed some things on the readme, but we actually spun up a new development environment automatically with continuous integration, just have a script that goes in, uses some command line tool, spins up a new environment and then call the GitHub API and post that link back. So now I don't have to go in, whoever made this change doesn't have to go in and worry about provisioning an environment. Someone else who wants to go review this change doesn't have to worry about provisioning it if the first person didn't. Maybe they don't even know how to do that. They can just come in and click on the link. They don't have to request it and wait for a response, right? So you're taking this burden off of the person who's making the change, you're taking the burden off of the person reviewing the change and just really improving the efficiencies in your process. This is visual regression testing. So it can use headless browsers to take screenshots before and after of a change. We see here on the left, we kind of are missing this button. Now we have this login with Google social button and then the image on the right is the difference because the button like moved everything a few pixels, the entire thing failed. But this is a type of thing that you can automatically generate these reports attached them to your pull requests. And I don't know about you but when I go in and make a change, that's kind of the default QA, right? Is go look at the homepage, go click around some stuff. What happens when you have 10 templates and you wanna view three viewports? That's 30 things I have to review. And if we're being honest with ourselves, we don't review 30 times every single push, right? It doesn't happen. But when you move that to continuous integration, that can happen every time because guess what? The robots are really good at spinning up a headless browser and they can do it in parallel, spin up like 10 of them and go review these things. And then it is reasonable. It's not reasonable to ask someone to review 30 for every single change. It is reasonable to ask somebody to, hey, look at the report and make sure that, yes, I introduced this button change. This is what I expected to change. But what if the report came back and said this other template, that this button's on the homepage, some other template is broken now and it caught that? Like reviewing the report is a reasonable ask. Much more reasonable than go check every template to make sure your homepage changed and break things, right? And so this is extending that. We've actually used visual regression, some of this automated testing to automate security updates. I know there was a pretty big one that happened recently. We won't go into details there, but essentially this is a pretty extreme example of the power of continuous integration, some of the things you can do. So spinning up a new environment, pulling down the database and files from live, applying a new security update, running this visual testing because security updates shouldn't affect the way your site looks, right? It's probably some one like SQL input line somewhere that's not gonna affect the way your homepage looks. So we can go in, make sure visual tests are okay. If you have any additional tests for those contact forms and whatever else is business critical we talked about earlier, run those tests. If everything passes, merge it, ship it out. You can run more tests if you want and then deploy it, right? And this is something that can run on a cron. I have it running every four hours for sites that have to help maintain. And so now if a big security patch came out right now, and I'm busy, I can't stop in the play updates to a bunch of sites right now. I mean, I could, but it'd be pretty rude. Then we could go in and I just know that within four hours this is either going to get applied or I'm gonna get an email that some tests failed and I need to go review. And even if that happens, it's gonna tell me like, hey, this certain template is broken, check that. And so I'm not playing needle in the haystack. I can go in with precision, fix what I need to fix, get my update applied and ship it out. So really if you think about the time you're spending on updates, adopting continuous integration is gonna mitigate your risk, up your level of confidence. And then we're talking about reducing overhead. I don't know about you, but before I automated this process I spent many, many hours applying and queuing updates. So if you want a good reason to adopt this, then taking those hours off of your plate is a pretty darn good one. And I kind of want to end with automation is a journey. So don't go in and try and like do this over the weekend. It's not gonna happen. This took us like a year to flesh out. That large process I showed at the beginning with all of these things running on pull requests, it was a journey, it took time. So we came in and said, all right, on every pull request we're gonna just run some code sniffing. Now we're just gonna install dependencies. Okay, wait, we're shipping code and the client's complaining with the site slower. Let's add a lighthouse test for performance. So you build these things over time so it really is a journey and so think of it that way. Final thoughts, I have some links on here at the end of the slide. I actually did a full talk at Drupalcon previously about the automated updates if you wanna dive into that. Some other great DevOps tracks. So if I've sold you on adopting CI, go check out some of these other ones and really get into the details. And then I don't unfortunately think we have time for questions, we're kind of out of time but I'll hang around out in the hall or up at the Pantheon booth, come find me or hit me up at TaylorME and I'm happy to chat some more. Thank you.