Sample CI/CD pipeline using AWS CodePipeline

Lately I created a sample AWS CI/CD pipeline with a demo ReactJS application. It automates the basic phases of continuous integration and delivery/deployment.

I have used below AWS services
• Pipeline services: CodePipeline, CodeBuild, CodeDeploy
• Compute platform: Elastic Compute Cloud or EC2
• Storage service: S3
• Event/Log/Alert: CloudWatch
• Notification: SNS

For code repository I have used GitHub. Though I explored AWS’s CodeCommit (AWSs own private version control service) and it has a lot of features, hence it can be used to but based on your requirement.

A glimpse of the pipeline:

Design: Please find a flow diagram below.

1. CodePipeline will be triggered through GitHub Webhook as soon as developer pushes code in respective branches or code merge happens.
2. CodeBuild will internally create a docker container instance, download and install all dependencies for build.
3. CodeBuild will test/build the code based on the configuration in buildspec.yml
4. EC2 instances to be created and CodeDeploy agent installed in it along with the other configurations
5. CodeDeploy will retrieve artifact and deploy in EC2 instance based on the instructions mentioned in appspec.yml
6. All the artifacts will be saved and retrieved in/from Amazon Simple Storage Service (S3)
7. CloudWatch will take care of Logs, Events, Alerts, Metrics etc.
8. Email will be sent for success/failure status using SNS

With this pipeline solution we can achieve:

Rollback – as soon as a deployment fails automatically rollback to last stable version will happen. Alarm setting can be created based on different parameters. For example, I have created CPU utilisation on EC2 instances. Roll back can be integrated with alarm and it will be triggered when alarm thresholds are met

Customized deployment - Deployment configuration can be customized to determines how fast application is deployed and the success or failure conditions for a deployment. There are few pre-defined values like ‘OneAtOnce’, ‘HalfAtOnce’, ‘AllAtOnce’ etc. Custom configs can be created, like this one, to specify minimum number or percentage of healthy Amazon EC2 instances that must be available at any time during the deployment.

Blue-Green Deployment – This deployment pattern can be achieved where latest version will be installed on new set of instances with help of EC2 auto scaling group. CodeDeploy then reroutes load balancer traffic to the new set of instances running the latest version. After traffic is rerouted to the new instances, the existing instances can be terminated. Blue/green deployments allow to test the new application version before sending production traffic to it. If there is an issue with the newly deployed application version, it can be rolled back to the previous version faster than with in-place deployments. Additionally, the instances provisioned for the blue/green deployment will reflect the most up-to-date server configurations since they are new.
Canary/Linear deployment – This is available for Lambda (serverless) with CodeDeploy. There are predefined values like ‘LambdaCanary10Percent5Minutes’ (for the new lambda version, 10 percent of the traffic will be routed to canary, and then the rest traffic will be routed) does traffic shifting in 2 increments whereas ‘LambdaLinear10PercentEvery1Minute’ (every 1-minute 10 percent more traffic will go for new version deployed) does that incrementally.

Please let me know your thoughts.