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 talk about continuous delivery.

By the end of the lecture, you're going to know what continuous delivery is and why it's useful. Let's start by defining continuous delivery. Continuous delivery, also known as CD, is a way of building software such that it can be deployed to a specified environment, whenever you want to. In particular, you should be able to deploy to production and ideally with one command or a push of a button.

Now this means that you should be able to select the version of software you want. Usually this will be the latest version to pass all the tests, and select the environment you want to deploy this to, push a button and have all of the code deployed.

If you've ever deployed something of any real complexity, then you already understand the value in this. If you're doing deployments on evenings and weekends, it's a sign that something is wrong with your deployment process. And if you're concerned that a deployment to production is going to break something, then again, something may be wrong. Now, I'm not suggesting that nothing will ever break in a continuous delivery set-up. But it should be the exception and not the rule.

In our Continuous Integration course, I mentioned that CI, as a process was responsible for code level testing. Its job is to ensure that the code is in a working state. If code from your CI server is always in a working state, then your continuous delivery server can pick up that code and start in on its' process. Continuous delivery should start by deploying your software to a testing environment that mirrors production. Now it can be a scaled-down version and that's okay. And then it should run the automated acceptance tests. The job of your acceptance tests is to ensure that the requirements for your software have been met. Automated acceptance tests tell the developer when they have completed their tasks. And they also serve as a set of regression tests and that just means that they can ensure that no new code changes have broken existing functionality.

Now, if you're automated acceptance tests fail, then the process should stop. The developer should be automatically notified and someone should be immediately assigned to resolve those issues. When the acceptance tests are passing, then any non-functional automated tests can be run. I like to have load testing performed here. As well as more in depth security audits, by automating scans that pick off the low-hanging fruit. Things like SQL injection, cross site scripting and known misconfigurations. Developers, ops and security engineers should collaborate on a testing plan for these automated tests.

Once your automated tests have passed, downstream teams can deploy the software to a testing environment of their choosing and perform any required manual tasks such as user acceptance testing. Assuming your software passes all of the manual tests, then you're ready to deploy to production.

Now that I've described the continuous delivery process, I wanna circle back to my initial description. I had said, "Continuous delivery is a way of building software such that is can be deployed to a specified environment, whenever you want to. And in particular, you should be able to deploy to production".

And while this is all true, I omitted a bit of the description for brevity. Now that you've heard how the continuous delivery process goes, you may have noticed that it's more than just about deploying software. With all of these layers of testing, it's about deploying the highest quality software possible. Simply automating a deployment to production, without these layers of testing will result in getting potentially broken code to users faster, or breaking an environment with a push of a button.

Automating a broken manual process will give you a false sense of security and probably nothing more. Every build of your software is a release candidate. And it's the job of your continuous integration and your continuous delivery process to try and prove that that software is not releasable by testing for known issues. There will be times where something makes it through to production and causes a problem. And in this case, you should try and incorporate tests to check for that problem in the future so that it won't happen again.

Your end goal should to be attempt to make a deployment process that is so boring and predictable that it can be done by the least technical person that you know. Okay, depending on the software, maybe that's asking for a bit too much, but, if you strive to hit that goal then it tends to make for much simpler deployments.

So, our revised definition of continuous delivery is that continuous delivery is a way of building software, such that it can be deployed to a specified environment, whenever you want to and deploy only the highest quality versions to production. Now that you have an understanding of what continuous delivery is, we need to talk about why it's valuable.

Between the gated tests and the ability to deploy at any time, there's obviously a lot of value there already. But here are a few other valuable things about continuous delivery.

First, increased quality. Because the tests are run on each commit, we filter out software that doesn't pass the tests, and this improves overall quality.

Improved cycle time. Developers are able to get features to the end-users faster and that's obviously a good thing.

Better resource management. Because we're testing more, and at different phases, we spend less time having people, which tends to be an expensive resource, wasting time on builds that won't pass our tests.

Reduced deployment risk. Because we made a process that's so boring and predictable, we remove a lot of the risk that's involved in a more manual and less frequent deployment process.

And finally, better customer feedback loops. Because the customer's getting the changes faster they can respond to those changes faster.

Now, before moving on, I wanna talk about continuous deployment, which is similar to continuous delivery except that, when your software makes it through all of this automated testing and the manual testing phases then your software is automatically deployed to production. So, choosing to deploy on each successful build is a business decision, and since this process is the same except for whether you push the button or it's automatically deployed, we'll only be talking about continuous delivery throughout this course.

So, how do you get started with continuous delivery? There are a lot of great tools out there that will help to build out a continuous delivery process. What your app does, the language it's built in, the frameworks you're using and the environment in production among other factors, are going to help dictate how you implement your continuous delivery process.

We'll talk about those tools later on, however; first I wanna get into what kind of changes your software may require to support continuous delivery. And that'll be the subject of our next lecture. Coding for Continuous Delivery.

Alright, let's check it out.