How do you use Go to address the following situation?
Say your QAs do some manual exploratory testing in addition to all the automation. They might want to have the last good build automatically deployed to their test environment for them every morning so that they don’t have to spend time manually figuring out the last good build and deploying it.
Simply creating a downstream deployment pipeline won’t do the trick. For one, it would auto-schedule for every successful upstream build thus wiping out the previous deployment and any testing in progress. To prevent auto-scheduling, you need to mark the first stage of the downstream pipeline as type manual.
So far so good. Our deploy pipeline will now only schedule at 10:15am every day. But sometimes, the QAs want to continue testing a given build the next day. They don't want the next day's timer trigger to deploy a new build. One way to do this is to manually pause the pipeline. This will prevent the pipeline from scheduling until unpaused.
Another way to achieve this is to add another manual stage at the end and use automatic pipeline locking. When auto locking is enabled in a multi-stage pipeline, the pipeline will only get scheduled if the previous run is complete.This may sound roundabout compared to simply pausing the pipeline. But it could serve a useful function. The final manual stage could serve as an indicator of successful exploratory testing. You could even treat this as a restricted approval privilege. Any pipelines further downstream will now only get scheduled after QAs give the go-ahead.
Finally, we need to consider the agents where stuff gets deployed. It is important to ring-fence the agents by defining an QA-exploratory-testing environment. It is also necessary to instruct all deployment jobs to run on all agents.
Hopefully this illustrates the power of combining a number of Go-primitives to achieve higher order behaviour.
Hope you enjoyed this series of blogs on doing CD with Go. Please add a comment with your feedback.
"How do I do CD with Go?" blog series:
- Part 1: Domain model, concepts and abstractions
- Part 2: Pipelines and value streams
- Part 3: Traceability with upstream pipeline labeling
- Part 4: Go environments
- Part 5: The power of pipeline templates and parameters