Welcome back to Introduction to Continuous Delivery. I'm Ben Lambert and I'll be your instructor for this lecture.

In this lecture we're going to take a walk through a continuous delivery process that I've created and review the different steps.

I'm going to be using Jenkins, Ansible, and AWS for this demo. These are tools that I have come to leverage when building Linux-based projects. However as we said in the previous lecture they are by no means the only option. And they're not even necessarily the best tools for all builds. They are just the ones I've selected based on my preferences.

So let's start by looking at Jenkins. We'll start with our continuous integration job.

If the CI job runs successfully, then we know we are working from a tested code base. If you took the Introduction to Continuous Integration course you may recall that that the CI process is in charge of testing our code and making sure that it behaves how we expect. So we only trigger our continuous delivery process after CI succeeds. Our continuous delivery process starts out by deploying our code to a staging environment for testing. If you look at the line that starts with Ansible playbook you can see that the way I'm deploying to the testing environment is through Ansible.

Your continuous delivery process should start out by taking the OS installer package that you're continuous integration process created, and deploying it for automated acceptance testing. By deploying it on an environment that matches production we can ensure that our tests are more accurate.

So I'm using Ansible however you can use whatever method you prefer. Let's check out the Ansible playbook and see how it does the deploy.

Starting off you can see that it says deploy application {{ environment }}. Those brackets are template tags that Ansible will swap out for us with the environment variable that we pass in to it on a command line. Looking back at Jenkins you can see that it passed in via the --extra-vars flag. Line two is where things get interesting. It says host; tag_environment_ and then we have that same environment variable in our brackets.

So this tells Ansible to look at at any host in this case it checks out our AWS servers and it looks for anything that has a tag named environment with a value that is equal to our environment variable that we passed in earlier, in this case its staging. So if you look at AWS you can see we have a server with that tag that is equal to staging. Now this is cool because we don't have to worry about IP addresses or anything like that. We can just tag a server with the environment set to staging and our script will provision it. This means we can dynamically create our testing environment whenever we need it and not have it running all the time.

Then going through the tasks we start with loading the assigning key for our apt get package and making sure that these new servers know where to look for our repo.

Next we update the app kit cache and we make sure that the Apache server is installed. Then we install the latest version of our application.

Keep in mind you could use a parameter here to pass through a specific version of your application if you wanted to. And we wrap it up by restarting the Apache surface. And once that's all done we can run our automated acceptance tests.

Now these tests can take a while because they run through the complete application stack by simulating a user sitting at the browser actually using our software.

This test takes the URL passed in and goes to that page and looks for the text to do And if it finds it, it passes. And if not, it fails. Now once the acceptance tests are run you can run other non-functional tests. You can run things like load testing and security audits.

Up to this point you've run all kinds of functional tests between the tests you've run in your CI tasks and the acceptance test here. However non-functional tests are the ones that don't really care if the software is functioning as a specification says. They care about things like, will the software stand up to the typical load that it needs to, or does it pass all the basic security audits. Now any automated tests that you can run here to try and show that the build is not production quality should be run.

Remember we talked about it before how your job from the CI server is to prove that the build is not production ready. And automated tests will help to ensure that people aren't spending time on builds that aren't going to make it into production. Once all of your non-functional automated tests are complete and they are passing, we can then allow people to perform any tests that they may need to. There are some tests that are still better for humans to perform.

You know who is really good at making sure that you're responsive styles are working well? Humans. Making sure that buttons line up and that the logo is exactly where you want it to, these are things that you could automate however the time and effort that would go into it really would be wasted.

So once you've run any manual testing and everything has passed then it becomes a business decision what to do next. At this point you haven't found anything wrong with the build so it can be promoted to production if that is what you choose.

Let's run through a complete process and see from code to production. We're currently running version 1.2 in our production environment. So let's edit that file and commit it. What we're going to do is update the version number. This is something that would ideally be done as a build step however I'm doing it manually here for the demo. So we're going to add a little bit of text and then we're going to commit this. And once its committed we'll push it to GitHub.

Now if we look at the Jenkins UI we can watch and see that its going to pick up the changes and run the continuous integration task. Notice the build button is blinking on the right side of the screen and it's running the CI task. And when this is done it's going to call the continuous delivery task if the CI tasks was successful.

The CD task takes a little bit of time to run. And we can see that its kinda going through its motions if we look at the console. So here its running through its deployment to staging. And the acceptance tests. And when its done we can see that staging has the latest environment. And production, which is the version our load balancer is serving, is is still running the previous version. And since everything looks good we can now push our code to production.

So we need to select which version we want to deploy to. Now this is an okay method for demonstrating blue-green deployments however keep in mind that if you implement this pattern yourself you'll want the process to determine for itself which color is live and which one needs to be deployed. We can check which color is attached to load balancer and it looks like the answer is green. So that means we need to deploy to our blue environment. So if we click the build button on the Jenkins UI then the process will start.

If we look at the Console we can see that Jenkins is running some of our Ansible tasks. Let's look at the playbook and look back at production when everything is deployed. Here you can see that the playbook looks a lot like the one from earlier when we deployed to staging. And that's because it basically is. The only real difference are the commands on lines 28 and 31 that are responsible for adding the new color to the load balancer and removing the old one. These playbooks are not as succinct as they could be. They could be one parameterized playbook. However I thought this would be a more readable way to show them.

So what Jenkins does when we tell it to deploy is run through this playbook and sets the color that we've told it to. And once the updates to the software are complete, it adds that color to the load balancer and unregisters the others. And since connection draining is enabled it will take the time to wrap any connections.

Okay, let's go back to Jenkins. Our job here is complete and if we look at the version running under the load balancer we can see that its 1.3. And if we went back to the green environment directly, that is the one with the IP address ending in .67, we can see its still on 1.2. And our production environments stays running with no down time And that's my basic CD process.

In our final lecture we're going to summarize what we've covered in this course.

So if you're ready let's check out the final lecture.