Infrastructure as a code is not something which I imagined when I started my career back in 2003. IT infrastructure has moved from hardware to software, slowly but surely. Usually, DevOps automation applies to the CI/CD source code pipelines. But infrastructure as a code has unveiled a huge and lots of scope in terms of automating the infrastructure deployments as well. We are taking this opportunity to discuss the same with reference to Amazon Web Services. Itʼs not that we are ignoring other providers, it is just that 90% of our expertise in this field is acquired on AWS infrastructure.
#1. AWS service configuration as a code
#2. Deployment pipeline includes one or more steps below
#3. Test runners to automate the code testing (e.g.: Junit, Nunit, Cucumber)
#4. Build source code (e.g.: Maven)
What is the difference between CI (Continuous Integration) and CD (Continuous Delivery)?
CI is building your code and running all tests on every code commit. We start by making a change to the code, unit tests are done on the new codes and once they pass successfully, its merged to the codebase. Using this method is convenient for any reasons, any broken codes can be identified before they reach the codebase and the errors can be identified at the very initial stage.
CD is CI + having the ability to deploy your continuously integrated code to a production environment in a fully automated fashion.
Benefits of CD
Automate Software release process and deliver updates faster Improve developer productivity and Improve code quality.
The general pattern for CI/CD pipelines
Step 1 : Source where developer commit changes.
Source Control Systems like VSTS and TFS for Microsoft projects from Microsoft itself and Github, subversion etc for Open Source projects. Database Schema management is also a part of Continuous delivery where the database schema is also versioned and checked in properly to the source control systems. Either you have to change the database schema first or the last depending on the granularity of your system. Sometimes you need to make the additions to your database schema before you start deployment and deletions in your database schema after the successful deployment. Database schema management is a painful process and would often cause issues if not done properly.
Step 2 : Build where changes are built and run unit tests (e.g.: Grunt for Node.js, TDD/mocha, and BDD/chai)
Step 3 : Staging where the code is deployed and tested (there could be various staging levels where there are different testing also involved like integration tests, load test etc)
Step 4 : Production where the code is deployed to public servers
AWS Pipeline for Continuous Deployment
Application code / Infrastructure Code => SourceControl (CodeCommit) => Build (CodeBuild) => Staging (CodeDeploy / CloudFormation) => Production (CodeDeploy / CloudFormation)
Deployment types
Method -> Deploy in place, Rolling, Rolling with additional batch, Immutable, Blue/Green
All at once/Deploy in place: The application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started and validated.
Rolling: A single batch is moved out of service and is upgraded to the latest version.
Rolling with additional batch: Similar to Rolling, but new instances are created with an updated application.
Immutable: The updates which ensure that configuration changes that require replacing instances are applied efficiently and safely.
Blue/green: New instances are deployed for replacement, and are updated with the latest application. An optional wait time is given for, testing. Once the process is completed the traffic is routed to the new instances. The older set of instances are later, updated or terminated if not used.
