Environments & deploys

Safe releases come from clear environments and a boring deploy pipeline. This guide explains environment types, the deploy pipeline, approvals, and rollbacks on Build Me Web cloud hosting.

Environment types

Preview environments spin per branch or pull request so reviewers see the real build. Staging holds integrated QA against shared services. Production serves live traffic and should be protected.

Keep configuration keys identical across environments; only values differ. That discipline prevents missing env vars at promote time. Preview must stay non-indexable and should use sandbox payment and email providers.

1. Create production with the canonical hostname.
2. Enable preview builds for pull requests.
3. Add staging when multiple teams need a durable shared target.
4. Document who owns secrets for each environment.

preview  → ephemeral URLs, noindex, sandbox deps
staging  → shared QA, longer lived, prod-like data (anonymized)
production → protected promote, live deps, monitoring on

Deploy pipeline

Build test health check promote. Attach lint, unit tests, smoke tests, and Core Web Vitals budgets where relevant so regressions fail early. Artifact immutability matters: promote the same build you tested, do not rebuild for production with different dependency resolution.

Cache dependencies, fail closed on secret scanning, and publish build logs to a place the team can search. For apps, run migrations in an expand-contract pattern compatible with blue-green.

• Static sites: build output hashed; purge HTML entry points on publish.
• Servers: health checks must pass before traffic shift.
• Mixed: keep CDN and origin versions aligned during cutover.

Approvals

Production deploys can require a second approver on Managed and Enterprise plans. Use deploy windows for high-traffic storefronts and regulated releases. Approvals should reference a checklist (migrations, feature flags, comms) not just a rubber stamp.

Emergency hotfixes still need a recorded approval after the fact and a blameless review. Prefer feature flags to turn off bad behavior without a full rollback when safe.

Rollbacks

Previous artifacts stay warm for a configurable window. Rollback is a traffic shift, not a rebuild from scratch. Practice it on staging so muscle memory exists before an incident.

• Rollback owner named for each release
• Prior artifact retention meets your RTO
• Comms template ready for customer-facing incidents
• Data migrations reversible or forward-fixed

Troubleshooting

Preview green, production red: secret drift or data shape differences — compare vault keys and migration versions.

Stuck approving: check required reviewers and deploy window calendar.

Rollback incomplete: CDN HTML cache — purge entrypoints after traffic shift.

Prerequisites & preparation

Before changing production settings for environments and deploys, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.

Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.

Define preview, staging, and production owners; list required checks before promote.

Detailed walkthrough

Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.

1. Ensure config keys match across environments with different secret values.
2. Attach lint/tests/smoke and vitals budgets to the pipeline.
3. Configure approval rules and deploy windows for production.
4. Practice rollback on staging as a traffic shift.
5. Annotate releases and keep prior artifacts for your RTO window.

Edge cases & failure modes

Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.

• Config key drift between preview and production.
• Health checks that only hit static HTML.
• Migrations incompatible with blue-green overlap.

QA checklist before you announce

• Happy path verified on mobile and desktop
• Failure path messaging reviewed
• Owners named for the first hour after launch
• Rollback or freeze path documented

Operating the change

After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.

Emergency hotfixes still get recorded approvals and a short review afterward.

Promote the artifact you tested — do not rebuild production with a different dependency graph.

Preview must stay noindex and on sandbox providers even when data looks production-like.

Approval checklists beat rubber stamps: migrations, flags, comms, monitoring.

Rollback runbooks belong next to deploy runbooks, not in someone’s head.

Staging exists to find integration bugs; empty staging databases hide permission errors.

Deploy windows protect high-traffic storefronts — calendar them with marketing.

Implementation checklist

Confirm identical config keys across environments on preview before you promote. Name who approves the change, which environment is authoritative, and what “done” looks like in measurable terms.

Document noindex and sandbox rules on preview where the team already looks — workspace notes or the engineering handbook — not only in a meeting memory.

Rehearse artifact immutability through promote against written acceptance checks. If you cannot name the verification event (order, DNS lookup, deploy health, or signed API call), you are not ready to announce.

Measure approval checklists beyond rubber stamps with anonymized but realistic data, and keep logs, headers, or screenshots for at least one release cycle so regressions have a baseline.

Operating it with your team

Automate rollback drills on staging so the next teammate can repeat the path without tribal knowledge. Prefer vaulted secrets over chat paste, and archive temporary exceptions with an end date.

Review deploy windows for peak storefronts when two tools disagree. Pick a source of truth in advance so incidents do not burn the rollback window debating dashboards.

Validate release annotations on dashboards before paid traffic or customer emails amplify mistakes. Capture request IDs or screenshots for support if anything looks off.

Schedule a follow-up on migration compatibility in dual-version windows after launch, update the runbook when reality differs from the doc, and assign a named owner for the first hour.

When you finish this guide, you should be able to explain the happy path, the abort path, and the metrics that prove success. If any of those are fuzzy, revisit the walkthrough with your teammates before you scale traffic, spend, or automation.