Explore the terms continuous integration, continuous deployment, and continuous delivery.
- [Narrator] In the next sections of this course, we're going to take a look at a concept called Continuous Deployment. So first, we'll have a definition. What is it? Continuous deployment or CD is the ability to get changes of all types, including new features, configuration changes, so that would be infrastructure changes in the case of Amazon, bug fixes, and experiments, AB tests, feature toggles, into production all the way to end users or customers, safely, quickly and in a sustainable and fully automated way.
Boy that sounds fantastic, doesn't it? Well, I've actually worked with a number of teams building CD pipelines for AWS. And in these two sections of the course, I'm going to talk about those experiences from the real world and also, a set of new tools that supports CD that's available via AWS. But we need to drill into definitions before we start on working with tools. So let's take a look at continuous deployment in the consideration of how it's built. The idea is a pipeline. And this is a conceptual drawing that we'll use as a reference as we work with the tools.
The idea is that there are phases or stages of the pipeline. And that you'll use associated AWS services and tools to support those phases. So these are source, so this is where developers commit changes. Traditionally, this has been something like Git or GitHub, or even a different type of source control. With the new set of tools available for AWS, you can continue to use GitHub but you also have AWS services, namely CodeCommit that supports this source phase. Build is where changes are built and if you have them, tests are run.
Unit tests would be an example. Prior to AWS releasing their new services, the customers I worked with used build servers. Servers like Jenkins. In the new set of CD AWS tools, they have a service called CodeBuild where this phase can be accomplished. The next phase is typically called Staging, code is deployed and tested. Now again, this can be combined with build, this can be a separate stage, this can be multiple stages, we're gonna look at a lot of different scenarios throughout these two sections and movies.
But the idea is that you have some phase in your pipeline where you have both manual and automatic testing. Now there can be many different ways to implement this. In some customer's, it's been fully automated. With some customer's, it's been entirely manual. With some, it's been a mixture. So we'll look at different patterns. And then the last phase is production. Code is deployed to public servers in the Amazon Ecosystem. This would be EC2 of course. There are though, modern architectures that support containers and functions or serverless.
So we'll also look at patterns that support those types of CD pipeline deployments. Now back to those definitions. When we talk about CD, there's some ambiguity in the term because it really refers to two different underlying terms. Before we get there though, there's a predecessor called CI. CI is Continuous Integration. What this generally means and I'll take my definition since I'm creating this content, is that your developers are committing to a main branch in source control.
The tests validate or pass and the failures would break the build. Now layered on top of continuous integration is continuous delivery. So in other words, once you've successfully implemented CI, then you can layer on top to implement CD. Which in this case, I'm defining as continuous delivery, not continuous deployment, there is a difference. Continuous delivery is that you push all the way to the customer, you push the code changes. This will use a build server and a pipeline and it relies on that validation that I talked about earlier, automated and human, or entirely human.
A product owner or a manager will click a button after reviewing changes to the application which will then send those changes out to production and the customer. Because we're working with different terms and to have the same abbreviation, I though it would be interesting to just look at how these phases of CD are accomplished in the real world. So we really have CI, continuous integration, CD, continuous delivery, and CD again, continuous deployment. Well how does this work? Well, we start with our source changes and that's represented by V1.1 on this diagram.
And then, we send them into source control or we commit the changes. This is generally automated. Then we send those changes to build which will run, build and unit test. Also generally, automated. Then we send to one or more staging environments, deploy to test. This could be test, QA, Alpha, Beta, whatever. During staging, it's common to run integration tests, load tests and other types of tests. Now here's the kicker. Continuous delivery has a manual approval to production.
Continuous deployment has a fully automated approval. So in other words, once the developer's push and all the tests pass, those changes do go into some subset of production automatically. Now this is a very advanced technique and it's one when I worked with teens, it's taken them weeks or even months to get to. So you wanna have realistic expectations particularly the first time you're attempting to setup full-on continuous deployment. It is quite advanced, it requires the cooperation of all the teams in the project and you wanna build up through the various stages.
- Understanding high availability (HA)
- Preparing for HA
- Designing for HA
- Understanding continuous deployment (CD)
- Types of verification tests used in CD
- Server mutability and CD
- Implementing CD
- Advanced CD pipeline techniques
- CD pipeline with Step Functions