Key takeaway
Give every change fast, explainable checks, keep release rules in code and protect pipeline credentials as production assets.
CI, continuous delivery and deployment are distinct stages
Continuous Integration frequently merges changes into a shared repository and runs a build and tests for each commit. Continuous Delivery keeps a validated artifact ready for release to staging or production; Continuous Deployment may release changes automatically after defined checks pass. Document which meaning your team intends by “CD.” Promote the same validated artifact through stages to avoid differences from rebuilding.
| Stage | Primary job | Output |
|---|---|---|
| CI | Build, unit/integration and security checks | Validated artifact and fast feedback |
| Continuous Delivery | Prepare artifact for promotion to environments | Approval or release decision |
| Continuous Deployment | Automatically release changes that pass | Automated production release |
Add security to early checks
Small commits speed up builds, tests and review. Add SAST, dependency/SCA checks, secret scanning and IaC/container configuration scanning alongside unit and integration tests at suitable stages. Automate checks for authorization, schemas, sensitive operations and error cases. Schedule DAST and penetration testing in running environments; commit scans do not fully cover runtime behavior or real workflows. Return findings with actionable explanations and code context.
Commit and build
Confirm the code builds and static rules pass.
Test and scan
Check workflows, code, dependencies, secrets and IaC.
Artifact and release
Sign the artifact, attach provenance and test results, then promote it by stage.
Policy as code makes rules repeatable
Define policies in testable text files, keep their history in version control and review changes in pull requests. Rules may require minimum identity permissions, forbid public storage, define approved base images, require test evidence and set conditions for production promotion. A policy engine can test rules in CI and stop a merge or deployment that violates them. Record the reason, scope, owner and expiry for exceptions, and test the policies themselves as they change.
Code and dependencies
Rules check licenses, vulnerabilities and secrets.
Infrastructure as Code
Validates network, identity, storage and encryption settings before deployment.
Release policy
Defines approvers, required evidence and when an exception expires.
Protect the pipeline as a production system
CI runners execute source code and packages, sometimes with production credentials; compromise can poison a build artifact and provide a path into production. Give each job a separate least-privilege identity, use short-lived credentials, mask secrets and plan rotation. Isolate untrusted pull requests from privileged runners and secrets; isolate build environments, pin third-party action and plugin versions, and verify provenance. Sign artifacts, then verify signature and source at deployment. Audit pipeline changes, credential use and unusual runner behavior.
Monitor feedback and release health
Track build duration, flaky tests, failed merges, security findings and remediation time. Noisy checks erode team trust; investigate results and tune the rule instead of removing it. Use a staged rollout to limit the impact of a new release. After release, monitor application errors, latency and user workflows; prepare to roll back to the previous artifact if a serious regression occurs. Small, frequent changes make causes easier to isolate and fixes easier to reverse.