A Go Pipeline does not necessarily map one-to-one with what is referred to as the automated deployment pipeline in continuous delivery literature. The automated deployment pipeline is essentially the end-to-end CD value stream. This end to end value stream is often better modeled using multiple Go Pipelines.
For very simple cases, it may be enough to model the entire value stream inside a single Go Pipeline as the diagram in the documentation suggests.
But for any realistic case, we are going to have to integrate the output of multiple teams and then subject the combined package to integration testing etc. In this case, it is much more flexible to model the value stream with multiple pipelines as below (each box is a pipeline).
There is no need to stop at one pipeline per team. If anything, the pipeline group is useful as a team level concept. Modeling your delivery value stream using multiple pipelines allows you to:
- Associate different materials with different pipelines
- Associate different pipelines with different environments.
- Pause or lock a specific pipeline without affecting the other pipelines.
Here is a simple delivery value stream modeled using seven Go pipelines (split over two screenshots below)
In the next part, Part 3 of our series "How do I do CD with Go?", I will detail ways to get good traceability for your builds by using Go's custom pipeline labels effectively...
"How do I do CD with Go?" blog series:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.