Next, we’re going to show a blue/green deployment, which is handled by Armory’s traffic management capabilities. We’re going to gate the deployment with both a manual judgment and a wait stage. First let’s touch on what is a Blue Green Deployment.
A blue/green deployment is a deployment strategy in which you create two separate, but identical environments. The environments could be separate clusters of EC2 Instances, separate Kubernetes clusters, or deployments in Kubernetes running in different namespaces. The concept is one environment (blue) is running the current application version and one environment (green) is running the new application version. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic is directed to the green environment and the blue environment is deprecated.
For more information, you can read the Armory blog article Leverage Advanced Deployment Strategies to Change How You Ship Software. The blog post not only the options for doing Blue Green deployments, it describes Canary deployments and deployment strategies for features.
Navigate to “Pipelines” in Armory Enterprise UI
Click on the “Configure” button next to your pipeline (or click on “Configure” in the top right, and select your pipeline)
Add the Manual Judgment Stage:
Manual Judgment: Deploy to Prod
Please verify Staging and click 'Continue' to deploy to Prod
Add the Wait Stage:
Wait 30 Seconds
Notice how we now have two stages that “Depend On” the “Deploy Staging” stage. Once the “Deploy Staging” stage finishes, both of these stages will start. A stage can have one or more stages that depend on it.
Now we’re going to add the Kubernetes blue/green “Deploy Prod” stage
Deploy Prod
Notice how this stage depends on both the wait and manual judgment stages - it will wait till both are complete before it starts. A stage can depend on one more or stages.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: hello-today
spec:
replicas: 3
selector:
matchLabels:
app: hello-today
template:
metadata:
labels:
app: hello-today
spec:
containers:
- image: 'justinrlee/nginx:${parameters["tag"]}'
name: primary
ports:
- containerPort: 80
protocol: TCP
Notice that this manifest is different from the other two manifests - this is explained below.