DailyRNG
Login
Master

Staging and environments

Good pipelines send code through environments: test, staging, then production. Each step is a safer gate.

What you will see

Approval gate before production: Auto deploy to staging: Yes Auto deploy to production: No (waits for human) Environment-specific config: config.test.json -> test database config.staging.json -> staging database

The full result is shown at the end of the exercise below.

About 1 min of reading

Quick check

Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.

Try It

A mature pipeline sends code through test, staging, then production, with a human approval gate before the most sensitive deploy. Each environment points at its own database and level of protection from a single build.

1

I walk a single build through three environments, printing each one's database and auth level to show one build producing three different deployments.

print("Staging and environments") deployments = { "test": "test database, no auth", "staging": "staging database, fake auth", "production": "production database, real auth", } for e in ["test", "staging", "production"]: print("Deploy to %s -> %s" % (e, deployments[e]))

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Staging and environments Deploy to test -> test database, no auth Deploy to staging -> staging database, fake auth Deploy to production -> production database, real auth
Staging should look exactly like production. A bug that staging cannot reproduce will almost always reach real users, which is exactly what the staging gate exists to prevent.
2

I show that staging deploys automatically but production waits for a human approval, and print the three environment-specific config files that one build selects.

print("Approval gate before production:") print("Auto deploy to staging: Yes") approved = False print("Auto deploy to production: %s" % ("Yes" if approved else "No (waits for human)")) print() print("Environment-specific config:") print("config.test.json -> test database") print("config.staging.json -> staging database") print("config.prod.json -> production database")

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Approval gate before production: Auto deploy to staging: Yes Auto deploy to production: No (waits for human) Environment-specific config: config.test.json -> test database config.staging.json -> staging database config.prod.json -> production database
A manual gate costs a click but stops accidental releases to real users. The rest of the pipeline stays automatic; only the most sensitive step waits for a person.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Code flows through test, staging, and production, with approval gates between the risky steps.
1 Deploy to test
↓
2 Deploy to staging
↓
3 Approve release
↓
4 Deploy to production
Why this works
More environments

Each environment is a safer gate. Test proves it works. Staging proves it works under load. Production is the final step.

Manual gates

Put a human approval before production. This stops accidental releases while keeping the rest automatic.

Examples

A safe deploy path

test server  -->  staging server  -->  production
  (all devs)      (fake users)         (real users)

Staging looks exactly like production. Bugs found here never reach real users. This staged path is the mark of a mature pipeline.

Approval gate before production

- name: Deploy to prod
  environment: production
  run: ./deploy.sh --env prod

The environment: production block requires a human to click Approve before the job runs. Staging and test can deploy automatically, but the most sensitive gate waits for a person.

Environment-specific config

config.test.json     -> test database, no auth
config.staging.json  -> staging database, fake auth
config.prod.json     -> production database, real auth

The workflow picks the config that matches its environment. One build, three deployments, each pointed at the right database and the right level of protection.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← Security in the pipeline
Previous Lesson
Security in the pipeline
Next Lesson
Monitoring and rollback
Monitoring and rollback →