Blue-green deployments

• Blue-green deployments

Blue-green deployments use two identical environments. While clients are using one active environment, you can update the other environment without interrupting the active environment. Then, when the other environment is ready, you set a load balancer to send client traffic to the updated environment. Updating environments in this way allows for zero-downtime deployments and keeps a second working environment ready at all times in case anything goes wrong with the active environment.

Rolling deployments
Rolling deployments update large environments a few nodes at a time. The setup for rolling deployments can be similar to blue-green deployments, but this time with a single logical environment.

Canary deployments
Canary deployments are deployments that start by updating a single node or a subset of nodes.
That way, you can test the update on a small subset of your system before you update every node.

https://www.ibm.com/support/knowledgecenter/en/SS4GSP_6.2.7/com.ibm.udeploy.doc/topics/app_process_advanced_ov.html

• Blue/Green (aka Red/Black) Deployment

In this approach we always manage 2 versions of our production environment. One of them is considered ‘blue’ – i.e this is the version that is now live. The new versions are always deployed to the ‘green’ replica of the environment. After we run the necessary tests and verifications to make sure the ‘blue’ environment is ready we just flip over the traffic, so ‘green’ becomes ‘blue’ and ‘blue’ becomes ‘green’.
https://codefresh.io/kubernetes-tutorial/continuous-deployment-strategies-kubernetes-2/