Continuous Delivery (CD) Procedures in AWS environment
Introduction
Continuous Delivery (CD) is a practice in software development that focuses on automating the procedures of building, testing, and releasing software to production servers. In other words, whenever a change is made to the source code, it is automatically tested and deployed to the production environment. This occurs as a result of the Continuous Integration (CI) process, which handles the integration, unit testing, and consolidation of code within a shared codebase.
Main Components of Continuous Delivery Procedures
The Continuous Deployment Process (CD) is characterized by several Phases:
- Source Code Updates: In this initial phase, developers make changes to the source code and upload them to the repository, which may be hosted in a version control system such as Git;
- Build, Compilation, and Testing: After each modification to the code, an automated build and compilation process is triggered. This phase creates an executable artifact from the source code, ensuring that all components are integrated correctly. Additionally, tests are performed at various levels, including unit tests, integration tests, and system tests, with the aim of identifying and resolving any issues or bugs before proceeding further in the deployment process. This process is also referred to as Continuous Integration.
- Deploy to Test Environment: If the Continuous Integration phase is completed without errors, the artifact is deployed to a test environment that simulates the production environment. This step allows for verifying the behavior of the software in a context similar to the real one.
- Acceptance Testing: In this phase, automated end-to-end tests are conducted to ensure that the software meets the specified requirements and expectations. This step is performed in dedicated test environments.
- Manual Approval: The only difference between a Continuous Delivery process and a Continuous Deployment process is that, in the former, there is a manual approval by a user. This user reviews the reports provided by the automated tools conducting end-to-end tests and decides whether to proceed with the release to production environments. In the latter case, everything is handled automatically.
- Deployment to Production: If all the previous phases have been successfully completed, and approval has been obtained, the software version is automatically deployed to the production environment.
- Continuous Monitoring: After the release, continuous monitoring is initiated to identify and address any production issues in real-time. This includes monitoring performance, errors, and system behavior.
Tools used
AWS Code Commit
It is a fully managed versioning service provided by Amazon Web Services (AWS). It can contain multiple private Git repositories, allowing developers to manage, archive, and collaborate on project source code securely and at scale. It is integrated with all AWS services and supports all Git commands.
AWS Code Build
It is a fully managed build service provided by Amazon Web Services (AWS). This service allows for the automatic compilation, testing, and deployment of application source code, providing a scalable and flexible build environment. It offers various build environments for many programming languages and is commonly used as a stage within continuous development and release workflows.”
AWS Code Pipeline
It is a release automation service managed by Amazon Web Services (AWS). It is a tool that allows for the automation of the software deployment workflow, from code compilation to production deployment. It consists of Actions, Stages, and Transitions and allows for the inclusion of manual approvals, useful in Continuous Delivery procedures.
Elastic Container Registry (ECR)
It is a service provided by Amazon Web Services (AWS) that offers a fully managed Container Image Registry (OCI). It allows developers to store, manage, and deploy images that will be subsequently used within orchestration services such as Amazon Elastic Container Service (ECS) or Amazon Elastic Kubernetes Service (EKS).
Elastic Kubernetes Services (EKS)
It is a fully managed service by Amazon Web Services (AWS) that simplifies the management and execution of workloads based on Kubernetes. Kubernetes is an open-source system for container orchestration, which facilitates the deployment, scalability, and management of containerized applications.
Procedure architecture
The procedure has been implemented using the previously described tools and, in our specific case, allows for the automation of the release of an Angular front-end module within a web application. It is composed of six different phases.
Pipeline Start
The internal process begins when authorized developers make pushes to specific development branches. The first step downloads two different repositories: the application repository (containing the Angular application codebase) and the repository for the automated testing module, which will be executed in a later phase.
Build Test and Push on Ecr
After downloading the necessary repositories for pipeline initiation, the second stage involves building, testing, and packaging the application. The newly created artifact is immediately saved in the test registry and will be useful for the next phase.
Deploy on test cluster
After creating, testing, and storing the artifact in the previous step, this stage retrieves it from ECR and installs it on a Kubernetes cluster using the EKS (Elastic Kubernetes Service) service. Additional tests are run in this environment to verify that the software meets requirements and expectations.
Start selenium test
Once the artifact is successfully installed in the test environment, automated end-to-end test suites are initiated to verify that all application features function as required. In this stage, besides the front-end, the behavior of the web application’s business logic layer is analyzed, and reports are generated for the next step.
Manual approval
In the Manual Approval phase, reports produced in the previous step are analyzed by the procedure manager who decides whether to proceed with installation on production environments, making updates available to end-users, or to cancel the entire process.
Push on ECR and deploy on cluster prod
If the procedure manager finds the results obtained during automated testing satisfactory, the image is archived in a production registry, and the artifact is finally installed on a production cluster.
Pipeline Structure
The entire design and implementation of the procedure were carried out using the AWS CodePipeline tool. It consists of six different stages:
- Source (source download);
- Build;
- Deploy to EKS;
- Run Selenium Test;
- Deploy to EKS Prod Approval;
- Deploy To EKS Prod;
Source (source download)
The Source (source download) stage consists of two parallel actions: CodeCommitDMF and CodeCommitTestSelenium. Both are AWS Code Commit tool-type actions, responsible for downloading the application codebase and the unit test codebase, respectively. As an output from this stage, there is a transition state that leads us to the Build stage.
Build
The Build stage consists of a single action named AngularBuildAndCreateDockerImage. It is an AWS CodeBuild action that handles the compilation, packaging, execution of unit tests on the Angular module, creation of a Docker image for the web application, and uploading it to the Amazon Elastic Container Registry for testing. As an output from this stage, there is a transition state that leads us to the Deploy To EKS stage.
Deploy To EKS
The Deploy To EKS stage consists of a single action. This action is an AWS CodeCommit type that retrieves the previously saved Docker image from ECR and installs it on a test EKS cluster. As an output from this stage, there is a transition state that leads us to the Run Selenium Test stage.
Run Selenium Test
The Run Selenium Test stage consists of a single action, RunTestSeleniumonEc2, also of AWS CodeBuild type. Within this stage, automated end-to-end test suites are executed, and reports are generated in specific formats to determine whether the application can be installed in production environments. As an output from this stage, there is a transition state that leads us to the Deploy to EKS Prod Approval stage.
Deploy To EKS Prod Approval
The Deploy To EKS Prod Approval stage is a specific stage in AWS CodePipeline and is what distinguishes our continuous delivery pipeline from a continuous deployment one. In fact, this stage includes an action, Deploy To EKS Prod Approval, of type Manual Approval, which pauses the execution, awaiting human intervention to decide, based on the test results, whether to proceed with the release or not. As an output from this stage, there is a transition state that leads us to the Deploy to EKS Prod stage.
Deploy to EKS Prod
The final Deploy to EKS Prod stage consists of two sequential actions: PushImageToEcrProd and DeployToEKSNamespaceProd. Both are AWS CodeBuild type actions responsible for storing the web application image in the production registry and deploying the artifact to the production cluster, making it available to users.
