A deployment target is the environment your code goes out to — development, staging, production, sandboxes for specific customers. Defining targets clearly makes releases predictable and rollbacks straightforward.
Typical Target Set
- Development: Auto-deploys from main on every commit. Developers' shared playground.
- Staging: Pre-production; closely mirrors prod config; final review before release.
- Production: The live customer-facing system.
- Per-customer sandboxes: For enterprise customers who need their own staging.
- Per-feature preview: Ephemeral environments spun up per PR.
Target Configuration
- Source: Branch / tag / commit SHA.
- Trigger: Push, manual, scheduled.
- Approvers: Who can authorise (production typically requires two).
- Environment variables: Per-target config (Stripe keys, DB credentials).
- Feature flags: Per-target flags for testing in staging without affecting prod.
- Health checks: Post-deploy verification.
- Rollback strategy: Blue/green, canary, replace.
Worked Examples
- Small startup: Three targets — dev, staging, production. Manual approval for production from a designated owner.
- Mid-size SaaS: Dev (auto), staging (auto from release branches), production (manual). Plus 5 enterprise customer sandboxes.
- Marketplace: Dev, staging, production, plus PR-preview environments for designers to review UI changes.
- Healthcare: All deploys require two approvers; staging is structurally identical to prod; rollback tested quarterly.