Continuous (Blue/Green) 1.3.

GitHub Actions Workflow

Deployment and Canary Testing for Blue/Green Deployment
Using GitHub Actions
Step 1: Define the workflow file
1. Blue/Green Deployment with (.github/workflows/deploy-blue-
GitHub Actions green.yml)
1.1. Prerequisites name: Blue/Green Deployment
1. Kubernetes Cluster on:
push:
(AKS/EKS): Set up a branches:
Kubernetes cluster in Azure - main
(AKS) or AWS (EKS).
jobs:
2. kubectl: Ensure kubectl is setup:
configured to interact with runs-on: ubuntu-latest
steps:
your cluster from within - name: Checkout code
GitHub Actions. uses: actions/checkout@v2
3. Docker Image: The
- name: Set up kubectl
application should be uses: azure/setup-kubectl@v1
containerized and hosted on with:
kubeconfig: ${{ secrets.KUBE_CONFIG
a container registry (e.g., }}
Docker Hub, Azure
Container Registry, AWS - name: Set up Helm (if using Helm charts
for deployment)
ECR). uses: azure/setup-helm@v1
1.2. Blue/Green Deployment
deploy_blue:
Overview runs-on: ubuntu-latest
 Blue Environment: Current needs: setup
production version of the steps:
- name: Deploy Blue version to
app. Kubernetes
 Green Environment: New run: |
kubectl apply -f blue-deployment.yaml
version of the app to be kubectl apply -f blue-service.yaml
tested and then promoted to
production. test_blue:
runs-on: ubuntu-latest
 Load Balancer/Service: needs: deploy_blue
Routes traffic between the steps:
- name: Test Blue Environment
Blue and Green run: |
environments. curl
http://blue-app.example.com/health
continue-on-error: true

deploy_green:
runs-on: ubuntu-latest
needs: test_blue
if: success()
steps:

1
 - name: Deploy Green version to service to route traffic to the
Kubernetes
run: | Green version.
kubectl apply -f green-  rollback_to_blue: If any
deployment.yaml
kubectl apply -f green-service.yaml
step fails (e.g., Blue health
checks fail), the traffic is
switch_traffic_to_green: switched back to Blue.
runs-on: ubuntu-latest
needs: deploy_green
if: success() 1.4. Deployment Files Example
steps:
- name: Switch Traffic to Green
1. Blue Deployment YAML
run: | (blue-deployment.yaml)
kubectl set selector service/myapp- apiVersion: apps/v1
service app=myapp,version=green kind: Deployment
metadata:
rollback_to_blue: name: app-blue
runs-on: ubuntu-latest spec:
needs: test_blue replicas: 3
if: failure() selector:
steps: matchLabels:
- name: Rollback to Blue app: myapp
run: | version: blue
kubectl set selector service/myapp- template:
service app=myapp,version=blue metadata:
labels:
app: myapp
Explanation of the Workflow: version: blue
 setup: Sets up the spec:
Kubernetes configuration containers:
- name: myapp
using the GitHub secret image: myrepo/myapp:blue
KUBE_CONFIG and ports:
- containerPort: 80
prepares Helm if necessary.
 deploy_blue: Deploys the
current stable version (Blue) 2. Green Deployment YAML
to the Kubernetes cluster. (green-deployment.yaml)
 test_blue: Runs health
apiVersion: apps/v1
checks to verify that the Blue kind: Deployment
deployment is functioning as metadata:
expected. name: app-green
 deploy_green: If Blue tests spec:
pass, the workflow deploys replicas: 0
selector:
the new version (Green) to
matchLabels:
Kubernetes. app: myapp
 switch_traffic_to_green: version: green
Updates the Kubernetes template:
metadata:
labels:

2
 app: myapp 2.2. GitHub Actions Workflow
version: green for Canary Testing
spec:
Step 1: Define the workflow file
containers:
- name: myapp (.github/workflows/canary-
image: myrepo/myapp:green deploy.yml)
ports: name: Canary Deployment
- containerPort: 80 on:
push:
3. Service YAML (myapp- branches:
- main
service.yaml)
jobs:
apiVersion: v1 setup:
kind: Service runs-on: ubuntu-latest
steps:
metadata: - name: Checkout code
name: myapp-service uses: actions/checkout@v2
spec:
selector: - name: Set up kubectl
app: myapp uses: azure/setup-kubectl@v1
with:
version: blue # Initially pointing to kubeconfig: ${{ secrets.KUBE_CONFIG
the Blue version }}
ports:
- protocol: TCP deploy_canary:
port: 80 runs-on: ubuntu-latest
needs: setup
targetPort: 80 steps:
type: LoadBalancer - name: Deploy Canary version to
Kubernetes
2. Canary Testing with GitHub run: |
kubectl apply -f canary-
Actions deployment.yaml
2.1. Canary Testing Overview
test_canary:
 Canary Deployment:
runs-on: ubuntu-latest
Deploy the new version to a needs: deploy_canary
small subset of users steps:
- name: Test Canary Environment
(canary pods) before fully run: |
rolling it out to the entire curl http://myapp-
canary.example.com/health
environment. continue-on-error: true
 Traffic Routing: Control the
traffic between the stable promote_canary:
runs-on: ubuntu-latest
version and the canary needs: test_canary
version using Kubernetes if: success()
steps:
ingress controllers like - name: Scale and Promote Canary to
NGINX or service weights. Production
run: |

3
 kubectl scale deployment myapp- replicas: 1
canary --replicas=3 selector:
kubectl set selector service/myapp- matchLabels:
service app=myapp,version=canary app: myapp
version: canary
rollback_canary: template:
runs-on: ubuntu-latest metadata:
needs: test_canary labels:
if: failure() app: myapp
steps: version: canary
- name: Rollback Canary spec:
run: | containers:
kubectl scale deployment myapp- - name: myapp
canary --replicas=0 image: myrepo/myapp:canary
kubectl set selector service/myapp- ports:
service app=myapp,version=blue - containerPort: 80
Explanation of the Workflow:
2. Service Definition for Canary Traffic
 setup: Prepares the Routing
Kubernetes environment Using an Ingress Controller or Service
annotations, you can control how traffic is routed
with the kubeconfig and to the Canary pods. For example, using NGINX
Helm (if used). Ingress for weighted routing:
 deploy_canary: Deploys the
apiVersion: networking.k8s.io/v1
new version to a limited kind: Ingress
number of pods (Canary). metadata:
name: myapp-ingress
 test_canary: Runs health
annotations:
checks to test the Canary nginx.ingress.kubernetes.io/canary: "true"
deployment. nginx.ingress.kubernetes.io/canary-
weight: "10" # 10% of traffic to Canary
 promote_canary: If the spec:
Canary deployment passes rules:
- host: myapp.example.com
tests, it scales the http:
deployment and routes traffic paths:
to the Canary version. - path: /
pathType: Prefix
 rollback_canary: If any test backend:
fails, the Canary deployment
service:
is scaled down, and traffic is
routed back to the Blue name: myapp-service

environment. port:
2.3. Canary Deployment File number: 80
Example
1. Canary Deployment YAML Conclusion
(canary-deployment.yaml) These workflows allow you to set up
apiVersion: apps/v1 automated Blue/Green and Canary
kind: Deployment
metadata:
Deployments with GitHub Actions for
name: myapp-canary Kubernetes-based applications. You can
spec: scale your services, test the new version,

4
and promote it to production based on the
results, all with automated testing and
rollback mechanisms.