A preproduction deployment should do more than confirm that a build starts. It should provide credible evidence that configuration, dependencies, data changes, security controls, observability, and rollback procedures are ready for release. This reusable preproduction environment checklist helps development and operations teams find environment-specific failures before production, with checks that can be adapted to a CI/CD pipeline, container platform, or infrastructure-as-code workflow.
Overview
Preproduction is most useful when it resembles production in the ways that affect release risk. Exact parity is not always practical: capacity, domain names, data volume, and third-party accounts may differ. The important question is whether the differences are documented, intentional, and covered by an appropriate test.
Use this release readiness checklist after a feature branch is merged, before a scheduled release, and whenever a service, integration, infrastructure module, or deployment process changes. Treat each item as a decision point rather than a formality. A failed check should produce an owner, a recorded decision, or a change to the release plan.
For a broader environment strategy, compare the responsibilities of development, preproduction, and production in Staging vs Preproduction vs Production. Teams using temporary environments can also review Ephemeral Environments for Pull Requests.
| Check | Development | Preproduction | Production |
|---|---|---|---|
| Application configuration | Fast local defaults are acceptable | Production-shaped values and documented exceptions | Approved, protected values managed through the release process |
| Dependencies | Mocks or shared development services may be used | Representative service versions, routes, and failure behavior | Production endpoints, capacity, and operational ownership |
| Data | Fixtures and disposable test data | Safe, representative, and access-controlled data | Production data with verified protection and recovery controls |
| Observability | Logs and local debugging are usually sufficient | Release smoke tests, dashboards, alerts, and trace coverage | Operational alerts, escalation paths, and incident procedures |
| Rollback | Reset or rebuild is often enough | Rollback artifact and database recovery path are tested | Approved rollback or roll-forward procedure with ownership |
Checklist by scenario
Before deploying an application change
- Confirm the artifact. Verify the image, package, or binary was built from the intended commit and passed required CI checks. Record the version or immutable identifier used in preproduction.
- Compare configuration. Check environment variables, configuration files, service URLs, ports, timeouts, retry settings, queue names, storage locations, and feature-flag defaults. Confirm that preproduction exceptions are documented rather than hidden.
- Validate secrets and permissions. Ensure the deployment can read only the secrets it needs and that credentials point to non-production systems unless a controlled integration requires otherwise. Do not place secret values in logs, manifests, or test reports.
- Check service dependencies. Confirm that databases, caches, message brokers, identity providers, payment sandboxes, email systems, webhooks, and external APIs are reachable. Test both successful responses and expected failure handling.
- Check certificates and DNS. Validate certificate chains, expiration handling, hostnames, redirects, callback URLs, ingress rules, and any allowlists. A service can appear healthy while an end-to-end flow fails because a callback or hostname is wrong.
Before a schema or data change
- Review migration order, locking behavior, expected duration, compatibility with the previous application version, and the rollback or roll-forward plan.
- Run migrations against a representative preproduction dataset where safe to do so. Confirm that indexes, constraints, defaults, and background backfills complete as expected.
- Verify that the application can operate during the transition if the release uses an expand-and-contract pattern. Do not assume a database rollback is equivalent to an application rollback.
- Confirm backups, restore instructions, ownership, and the definition of an acceptable recovery point before approving a high-risk data change.
For safe fixture handling, resets, and anonymization, see Preproduction Test Data Management.
Before a Kubernetes or container deployment
- Inspect image provenance, tags or digests, resource requests and limits, environment-specific manifests, rollout settings, probes, service selectors, ingress rules, and network policies.
- Confirm readiness and liveness probes represent actual service behavior. A process listening on a port is not necessarily ready to receive traffic.
- Test startup, scaling, termination, and dependency failure behavior. Review logs and events for scheduling, image-pull, permissions, and configuration errors.
Use the Kubernetes Deployment Troubleshooting Runbook when a workload does not become healthy.
Before approving release traffic
- Run smoke tests for authentication, the primary user journey, key API calls, writes and reads, asynchronous jobs, notifications, and any critical integration.
- Confirm dashboards, logs, traces, alert rules, and synthetic checks identify the new version and its failure modes.
- Verify the rollback artifact is available and that the team knows who can execute it. If using blue-green or canary delivery, define the promotion, pause, and abort conditions before the rollout begins.
What to double-check
Environment parity is usually lost at the boundaries between systems. Double-check the following areas before calling a deployment release-ready:
- Configuration source: Make sure the CI/CD job, deployment manifest, secret manager, and runtime all agree on which values should win. Look for stale variables left by an earlier release.
- Dependency versions: Confirm that preproduction is testing the intended database engine, runtime, base image, SDK, and managed-service behavior. Record meaningful version differences.
- Asynchronous work: Test queue permissions, consumer concurrency, retry limits, dead-letter handling, scheduled tasks, and duplicate-message behavior. A synchronous smoke test will not expose a broken worker.
- Data access: Check tenant boundaries, service accounts, row-level permissions, masking, and retention behavior. Test with roles that resemble real users, not only an administrator account.
- Operational evidence: Capture deployment logs, migration output, test results, health checks, and known warnings. A green pipeline is not a substitute for reviewing evidence from the environment.
- Rollback compatibility: Ask whether the previous application version can read data written by the new version. If not, document a roll-forward strategy and ensure the release owner understands it.
Where possible, automate repeatable checks as CI/CD quality gates. The guide to CI/CD Pipeline Quality Gates provides a useful framework for deciding which checks should block promotion and which should create a review task.
Common mistakes
- Testing only the happy path: A successful login and page load do not validate timeouts, retries, expired credentials, failed dependencies, or partial outages.
- Using unrepresentative data: Empty tables can hide query performance, pagination, validation, and migration problems. Use safe data that reflects important shapes and edge cases.
- Allowing manual drift: A one-off console change may fix preproduction temporarily while making the next deployment unpredictable. Capture durable changes in version-controlled configuration or infrastructure as code.
- Sharing production credentials: This increases blast radius and makes test activity difficult to distinguish from real operations. Use scoped, environment-appropriate identities.
- Ignoring background processes: Workers, cron jobs, event consumers, and notification services need their own readiness checks and monitoring.
- Skipping rollback rehearsal: A rollback plan that has never been verified may fail because of schema changes, unavailable artifacts, permissions, or traffic-routing assumptions.
- Treating approval as evidence: A sign-off should reference test results, known risks, owners, and a decision. It should not merely confirm that someone clicked through a workflow.
If a pipeline fails during validation, use a log-first investigation rather than repeatedly rerunning the job. See CI/CD Pipeline Failure Troubleshooting for a structured approach.
When to revisit
Review this checklist before each meaningful release, not only during major launches. Revisit it after adding an external integration, changing authentication, modifying a database schema, introducing a new deployment target, upgrading a runtime or container base image, changing DNS or certificates, or altering feature-flag behavior.
Schedule a broader review before seasonal planning cycles and after any incident or preproduction failure that reveals an environment-specific gap. Update the checklist when workflows, cloud services, CI/CD integrations, infrastructure modules, security controls, or team ownership change. Remove checks that no longer reduce risk, and add explicit checks for newly discovered failure modes.
To use this checklist in the next release, copy it into the team’s pull request or release record. Assign an owner to each non-trivial item, attach evidence for migrations and smoke tests, record known differences between environments, and make the final decision explicit: promote, delay, or proceed with a documented exception. That small discipline turns preproduction from a last-minute gate into a reliable part of the release process.
