Concepts for Rolling Deployment strategy for applications in production environment

Rolling deployment strategy follows wherein servers are taken out in a batch for deployment instead of deploying onto all servers at once. This helps in lowering the HTTP 5xx and other such issues when the traffic is high on the application and the deployment needs to be performed.

What Applications Qualifies for this Deployment:

• Applications running behind an Elastic load balancer.
• Application which have been moved to build and deploy model for NodeJS Applications (Wherein we build the deployment package once instead of doing on the fly compilation/installation)

Deployment Phases:

PreBuild:

• In this phase, the deployment script will gather all the active application servers running behind the load balancer, defining the server candidate for deployment.

PreDeploy:

• In this phase, as per the batch criteria set by the end user (defaults to 1), the rolling deployment will start onto the servers per batch number. In this, servers will be taken offline from the active load balancer and will wait until connection draining completes and then will start with the deployment by picking the latest build specific to service defined in the job.
• Before running deployment, it will check the _status call, if it succeeds with status code 200, deployment will be initiated else it will skip to another host.  (This is done to handle autoscaling instances or misconfigured boxes )
• In case, post running deployments steps, the script doesn't respond with status code 200 for _status call, the deployment will be halted and the servers taken out of ELB, have to be verified manually.
• The script waits for 60 seconds before making the call to _status call and if all goes well, the instance is registered back with the active load balancer and next batch deployment proceeds. 

PostCheck:

• In this phase, the script performs a timestamp check to ensure the latest code is deployed on all the servers post predeploy phase has been completed. In case, there is a mismatch, servers will be stopped gracefully and as a preventive measure, if the count for stopped instances increases goes beyond 3, the script will be halted and marked as FAILED.