Whether it’s a startup or an established software company, they have a final environment which is solely for the end-users. This is known as production environment. It is encouraged that people just don’t login to the production environment and make changes.
After a developer has committed code in a repository, it can be built on Jenkins or CodeBuild. Once a build is successful, the code will become eligible to be placed in production environment. The series of steps one would need to take to run code is called deploying the code. The instructions to deploy code will vary a little.
As your application would grow, we would be running it on more number of servers. Let’s say your, code-deploy-app is currently running on 5 servers (server-1, server-2, and so on) then you would need to login to each one of them and place the new version of the app (every time a new feature is released). As we are reusing the servers, this strategy is called in-place deployment.
Side-Note:
Why to run your app on multiple servers?
If you are running app on a single server then by any chance it loses power, users would not be able to use your application. Just by running your app on one more server, you can withstand such event. But what if the data-center itself loses the power, what if the entire region loses the power? In order to make your services highly available you would need to run your services on multiple servers/data-centers/regions.
Using CodeDeploy, one can easily deploy to a virutal machine (a.k.a. EC2 in AWS), on any host, to Amazon managed container service (ECS). It can be also used to trigger an event via Lambda service.
Now imagine updating your app. Deployment tools such as CodeDeploy helps to solve this problem. If a deployment tool is correctly configured, you can have a new feature rolled out to all the servers with 0-downtime. Let’s say you ran into some error while deploying code then the tool would automatically stop the roll-out. It can be configured to even roll-back automatically.
Deployment Strategies
In case of the classic in-place deployment, the application gets redeployed to the same host. The other alternative is to cut-off traffic from few servers that are running version1 (let’s call them green group) of code-deploy-app, rollout version2 on completely different hosts (let’s call them blue group) and forward traffic to version2. Eventually, the traffic would be forwarded to new set of servers which are running version2 of the app (at this point, these hosts will become green group). This strategy of deploying application on new set of servers is called blue/green deployment (represents the transition from blue to green. More information can be found at https://en.wikipedia.org/wiki/Blue-green_deployment).
In either of the deployment strategy, you can define how fast/slow you want to rollout version2.
- You can rollout version2 all-at-once.
- Another strategy would be to introduce version2 to your deployment group one or X number of hosts at a time. We are basically introducing version2 in linear fashion.
- If you prefer to rollout version2 in 2 increments by rolling it out to X% of hosts in one-go and then upgrade the rest. This strategy is known as canary.
Standard deployment process
If we are running v1 of the app on 5 different servers then we would need to take following steps to roll out v2 to achieve upgrade with 0-downtine:
- Pick one/multiple hosts depending on the deployment strategy
- Block traffic going to the host — You might want to take some steps before & after you block the traffic — BeforeBlockTraffic, AfterBlockTraffic. In some cases, users would connect to the host via load-balancer.
- Stop the application — ApplicationStop
- Download newer versions — DownloadBundle
- Backup old version and/or Install dependencies — BeforeInstall — if package-A is needed to deploy the application then it doesn’t hurt to reinstall it, everytime the app gets deployed. If you run “yum install xyz@v3”, the yum-installer would install xyz if it does not exists; if it does then it won’t reinstall it.
- Install application — Install
- Make needed configuration changes —AfterInstall — let’s your your application now uses different database/needs some configuration files
- Start application — ApplicationStart
- Verify whether the application is working smoothly or not — ValidateService — a check can be as simple as just querying the service and making sure it returns HTTP-200 response
- Take some steps before/after allowing traffic to the host — BeforeAllowTraffic, AfterAllowTraffic
The details on each of the above steps can be found at https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
Side-note
It does not matter whether you run the application on a single host or on multiple hosts but one would take few of the steps mentioned in the above diagram. Imagine you outline all the steps needed to deploy your app in a file and deployment tool would use it to deploy your application.
Do I need to provide instructions on what to do when things go wrong? Here is a screenshot of how roll-back can be configured in Code-Deploy.
The automated process can run in various environment such as production, test, dev and so on. These end targets are also called Deployment Groups.
Few things to consider while setting up deployment
- What is the input to your deployment tool ? — CodeDeploy’s input would be either S3 or Github. This means build tool needs to place artifacts in S3 in order for CodeDeploy.
- What is the output of your deployment tool ? — Where would CodeDeploy deploy the application?
- How should the application be deployed? — Choose deployment strategy, also define the speed of deployment (linear, canary, all-at-once)
- What to do when deployment fails ? — Think about rollback options
References
- CodeDeploy trailer — https://youtu.be/Wx-ain8UryM
- CodeDeploy intro year 2015 — https://youtu.be/KzziRHOa5X4
- CodeDeploy getting started year 2015 — https://youtu.be/zHOQnTNxIKM
- CodeDeploy document — welcome.html
- Structure of AppSepc.yml — https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
- Modern deployment strategy year 2020 — https://youtu.be/-55YIDf0Z-E
- Canary release deployment — https://youtu.be/wbHXH8dzgyI
- Deployment groups — deployment-groups.html