Skip to main content
In this tutorial, we’ll extend our GitHub Actions CI/CD pipeline to deploy Kubernetes manifests into a production environment. By cloning the existing dev-deploy and dev-integration-testing jobs, renaming them for production, updating manifest paths, and configuring environment protection, you’ll achieve a safe, repeatable deployment process.

Workflow Configuration

Begin by updating the workflow metadata, trigger conditions, and shared environment variables:

Production Deployment Jobs

Below is the new production deployment job, which depends on dev-integration-testing, runs against the production environment, and exports the ingress URL:
Next, add a job to validate the live endpoint via Curl and JQ:
Note: Ensure that vars.NAMESPACE, vars.REPLICAS, and secrets.MONGO_PASSWORD are defined in your GitHub repository settings or organization variables.

Job Overview

Here’s a quick breakdown of the full CI/CD pipeline:

Running the Workflow

After pushing these changes from a feature branch, GitHub Actions will schedule all jobs:
  1. unit-testing
  2. code-coverage
  3. docker
  4. dev-deploy
  5. dev-integration-testing
  6. prod-deploy
  7. prod-integration-testing
The image shows a GitHub Actions workflow interface with a series of jobs, including unit testing, code coverage, and deployment steps. The "prod-deploy" step has failed, indicated by a red cross.
Warning: Because the production environment has branch protection rules (only main allowed), any attempt to deploy from a feature branch will be blocked. Subsequent jobs in the workflow are skipped when this rule is not met.
The image shows a GitHub settings page for configuring deployment protection rules in a production environment, including options for required reviewers, self-review prevention, and a wait timer.
Any unmet protection rule halts the prod-deploy job and skips downstream steps. In the next lesson, we’ll cover how to configure approvals and satisfy these rules for safe, automated releases.

Watch Video