Gnu Group Learning AcademyGnu Group ↗
CI/CD Fundamentals · Module 08 of 12

Environments, approvals and concurrency

Protect deployments with environment-specific controls, deliberate promotion and concurrency rules that prevent overlapping releases.

Learning objectives

By the end of this module, you should be able to:

  • Explain what a deployment environment represents.
  • Use approval/protection concepts for sensitive environments.
  • Prevent two deployments from racing against the same target.

Environments separate deployment policy

GitHub environments can associate deployment targets with secrets, variables and protection rules. Production controls should be stronger than ordinary CI validation.

Approval is a policy decision, not a rebuild

A manual promotion should approve the already-validated artifact. Rebuilding after approval creates a new unvalidated set of bytes.

Concurrency protects shared targets

A concurrency group can prevent overlapping workflow or job executions for the same deployment target. Depending on policy, a newer run can queue or cancel an older in-progress run.

Worked examples

See the idea in practice.

Production deployment shape

environment: production
concurrency:
  group: production-deploy
  cancel-in-progress: false
  • The environment provides a policy boundary.
  • The concurrency group serializes production deployment work.
Hands-on lab

Lab — Serialize a simulated deployment

Goal: Use a filesystem lock to model why only one production deployment should mutate a target at a time.

STEP 1

Create deploy script

mkdir -p ~/gnu-cicd-labs/module08 && cd ~/gnu-cicd-labs/module08
cat > deploy.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
exec 9>deploy.lock
flock -n 9 || { echo 'deployment already in progress'; exit 20; }
printf 'deploying %s\n' "${1:-unknown}"
sleep 1
printf '%s\n' "${1:-unknown}" > deployed.txt
EOF
chmod +x deploy.sh
STEP 2

Run a deployment

./deploy.sh build-001
STEP 3

Verify target

grep -q 'build-001' deployed.txt
STEP 4

Map to Actions

printf '%s\n' 'concurrency group: production-deploy' 'environment: production'

Verify

  • A deployment records the selected build identifier.
  • The lab explains serialization of a shared target.

Expected outcome

  • Promotion state is controlled separately from build creation.

If it fails

  • flock is available on common Linux distributions; on other systems use an equivalent locking primitive.
  • In GitHub Actions, inspect the concurrency group and environment protection configuration if runs are unexpectedly queued.
Real-world connection

Serialized production deployments prevent two independently valid changes from corrupting shared rollout state.

Avoid these traps

Common mistakes

  • Rebuilding after a production approval.
  • Sharing production secrets with every CI job.
  • Allowing concurrent deployments to mutate the same target without a defined strategy.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What should a manual promotion approve?

The already-built and validated artifact, not a fresh rebuild.

2Why use deployment concurrency?

To prevent overlapping runs from racing while mutating the same environment.

3What can a GitHub environment provide?

A deployment policy boundary with environment-specific variables/secrets and protection rules where configured.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.