CodePipeline actions let you perform operations not only in the region where the pipeline is hosted but in others. The elegance of this feature is that the respective input artifacts are made available in the other region by the service itself. You just need to ensure the presence of an artifact bucket in the target region to leverage this capability.
As you can imagine, this can evolve into a deployment design, where you host your pipeline definition in one region but manage resources across multiple others. This is a functionalitythat is at the core of several multi-region AWS deployment frameworks.
Rolling out a fully automated CI/CD pipeline in your AWS account
So far, we’ve established a conceptual understanding of how AWS services such as CodeBuild, CodeDeploy, and CodePipeline work, and how they help you automate parts of your software delivery process. The biggest advantage of these services is that you don’t need to adopt a full-fledged solution. You can selectively offload specific areas of your software delivery process to one or more of these tools. Wiring them up with one another is also a seamless experience.
When a substantial number of workloads are running in the cloud, leveraging AWS native tooling for CI/CD can help a lot. Let’s see these concepts in action by rolling out an end-to-end CI/CD pipeline. In the previous chapters, we used an AMI with the application code in it. To better demonstrate the capabilities of the AWS services mentioned in this chapter, we will use a slightly different AMI. The new image will differ in two aspects:
- It will no longer include the application code. We will inject the code at runtime using CodeDeploy-managed deployments.
- It will have the CodeDeploy agent installed by default. This is a prerequisite for CodeDeploy to be able to manage your EC2 instances or on-premises servers.
The overall workflow is highlighted in Figure 5.2:
Figure 5.2 – Software delivery process highlighting the important phases
The following are the individual steps you must take, starting from writing code to deploying the changes in the production environment:
- The application developer commits code to the CodeCommit repository. The repository contains the application code as well as the manifest files for respective services such as CodeBuild and CodeDeploy. Please note that the solution can easily adapt to other version control systems as well. Just replace CodeCommit with other providers, such as GitHub or Bitbucket, and you are good to go.
- Completing the code check-in process triggers the pipeline’s execution since CodePipeline continuously polls for new changes in the CodeCommit repository. As part of the first stage in the pipeline definition, recent code changes are pulled. The role of this stage is to pass this code (artifact) to the next stage for further processing. It is a good practice to set up CloudWatch event-based triggers for CodePipeline instead of polling for changes. For the sake of simplicity, we will restrict polling behavior in our demo.
- CodePipeline takes the output artifact from the source stage and passes it further to the build stage as an input artifact. CodeBuild reads the buildspec.yml file to understand the build instructions, runs all the validations that have been defined, and reports the outcomes (success/failure) back to the orchestrator – CodePipeline.
- Upon receiving a successful status from the build stage, CodePipeline picks up the output artifacts. which in this case are the validated templates and code. It then forwards them to CodeDeploy, which serves as its input for the following steps in the process.
- CodeDeploy makes use of the appspec.yml file to understand the deployment steps. Depending on the deployment configuration, it coordinates code rollout activities in the deployment group (two EC2 instances). CodePipeline tracks the output of the respective CodeDeploy deployment and upon receiving a success signal, marks the pipeline as completed.
- Finally, the new code modifications are deployed to the underlying EC2 instances. Application consumers, or the end users, can now use the application by accessing the load balancer’s URL.
Note
For a brief duration, you might notice different code versions running in parallel, across different EC2 instances. This is because we do a phased deployment rollout with CodeDeploy. This results in ALB returning different responses while the deployment is mid-way through.
Let’s start with the first step of our deployment, which is to create a new AMI in the AWS account.