CI/CD Pipeline Specification Template

Target under 15 minutes for the full cycle from push to production deployment readiness. Under 10 minutes is excellent. Over 30 minutes and developers will start batching changes, which defeats the purpose of continuous integration. Optimize by parallelizing test suites, caching dependencies, and using incremental builds. Track pipeline duration as a [team metric](/glossary/prioritization) and set alerts when it exceeds your target.

Auto-deploy if your test coverage is high, your monitoring catches issues quickly, and you have automated rollback. Manual approval if you are in a regulated industry, your test suite has known gaps, or deployments require coordination across teams. Many teams use a hybrid: auto-deploy for low-risk changes (behind feature flags) and manual approval for database migrations or breaking API changes.

Run migrations as a separate, ordered step before the application deployment. Migrations should be backward-compatible (the old code should work with the new schema) so you can roll back the application without rolling back the migration. Use the [database migration template](/templates/database-migration-template) for planning schema changes.

80% line coverage is a reasonable starting point for most teams. Below 70% and you are likely shipping untested code paths. Above 95% and you are probably writing tests that do not add value (testing getters and setters). Focus coverage requirements on critical paths (authentication, payments, data mutations) rather than hitting a blanket number.

Never store secrets in code, environment files, or pipeline configuration files. Use a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets for CI). Rotate secrets quarterly. Audit secret access logs monthly. The [Technical PM Handbook](/technical-pm-guide) covers security practices for technical PMs. ---