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