How to Build a Zero-to-One Canary Release Pipeline with Nginx and Jenkins

Introduction

Canary (gray) release, also known as canary deployment, uses a small group of users to validate new features before a full rollout. The article presents a hands‑on tutorial for building a complete canary deployment pipeline, aimed at junior front‑end developers interested in engineering practices.

1. Server Preparation

Two servers (or two ports on a single server) are needed so that each can host a different version of the application. If you have no servers, you can purchase two cloud instances; a minimal demo costs about ¥20.

Cloud‑server setup guide: https://github.com/TerminatorSd/canaryUI/blob/master/HuaWeiCloudServer.md

Tool Installation

Install Git, Nginx and Jenkins on each server.

yum install git

sudo yum install nginx

service jenkins start

Verify Nginx installation with nginx -t and start it using nginx or nginx -s reload. Access the server’s public IP to confirm the default Nginx page is displayed.

2. Code Preparation

Two different builds of an Angular application are required. Install Angular CLI, create a project, and build it twice with different titles to distinguish the versions.

npm install -g @angular/cli

ng new canaryDemo

cd canaryDemo

ng serve

Change src/index.html title to A-CanaryDemo, build with ng build --prod, then repeat the process with title B-CanaryDemo. The two dist folders become the “old” and “new” code bases.

ng build --prod

3. Nginx Configuration

Upload the A-CanaryDemo build to /var/canaryDemo on both servers. Edit /etc/nginx/nginx.conf to add upstream groups and a map that routes traffic based on a canary cookie.

# Canary Deployment
map $COOKIE_canary $group {
    ~*devui$ server_canary;
    default server_default;
}

upstream server_canary {
    server 11.11.11.11:8000 weight=1;
    server 22.22.22.22 weight=1;
}

upstream server_default {
    server 11.11.11.11:8000 weight=2;
    server 22.22.22.22 weight=2;
}

server {
    listen 8000;
    root /var/canaryDemo;
    location / { index index.html; }
}

server {
    listen 80 default_server;
    root /var/canaryDemo;
    location / { proxy_pass http://$group; }
}

4. Defining the Canary Strategy

The strategy uses a cookie named canary. When its value is devui, traffic is sent to the canary upstream; otherwise it goes to the default upstream.

5. Jenkins Automation

Create three FreeStyle Jenkins jobs on the A‑side server:

Canary_A : Deploy new code to A, modify Nginx so that canary traffic goes to A.

Canary_AB : Deploy code to B and switch canary traffic to B.

Canary_B : Remove comments so that traffic is evenly split between A and B.

Each job runs a shell script that pulls the latest code, copies the dist folder to /var/canaryDemo, and updates nginx.conf with sed commands.

# Example for Canary_A
git pull
rm -rf /var/canaryDemo
scp -r dist /var/canaryDemo
sed -i 's/server 22.22.22.22 weight=1/# server 22.22.22.22 weight=1/' /etc/nginx/nginx.conf
sed -i 's/server 11.11.11.11:8000 weight=2/# server 11.11.11.11:8000 weight=2/' /etc/nginx/nginx.conf
nginx -s reload

Similar scripts are used for the other two jobs, adjusting the sed patterns to comment or uncomment the appropriate upstream lines.

Conclusion

The guide demonstrates how to build a canary release environment from zero, covering server setup, code preparation, Nginx traffic routing, and Jenkins automation. While the demo is minimal, real‑world DevOps pipelines would also integrate build verification, security scanning, and automated testing.