GitHub Actions Certification
Continuous Deployment with GitHub Actions
Modify Dev Deployment Job to use Environment tags
In this lesson, we’ll enhance our GitHub Actions workflow by updating the dev-deploy job to leverage environment tags. By specifying an environment:
- You can enforce protection rules (e.g., required approvals or wait timers).
- Access environment-scoped secrets and variables.
- Surface the deployment URL directly in the GitHub UI.
Prerequisites: Review Your Environment
First, recall the development environment configuration. It includes one protection rule, one secret, and two variables. Environment-scoped variables always take precedence over repository-level variables.

Note
Environment-level variables override repository variables. This ensures you can customize settings (like replica counts) for each deployment stage.
Next, compare the repository-level variables (e.g., replicas: 2) against the environment-level variables (replicas: 1):

| Scope | Definition | Priority |
|---|---|---|
| Repository | Variables and secrets at the repo level | Lower |
| Environment | Variables and secrets scoped to env. | Higher |
Verify Current Deployment
Use kubectl to inspect your deployments and pods in the development namespace:
kubectl -n development get deployments.apps
# NAME READY UP-TO-DATE AVAILABLE AGE
kubectl -n development get pods
# NAME READY STATUS RESTARTS AGE
# solar-system-6db5d5dfb8c-96qcz 1/1 Running 0 26m
# solar-system-6db5d5dfb8c-psbxx 1/1 Running 0 26m
Currently, the solar-system deployment uses two replicas (from the repository variable). We want to switch this to the environment variable value (1 replica) by invoking the development environment in our workflow.
Update the Workflow
To enforce environment protections and show the deployment URL in the workflow summary, add an environment block under the dev-deploy job:
env:
MONGO_URI: mongodb+srv://supercluster.d83ji.mongodb.net/superData
MONGO_USERNAME: ${{ vars.MONGO_USERNAME }}
MONGO_PASSWORD: ${{ secrets.MONGO_PASSWORD }}
jobs:
unit-testing:
# ...
code-coverage:
# ...
docker:
# ...
dev-deploy:
needs: docker
environment:
name: development
url: https://${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}
outputs:
APP_INGRESS_URL: ${{ steps.set-ingress-host-address.outputs.APP_INGRESS_HOST }}
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Install kubectl CLI
uses: azure/setup-kubectl@v3
with:
version: 'v1.26.0'
- name: Set kubeconfig context
uses: azure/k8s-set-context@v3
with:
method: kubeconfig
# ... additional deployment steps ...
Commit and push these changes to trigger a new workflow run.
Warning
After this change, the dev-deploy job will pend if the environment has protection rules (e.g., a wait timer or approval). Administrators must review and approve to proceed.
Approving the Pending Deployment
Once the workflow hits the dev-deploy job, you’ll see it pending due to environment protection:

Click the pending job to reveal the protection rule and remaining wait time. Administrators can bypass the wait by adding a comment:

After approval, the dev-deploy job runs. Upon success, the deployment URL appears in the workflow summary:

By clicking this URL, stakeholders can quickly verify the live application.
View Deployments Across Environments
GitHub’s public beta for deployment tracking offers a centralized overview of deployments across all environments. Access it via Actions > Deployments in your repository:

This dashboard displays each deployment event along with environment name, branch, commit, and duration. Learn more on the GitHub blog announcement.
![]()
With environments configured in your GitHub Actions workflow, you can enforce rules, manage scoped secrets and variables, and prominently display deployment URLs for fast verification.
Links and References
Watch Video
Watch video content