 Good. OK. Hi. I'm Chris Proto. I'm a DevOps engineer and lead at Craftsy. My topic today is blue-green deployments with Packer, Terraform, and Jenkins, and some cool DevOps tools. But my talk's really about is a story that we're writing here at Craftsy, where we're moving from a rigid release cycle, a weekly release cycle, as you can see here, every Tuesday, and moving more to a continuous release, continuous deployment model. We're not quite finished with it yet, but we're at this phase where we want to share some stuff that we've done. So every Thursday before release, that would be our code freeze day. Code freeze day is when we would build our release candidate. And then that would start the QA regression cycle. And as you can see, there will be about two and a half days to fit in about a week's worth of changes. And then that culminated on release day, where about four or five to six engineers would get in a room every Tuesday for about four or five, maybe six hours to shepherd the release through. Quite a few people, and if you want to do the math, that's a lot of expensive people in a room not making features. They're all sitting on their butts shepherding a release. So what we're looking at this was that's costly. And part of the reason that is is because these changes that happen every week, they're complex. So it requires a lot of different people, a lot of different disciplines in order to shepherd this release through. So once our releases are risky, the cost becomes high, the cost being we need to put all these people in the room every week to shepherd this thing through. So we realized we're not special snowflakes. Other people might be having these same problems. So what we did was we went look to the community. And we looked at what tools were out there, what people were doing, the process of the new ideas that the DevOps community was going through. So one of the things that kind of kept popping up was putting these ideas of putting different things into code repositories, infrastructures code. Packer is a tool for doing machine provisioning as code, as I like to call it. Terraform is the infrastructures code. And that kind of fits nicely. It was kind of a paradigm shift for us because application, that's what we put as code. So that makes more sense. But when you think about it, if we can use Packer to do that system provisioning and put that code and facilitate that, what we can do is we can take that integration problem with the application and what system it's going to be running on and figure out those problems earlier on when we bake a system image or AMI when you are launching things in Amazon. And then if you pull up a little bit further and you look at the environment level, you can take that AMI that you've already tested and you can define your infrastructure and the environment that it's going to be running in with Terraform. So in this case, we've got a load bouncer, a group or two, a blue and a green. And we can facilitate some cool stuff like a blue-green deployment, which I'll talk a little bit more later on when we go through a build pipeline that we've got. But it's this idea that we can now define our infrastructure as well and integrate that. And then pulling up a level further, we can put our unit in functional and our smoke test as well as in code. And we can also put our Jenkins build configurations in there as well and integrate that all at once whenever a change is detected with a code change to repository, which will then trigger out of the whole unit tested and functional test framework. And then after that's done, we can test the AMI process, make sure that application we just tested actually integrates with the system that we're going to be deploying. And then after that, we can go through the deployment process and make sure that that AMI that has that application can now be deployed out in the way that we have designed out. So really compelling stuff and some interesting paradigm shifts for us as we're going through this. But automating this has opened up some new doors here. So once we get that stuff out into stage, we can get in front of our first person that can look at that, validate it from just a human perspective, a QA person, ops person, product person. And they can promote that. They have the opportunity to promote that now to production. And here we'll talk a little bit about the blue-green style. So what we've got here is we define our load balancer and a couple namespace security groups type things or things that are local to that application. And then when we have those blue and green groups together, we can do a switch with Terraform by orchestrating what's connected to the ELB. So the key thing here that I feel like glues everything together is that a code commit is a change. And it's a special kind of change. It's a change that's very reactable to. A lot of different processes. Jenkins being an obvious one in that realm that can react to these changes and fire up tasks and processes all in an automated fashion. You can do changes in different ways with logs or some other eventing model, but this seems like a really low effort way to do with these code detection mechanisms. And then that opened up these doors for things like blue-green deployments where now we can do these, it opens the door a little bit more for us to do these fast rollbacks. And now that we're testing all our integrations as they happen, all these changes, our deployments are smaller and less riskier than they were before and we have to test everything from one week. And finally, I want to end on thank you everybody for none of this would be possible without all the cool DevOps tools that the community is building out and all the ideas and everything that we borrowed from. And small team like mine can do some really cool innovating stuff. So thank you very much.