CI and CD stand for continuous integration and continuous delivery/continuous deployment. In other words, CI is a contemporary method of software development where incremental code changes are reliably and regularly produced. Code updates that are merged into the repository are made reliable by automated build-and-test procedures that are sparked by CI. Then, the code is swiftly and efficiently deployed as part of the CD process. The CI/CD pipeline, as used in the software industry, is the automation that enables developers to consistently and quickly transfer incremental code changes from their desktops to Git repositories and then finally into the production environment with specific changes applied to it.
Continuous integration (CI) is a technique where developers check and make minor changes to their code and promptly deploy it effortlessly. This process is automated because of the size of the requirements and the number of steps needed to complete it, allowing teams to design, test, and bundle their applications in a dependable and repeatable manner.
CI streamlines code updates, giving developers more time to make changes and contribute to better products.
The automated transmission of finished code to contexts like testing and development when get integrated with the actual environment stage is known as continuous delivery (CD). Code delivery to various contexts is made automated and standardized via CD.
The next phase after continuous delivery is continuous deployment. There are numerous production deployments because every modification that passes the automated tests is seamlessly put into production. Most businesses that are not bound by regulatory or other limitations should aim toward continuous deployment.
Why the Continuous Integration & Continuous Deployment has became so popular nowadays?
CI/CD allows organizations to ship software quickly and efficiently to the Internet community of their product. In addition to continuously releasing code into production and assuring an ongoing flow of new features and bug fixes via the most effective delivery method, CI/CD provides an efficient procedure for bringing goods to market more quickly than ever.
It significantly reduces the product’s release time and saves the company’s resources time to dive into overheads.
Implementation of AWS Cloud Native Codepipeline CI/CD Automation:
We’ll be using the GitHub repository & AWS codepipeline to deploy a containerized application on the Amazon Elastic Container Service(ECS) through the CICD mechanism.
Prerequisites:
- Dockerized application in the Git repository
- AWS Account
Let’s get started:
First, create an ECR repository to push a docker image in it.
- Click on ‘Create repository’.
- Give the repository a name such as ‘test-repo’.
- Click on ‘create’.
Output:
The ECR repository ‘test-repo’ is ready.
Now, create an ECS task definition where the ECR repo URL will be integrated.
- Click on ‘create new task definition’
- Give the task definition a name such as ‘Test-TD’.
- Set the ECS container name and attach the ECR repo URL.
- As the Port exposed in the Dockerfile of the client is 7000:
- Configure the port mapping accordingly to it.
Add the environment variables(optional).
- Configure the container environment:
App environment such as ‘AWS Fargate Serverless’.
Operating systems as ‘Linux/x86_64’.
Set the task size: 1 vCPU & 2GB memory
- Use the CloudWatch log collection for the ECS task.
- Review & create the task definition.
Now, Create the ECS cluster to deploy the ECS service on it.
- Set the ECS cluster name as ‘Test-cluster’ and associate the VPC network with it.
Output:
Then, create an ECS service to deploy the task definition through it.
Deployment configurations:
- Set application type as a Service.
- Service name as ‘Test-service’ & set the service type as a replica.
- Specify the ‘Test-TD’ as Family with ‘latest’ revision & set the desired number of tasks as ‘1’.
- Review & Create.
Output:
Now, the deployment infrastructure is ready. We’ll be moving toward the CI/CD implementation to automate deployment configurations through AWS CodePipeline.
- Goto the CodePipeline and click on ‘create’.
- Set a pipeline name such as ‘Test-pipeline’ & allow AWS CodePipeline to create a service role then hit the ‘next’ button.
- In the source section, click on ‘connect with GitHub’.
- After the authentication is done with GitHub, confirm the process.
Output:
(Note: As the source provider ‘version 1’ is not recommended nowadays but we’ll continue the CICD with it.)
- Select the Git repo and its specific branch as the source for the CICD process. Click on ‘next’.
- In the add build stage, select the ‘AWS Codebuild’ platform to run the builds.
- When you click on the project to select the CodeBuild project, it will display ‘no options’ if it does not exist already. Then click on ‘Create project’.
- Set the name as ‘Test-codebuild-project’ & select the Build type as “Single build”.
- Select the ‘Amazon Linux 2’ operating system for the CodeBuild project and create a new role for it.
- Select the Runtime as Standard with its latest version:
As we are using a containerized application, allow the following checkbox to build the docker images:
- Add Buildspec using the editor:
Output:
- Use ECR push commands for it and substitute the following with your repo commands:
Possible buildspec:
version: 0.2
env:
variables:
IMAGE_TAG: "latest"
# key: "value"
phases:
pre_build:
commands:
- echo $ENVIRONMENT
- echo Entered the pre_build phase...
- echo logging in docker hub
- docker login --username $DOCKERHUB_USERNAME --password $DOCKERHUB_PASSWORD
- echo Logging in to Amazon ECR...
- ACCOUNT_ID=${account_id}
- REPOSITORY_URI=${repository_url}
- aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com
build:
commands:
- echo Build started on `date`
- echo Building the Docker image as $ENVIRONMENT environment...
- docker build --build-arg ENVIRONMENT=$ENVIRONMENT -t $REPOSITORY_URI:$IMAGE_TAG .
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:$IMAGE_TAG
- echo Writing image definitions file...
- cd $CODEBUILD_SRC_DIR
- pwd
- printf '[{"name":"${container_name}","imageUri":"%s"}]' $REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
artifacts:
files: imagedefinitions.json
- Use the ECR push commands to write the Buildspec:
- Configure the CloudWatch Logs for the CodeBuild project and click on ‘continue with codepipeline’.
Output:
Now, the Codebuild project is ready.
- Goto the deploy stage, select the ‘Test-cluster’ & ‘Test-service’ where you need to deploy the changes whenever there’s a push request on the specified branch of the Git repository selected earlier. Whereas, ‘imagedefinitions.json’ contains the Codebuild artifacts.
- On the last step of the CodePipeline configurations, review the pipeline.
And click on the ‘create pipeline’.
After the creation of Codepipeline, when we hit the ‘release change’ button to trigger the pipeline manually. It will initiate the automated CICD process.
Note: Whereas, the pipeline will also automatically be triggered whenever there’s a change push into the attached GitHub repo through Webhooks configuration.
Output:
The CodePipeline’s Source stage is passed successfully. And the Build stage is just initiated:
Output:
- To view the build logs, click on ‘Tail logs’:
- The Build stage of the Codepipeline has been successful and it started the final deployment stage.
Output:
- The Deploy stage of the Codepipeline “Test-codepipeline” has been successful. So with this, it has completed the AWS Cloud Native Codepipeline CI/CD Automation process.
Multiple use cases can be integrated with the advanced CICD pipeline such as security checks, Role-Based Access Control, or automated testing integration with it. Utmost every popular cloud services provider allows us to work with it. It is needed and becoming an industry standard to implement deployment automation accordingly.