Update documentation to explain using Blue/Green Deployments
Problem to solve
We already support incremental rollout for Kubernetes, if you set the incremental rollout from 0% to 100% you are essentially doing blue/green deployment.
Our documentation currently states incremental rollout. https://docs.gitlab.com/ee/topics/autodevops/index.html#incremental-rollout-to-production-premium
We should add a section to the current documentation that explains to the users how to deploy using blue/green strategy in one-shot.
Intended users
DevOps engineers and developers in charge of deployment QA engineers testing the environment replica with the new version
Further details
Blue/ Green (or Red / Black) deployments In a blue/green deployment strategy (sometimes referred to as red/black) the old version of the application (green) and the new version (blue) get deployed at the same time. When both of these are deployed, users only have access to the green; whereas, the blue is available to your QA team for test automation on a separate service or via direct port-forwarding.
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"
After the new version has been tested and is signed off for release, the service is switched to the blue version with the old green version being scaled down:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
Proposal
Follow the guide here (doesn't require K8s)) - test it and add it to the documentation
What the gitlab-ci.yml file will look like:
stages:
- package
- deploy
- swap
package_backend:
stage: package
image: microsoft/dotnet:2.2-sdk-alpine
script:
- apk add --update zip
- dotnet publish $CI_PROJECT_DIR/src/backend/Backend.csproj -o $CI_PROJECT_DIR/dist
- cd dist
- zip backend.zip ./*
artifacts:
name: backend
paths:
- dist/backend.zip
tags:
- docker
package_frontend:
stage: package
image: alpine:latest
script:
- apk add --update zip
- mkdir dist
- mv src/frontend/* dist
- cd dist
- zip frontend.zip ./*
artifacts:
name: frontend
paths:
- dist/frontend.zip
tags:
- docker
deploy:
stage: deploy
script:
- DEPLOYMENT_ENV=$(curl -s https://staging.notkimsereylam.xyz/deployment_id)
- cd dist
# Deploy frontend to staging
- scp -qr ./frontend.zip notkl:~
- ssh notkl "unzip -o ~/frontend.zip -d ~/frontend"
- ssh notkl "sudo rm -rf /var/www/$DEPLOYMENT_ENV/frontend/*"
- ssh notkl "sudo mv ~/frontend/* /var/www/$DEPLOYMENT_ENV/frontend"
- ssh notkl "rm -rf ~/frontend*"
# Deploy backend to staging
- scp -qr ./backend.zip notkl:~
- ssh notkl "unzip -o ~/backend.zip -d ~/backend"
- ssh notkl "sudo rm -rf /var/www/$DEPLOYMENT_ENV/backend/*"
- ssh notkl "sudo mv ~/backend/* /var/www/$DEPLOYMENT_ENV/backend"
- ssh notkl "rm -rf ~/backend*"
- ssh notkl "sudo systemctl restart backend-$DEPLOYMENT_ENV"
variables:
GIT_STRATEGY: none
environment:
name: staging
url: https://staging.notkimsereylam.xyz
tags:
- blue-green
swap:
stage: swap
script:
- DEPLOYMENT_ENV=$(curl -s https://staging.notkimsereylam.xyz/deployment_id)
- ssh notkl "sudo ln -sf /etc/nginx/sites-available/$DEPLOYMENT_ENV /etc/nginx/sites-enabled/upstreams"
- ssh notkl "sudo systemctl reload nginx"
dependencies: []
variables:
GIT_STRATEGY: none
when: manual
environment:
name: live
url: https://notkimsereylam.xyz
tags:
- blue-green
Permissions and Security
Documentation
https://docs.gitlab.com/ee/topics/autodevops/index.html#incremental-rollout-to-production-premium
Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
https://www.weave.works/blog/kubernetes-deployment-strategies