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