 So thanks everyone for coming. We're gonna get started. So yeah, I'm Shanley. This is Everett and we are from my planet. Hello, we're my planet. And this is our mission just to give you an idea of who we are. We're actually a Toronto based technology firm and our mission is re-energizing how people connect in the workplace. And we do that through a lot of ways, but Drupal is one of the tools that we use a lot. So just to introduce ourselves, Everett. Yeah, I'm Everett Zufeld. I've spoken at a couple of Drupal camps in Toronto and around. I've been drilling Drupal for five or six years. I'm an associate director of technology at my planet in the professional services part of our business where we do a lot of Drupal work amongst others. And I'm an Aquia certified grand master, which means I passed three exams, so that's pretty exciting. And I'm just a lowly Aquia certified developer. So one of the things is that this is marked as a Drupal advanced, but you know, a lot of the elements already talking about are comments of people. So we hope to start a discussion. If you have any questions, just please raise your hand. And we hope to just have a discussion with you guys, especially with a smaller group, which this is, I'd love for it to be less of us lecturing, because quite frankly, we like to look at this as incremental learning. We learned a bit through making lots and lots of mistakes. Hopefully, some of you have experimented with these tools and have made a bunch of mistakes too. So if there's things where you want to contribute and say, oh, yeah, I also made that mistake or, or, oh, you know what, I learned that and here's how I jump in because, you know, A, we don't have tons and tons of material and B, it's nice to have more points of view and more voices in on this. All right. So let machines do the work. Continuous integration with Behat and Travis CI. So we've just introduced ourselves, but I hope to get to know you guys a little bit better first. So what we're going to do is we're going to run a little bit of an exercise. And it's all the five fingers exercise. I'm going to say a statement and then if, depending on how much you agree with the statement, you hold up from one to five fingers. So for example, I might say I like ice cream. And if you really agree with that, you say, yeah, like ice cream, or you might for some reason say, no, I hate ice cream. So, yeah, here are the statements. Here we go. I understand what the important features of my projects are. So yeah, if you have any coworkers here, feel free to look around. Judge them. Judge them harshly. I understand how to verify the work we produce satisfies the requested features. I understand how to verify that the work we produce satisfies the requested features. All right. How about I feel like I'm empowered to produce the best quality work. And I understand how much effort is required for testing and who's going to produce that effort. I understand it. The project manager. Yeah. So there's a wide variety of answers here. And these are a bunch of questions that we've really considered over the past few years on my planet. And we've developed a process and glued together some tools that help us support that process. And that process helps us to go five fingers on those questions. So I'm going to show you a demo. But first thing to talk and Everett and I are going to talk about the components and the principles behind those components. So I guess the first key building log for us is BDD and using BDD to achieve stakeholder alignment. So what is BDD? BDD in case you don't know is it an acronym that just refers to behavior driven development and what is behavior driven development. All it is is a pattern for collaboration. And hopefully the output of this collaboration is shared understanding for alignment about what we're supposed to be building. Is anybody using BDD today in their regular practice? So I mentioned collaboration because when I it's not just developer centric. There's developers, designers, product owners, business people, testers, anyone who might have insight into why we should build what we should build should contribute to this process. So this typically occurs during planning on the story level and the output of this collaboration is what we like to call Gherkin. Gherkin is just a formalized description of our alignment and it's a subset of natural language. Here's the example of a Gherkin test and it reads a lot like a story. Given I am logged in as an admin when I delete a user then that user should receive an email alert and that user's content should be assigned to me. So one of the points and one of the big key points here is that everyone can understand this. Business people can understand this, designers can understand this and we all agree on the important features without having to go into the the tiny details. And you're loaded with this written in the format given when then and and and every statement starts with one of those and either sets up something about the world, performs an action, or makes an assertion about the world. So I guess the key point that we get from BDD is that we collaborate to build alignment and the tool we use for that is BeHot. I'm going to be getting into that a little bit later but first now that we have an understanding of how we're going to test it we have to make sure that we have something worth testing. So let's talk about how we build Drupal reliably. So maybe poll the audience, how are people doing building Drupal sites today? How are you guys ensuring that when you deploy code to your integration server that you're actually deploying reliably built code, that the modules are the right versions, that the code is being built the same way, that it's being deployed the same way, that the same activities are happening every single time. So we do both of those things. We definitely use Travis on most of our projects, almost every project that we use GitHub for I would say, definitely using features, have a love hate relationship with features, looking forward to Drupal 8 and not needing to use features anymore for most of our work, definitely using Drush. What we do for almost every Drupal project is we, I'd say every Drupal project that we start fresh. Sometimes we we found ourselves recently in the last couple of years in a position where people come to us a lot for disaster recovery, like I had a vendor. They didn't really get the job done. Can you please help save my website? Then we're kind of stuck a lot of the time with what we've been handed. If we start from scratch with a web application though, we're building on Drupal. We start by building a distribution with an installation profile. Now I tried to look for a really good definition that distinguishes installation profiles and distributions. And I've come to the opinion there's really no difference in the world of Drupal. We might just as well call it one thing. So the distinction is the distribution is about composing together all the libraries and themes and modules that you need. And the installation profile is that actual thing that you're able to install. It's got the .install file and it's able to enable the right modules and set up the right configuration for you. They're not supremely useful, one without the other. We use them together all of the time. And so I think what Shanley has up is a shot of kind of the root directory of what one of our GitHub repositories would look like. It's got some make files in there like you would expect. It's got some directories in there. We have these folders in there using just get keep. But there's some folders for themes, modules, and libraries if you're including custom code that isn't on Drupal.org or that you can't pull in through a get reference. We have that in there. And then in the temp folder we've got some just scripts that we use to build the exact same build every single time the code gets deployed. The exact same script is what runs Drushmake. So nobody's ever going on the command line and typing the words Drushmake. They're just using a build script so that it happens the exact same way with the exact same flags every single time we do a build. We won't... Using what? No, most of the time we host our Drupal applications either in Aquia Cloud, sometimes on Pantheon, and some of our customers we do a lot of work with cloud services providers. They like hosting on their own infrastructure because it looks really bad if you're a cloud services provider and you're hosting on somebody else's cloud. So we have a few customers who actually host internally so most of the time we host in those three ways. This is not revolutionary so we won't spend a lot of time talking about it. I just wanted to make sure we're kind of all talking about the same thing from a base level around relatively common best practice for how to structure and use Drushmake to build your code and really we just have a very simple script that does the deployment of the code. Yeah. The key point here for us is that humans make mistakes and humans get lazy and machines taking over for you to do the automated stuff or the repeatable aspects is not actually a bad thing. Yeah, go keep going. Which is a good segue to Travis. Yeah, so I think we started doing notes like I'm sure way back in the day. Shanley knows the early beginnings of the organization. We probably started like everybody just shuffling the code off to the server using FTP. That's not reliable and takes way too long. So then we upgraded sort of to using Jenkins. Jenkins is the aircraft carrier of continuous integration. It can do everything. It's huge. It's complex. It's got a knob and a switch that you can flip for every single thing you could ever possibly want it to do. It supports a multi-stage deploy process. It can archive your artifacts and reuse them in the future and for the majority of the work that we do Jenkins is overkill. So when Travis emerged on the scene or at least when we realized that it existed a few years ago started taking a look at it to see what it was able to do for us and it as a tool Travis has definitely evolved over time and grown up. In the beginning we had lots of problems around well how do you get an SSH key in there? There was no ability to upload an SSH key. You had to do tricks like I think there were a few tricks we came up with. Sometimes there was the trick of just well it's a private repository so just version control your private key and it'll be fine. That feels yucky. I don't like that. There's the trick I think at one point. Use an anonymous gist and put your private key out there in the cloud in an anonymous gist. Nobody will ever be able to find it and then in your repository Travis does let you encrypt some short strings that you can then use as environment variables. So you would encrypt the URL to that anonymous gist. Again that's actually relatively safe but feels very yucky that you have this private key that accesses a server floating out there somewhere. Now you'd ask yourself if you can encrypt the URL to the private key why don't you just encrypt the private key. It's because at least at that point in time private keys were too long for Travis to be able to encrypt and store in one of its fancy secure environment variables. So then I think out there on the web someplace there's this technique of a little script that will split your private key in half. Now you store both halves of the private key as encrypted Travis environment variables and then when Travis executes you use another script to glue them back together. Travis has grown up a little bit recently so actually just let you click a button in the user interface that says add private key and that's a whole lot more convenient. You upload a private key to Travis. You put your public key wherever you need the code to deploy to and it's just that simple but back when we first started working with it it was a little bit immature and some of the places where we kept using Jenkins were places where Travis just didn't quite have the feature set yet but we use Travis. Travis is simple. It is tightly coupled with GitHub. You log into Travis using your GitHub OAuth username and password. It can see all of the repositories that you can see and you can just toggle on and off whether or not Travis actually does anything at all with your repository. If you toggle on a repository Travis will automatically put a deploy key into that GitHub repository so that it can pull the code and it will set up a hook so that every time you push code or do a pull request to the repository Travis will get a signal and start to kick off a build process and that build process is configured through a YAML file. I'm not sure YAML is something that Drupal was a little less familiar in the Drupal world until Drupal 8 and now everything is YAML, YAML everywhere. So Travis's YAML file is pretty straightforward. There's really three chunks of a YAML file. There's first of all configuring the environment so you can tell Travis what types of tools you need installed on the system. Do you need PHP? Do you need Node? What version 5.5, 5.6 do you need? Do I need a MySQL server? Do I need a memcache server running? So you can configure the environment through the YAML file very declaratively. You can configure scripts to execute. So there's a before install script where you can set up your tools. There's an install script where you can install your application. There's a testing phase where you can actually run your tests and then there's basically a deploy phase and a post deploy phase where you can actually do a deployment if the tests pass and clean things up or do any final items after that deployment is complete. And then the third part of a YAML file is just about notifications. It's a super slick system. You can just put in a list of email addresses. I believe it supports things like IRC as well. You just configure it in the YAML file where you want the message to be sent and when you want the message to be sent. Typically we do notifications on every single failure and on the first successful build after a failure because I don't need to get an email every time successful code was pushed but it's nice to know that, hey, I got 10 failure emails in a row and now I saw that it got fixed so I don't have to worry about it being broken anymore. And those are really the three major types of things that you're going to configure in a YAML file and it really just is quite as simple as pushing the code to GitHub. GitHub kicks off a hook over to Travis which pulls your code and depending on what you have configured in that YAML file will set up the environment, execute your scripts and notify you of the results. So now it's time for the demo. Anyone by the way has used Jenkins, Travis or CircleCI or is currently using? All right, so about half plus. All right, so it's time for the demo but essentially Everton and I have done something like this maybe four times at Drupal Camps, Drupal Con, whatever you around and not once has it ever gone right when we try to do a live demo. So what I've done this time is I've actually recorded the demo. Yeah, sorry. No guarantee that that's actually going to go right but it feels more certain. So I did record the part of the demo where Everton was just discussing where we actually make a commit. Let me just show you actually. Actually this part is boring. Everybody's clear how to push a commit. Yeah, okay. So once you push a commit, Travis is going to pick it up through like a deploy hook and then it's going to kick off the build. Now one of the things that Travis does is it actually gives you a build environment. It gives us by default the Ubuntu box. So what you're seeing right now. So the Travis box is booted and I'm just going to let it run for a little bit. You can see what it's doing right now is installing the packages that we requested and I'm just going to click here to follow along with the log. You don't have to worry about what's going on too much just other than to understand that the configuration that we entered in Travis.yaml is now being run on this Ubuntu box. For example, setting environment variables from .Travis.yaml is a good example. And here are a couple of secure keys that we've set up. So while this is going on, he hosts. And here, this is pretty familiar to a bunch of you. I'm sure it's just building the Drupal profile. Now here's the interesting part. The tests have started. So you can see here that we have this authentication feature, which is about to begin. And when it does, I'm going to show you what's actually happening on the Selenium end. So it's starting. And you can see that in browser stack, it's actually running these tests as we go. So browser stack is actually pretty useful in that it gives you the ability to see these tests as they ran. And this is actually one in IE8, as I just mentioned. So it's booting the IE8 box, it's starting up the browser and then it's going to run the same test over again. So we can go back to Travis and see that our tests all passed. So because our script phase of Travis completed successfully, it's now going to actually package the application and commit it to the awkward remote repo, which will trigger the plan.