Home

CI/CD Pipeline and Deployment

Overview

The nr-wrf project uses GitHub Actions for continuous integration and continuous deployment to OpenShift. The pipeline is designed to seamlessly move code from development through testing to production with appropriate approval gates.

At a high level:

1. Creating a PR will deploy that code to the delivery environment. Any further commits to that PR will migrate those commits to the dev environment.
2. Merging the PR into main will trigger deployment requests to test and production (each of which must be manually approved)

PR Pipeline Workflow

Phase 1: Pull Request Creation

When a developer creates a pull request:

1. PR Greeting - An automated greeting is posted to the PR itself with links to the deployment environment
2. Build Phase - The pipeline builds container images for both backend and frontend components
   • Images are tagged with the PR number (e.g., bcgov/nr-wrf/backend:123)
   • Images are pushed to GitHub Container Registry (GHCR)
3. Deploy to Dev - Automatic deployment to the development environment
   • Note that each PR creates its own deployment environment with its own URL. Once a PR is merged into main, the deployment environment is removed. This allows multiple instances to run in dev at the same time, each isolated from the other (thus the need for unique URLs)
   • Components deployed: backend, frontend, init (can be used for automated database migrations, if a database is added in the future)
   • Available at URLs like: https://wrf-{pr-number}-frontend.apps.silver.devops.gov.bc.ca/

Phase 2: PR Closure and Image Promotion

When the PR is merged to main:

1. Cleanup - Non-merged PRs trigger cleanup of dev environment artifacts
2. Image Promotion - If merged successfully, images are promoted from PR-tagged to test tag
   • This prepares images for the next phases

Phase 3: Main Branch Merge - Test Deployment

After merge to main, the merge-main workflow executes:

1. TEST Deployment (requires test environment approval)
   • Automatic trigger: Runs immediately when merge-main workflow executes
   • Requires approval: Uses GitHub environment secrets
   • Deploys with ZONE=test, indicating the environment the application is deployed to.
   • Promotes images from PR registry to test environment
   • Components deployed: backend, frontend, init

Phase 4: Main Branch Merge - Production Deployment

After test deployment succeeds:

1. PROD Deployment (requires prod environment approval)

   • Gated deployment: Only runs after test succeeds
   • Requires approval: Uses GitHub environment secrets for prod
   • Deploys with ZONE=prod
   • Promotes images from test to prod registry
   • Components deployed: backend, frontend, init

2. Image Promotion to PROD

   • Final step promotes container images from test tag to prod tag in GHCR

Approving Deployments to test/prod

Once a PR is merged into main, designated approvers can approve migrations to test, and then to production. PRs that are awaiting an approval are designated on the actions screen with a "time" icon:

Clicking on the action will display a button that approvers must click to promote the application to test and/or prod:

Deployment Environments and Architecture

Environment Levels

Environment	Trigger	Approval Required	Purpose
Dev	PR created	None	Developer testing, ephemeral
Test	Main merge	Yes (test)	QA and integration testing
Prod	Main merge	Yes (prod)	Production workloads

OpenShift Deployment Templates

The project uses OpenShift Template objects with parameterized YAML files:

• Backend: backend/openshift.deploy.yml
• Frontend: frontend/openshift.deploy.yml
• Init (Setup): common/openshift.init.yml

Required Secrets for Deployment

GitHub Actions Secrets

All secrets are configured at the GitHub repository level and are consumed by the GitHub Actions workflows.

Repository-Level Secrets

These secrets are required for both PR and main branch workflows:

Secret	Purpose	Example
OC_TOKEN	OpenShift authentication token	Kubernetes service account token
OC_SERVER	OpenShift API server URL	https://api.silver.devops.gov.bc.ca:6443
OC_NAMESPACE	OpenShift project namespace	{project-prefix}-{env}
GITHUB_TOKEN	GitHub token for GHCR access	Automatically provided by GitHub Actions

Environment-Specific Secrets

Additional environment secrets can be configured in GitHub for test and prod environments to override repository secrets if needed.

Note: The same OC_TOKEN, OC_SERVER, and OC_NAMESPACE are used across all environments (dev, test, prod). The ZONE parameter in the deployment templates distinguishes between environments.

Workflow Files

Main Workflow Files

1. .github/workflows/pr-open.yml

   • Triggers on: Pull request creation/update
   • Jobs: PR greeting, builds (backend/frontend), deployment to dev

2. .github/workflows/pr-close.yml

   • Triggers on: Pull request closure
   • Jobs: Dev cleanup, image promotion to test (if merged)

3. .github/workflows/merge-main.yml

   • Triggers on: Push to main branch
   • Jobs: Test deployment, prod deployment (gated), image promotion to prod

Deployment Parameters

OpenShift Template Parameters

Common parameters across deployment templates:

- NAME: wrf (project name)
- COMPONENT: backend | frontend (component name)
- ZONE: dev | test | prod (environment identifier)
- IMAGE_TAG: latest (or specific version)
- CPU_REQUEST: 25m
- MEMORY_REQUEST: 50Mi
- CPU_LIMIT: 75m
- MEMORY_LIMIT: 150Mi
- MIN_REPLICAS: 1-3 (HPA minimum)
- MAX_REPLICAS: 2-5 (HPA maximum)
- REGISTRY: ghcr.io (container registry)
- PROMOTE: bcgov/nr-wrf/{component}:{source-tag}
- DOMAIN: apps.silver.devops.gov.bc.ca

Environment-Specific Parameter Overrides

• Dev deployments: -p MIN_REPLICAS=1 -p MAX_REPLICAS=2
• Test/Prod deployments: Uses default values (3 minimum, 5 maximum replicas)

Promotion Flow

Developer Push
    ↓
PR Created → Dev Build & Deploy (bcgov/nr-wrf/{component}:{pr-number})
    ↓
PR Merged to Main
    ↓
Image Promotion: {pr-number} → test
    ↓
Main Merge Workflow Triggered
    ├→ Test Deploy (gated) - images from test tag
    ├→ Prod Deploy (gated) - after test succeeds
    └→ Image Promotion: test → prod

Key Implementation Details

• Concurrency Control: Workflows use concurrency groups to cancel in-progress runs when new pushes occur
• Docker Registry: GHCR for all images, with tag-based versioning
• Horizontal Pod Autoscaling: Configured via MIN_REPLICAS and MAX_REPLICAS parameters
• Network Policies: OpenShift NetworkPolicy objects created via init template
• Storage: Frontend uses NetApp file storage for persistent volumes