A deployment pipeline is an automated path from a software change toward a running release. For a cloud-native application, that path has two distinct parts: a service pipeline produces deployable artifacts, while an environment pipeline validates and promotes versions into specific environments. Producing a new artifact does not, by itself, deploy it. section 3.2 section 4.3
A pipeline definition describes tasks; a pipeline engine starts instances of that definition and reports their status. Instances may fail, so automation needs both checks that stop unsuitable changes and a way for teams to see what went wrong. section 3.1
A typical service pipeline moves through these activities:
- Detect a repository change, such as a merge to the main branch, and obtain the source code. section 3.4
- Build and test the service. Unit tests, coverage checks, or dependency security scans can block unsuitable changes. section 3.4
- Version and publish the resulting artifacts so other systems can retrieve them and trace them back to source code. section 3.4
- Notify interested environments that a new version is available, without making the service pipeline responsible for deploying it. section 3.2
With trunk-based development, a similar pipeline validates a pull request before merge. The main-branch pipeline should then produce releasable artifacts; if it fails, the service team needs to fix it promptly. Shared pipeline definitions can reduce duplicated work across similarly built services, while production-readiness checks can include policy, conformance, signing, and security scanning. section 3.4.1 section 3.2
A walking-skeleton service
For a service in the Conference application, a pipeline can start when a change is submitted and finish after publishing its container image. These example service pipelines do not publish an individual Helm chart for every service. An environment pipeline can subsequently test a change request to an environment repository; promotion toward production can require more checks than promotion into a low-risk environment. section 3.6 section 4.3
The handoff between the two pipeline types can be an automated pull request: the service pipeline makes a version available, and a change to the environment repository starts the environment pipeline. section 4.3
Before automating this flow, provide reachable repositories and valid credentials for the artifacts being published. Keep its boundaries deliberate: a Helm chart per service may be unnecessary, and repository layout affects webhook filtering. The aim is an end-to-end path teams can use without defining every task anew, not a single rigid pipeline for every service. section 3.4.2 section 3.4.3 section 3.6
