In support of simplifying the Segregation of Duties pipeline definition, the Lab Assistant app will now create a dotenv formatted file and deliver it to the newly created branch. This perfectly meshes with what the Auto Deploy Image is expecting to allow Segregation of Auto DevOps Duties.
To help make it clear what the intermediate step is between the existing Deployment project example and real DevOps, I created a streamlined version.
Spring Web App project tag pipeline
The MR and Commit jobs are now in one job. It creates MRs in 2 deployment projects now.
To take advantage of the new functionality
Update your CI pipeline definition for the job that is using Lab Assistant to refer to the v1-1 docker image tag.
handoff:
image: registry.gitlab.com/brownfield-dev/public/lab-assistant:v1-1
script:
- lab-assistant --target-project-id={integer identifier} --target-user-id={integer identifer]
Then add whatever rules you need to make it work right. It expects to be run on a Tag so if you’re using it on master merges or some other event, be sure to change the code and recompile.
Then in the consumer apps, replace the get artifacts job with this simpler version.
get handoff:
stage: handoff
script:
- cat handoff.env
artifacts:
reports:
dotenv: handoff.env
There are examples in the Segregation of Auto Duties example group.
This still seems complex…
It is discussed in the Segregation of Auto Duties video walkthrough. There are 3 sources of complexity that tie into these examples and lead to confusion.
- Auto DevOps is a lot
- The gates are a lot
- GitLab CI is a lot
Auto DevOps is good
It shows a live running environment that undergoes change and the changes are reflected along the line of review, staging, and ultimately production. It would be trivial to crank it up to a blue/green deployment pattern or point it at ECS instead of kubernetes. The flexibility there is valuable, though it makes the demo a bit longer since those aspects need to be talked about.
The gates are necessary sometimes
The confusing process that leads to confusing gates is the core requirement that needs to be supported. If your processes are easy, that’s great. Use the system as it’s designed and sleep well at night.
If you’re like my customer and need to take deliberate steps toward proving the gates should be moved based on better ways of working, then the gates will come in handy. They’ll provide a risk vs value baseline where relaxing the gates can be tested and if regressions or security issues climb, then the CM team is vindicated. If the quality is maintained while automation takes the load off of CM, then everyone wins.
For folks who don’t have as many gates on the deployment side, check out the Deployment but fast project. It eliminates all the pipeline gates and just has the Merge Request approval and merge events to control the release. The same Spring Web App deploys to both the gated and fast projects for comparison of tags.
Deployment pipelines without the gates
Deployment project commit pipeline
Not having the staging approval job is just one fewer nodes, significant workflow improvement
The developers know right away if the stage deployment fails versus having to wait until the staging approval happens to receive that feedback. They can remediate their own problems, as long as the blast radius is limited. If a failed deployment breaks the whole staging environment for several teams, maybe keep the gate.
This would not be particularly resilient but adding a job to validate and roll-back if needed is a good iteration on what’s here.
GitLab CI is good
It hides a lot of functionality both in making assumptions (having no value leads to some default) and by using includes and yaml anchors. The good news is that when it works, it’s terse and nice looking. The bad news is that when it doesn’t work, it becomes quite a troubleshooting adventure to chase down the problems.
That’s why Golang was used
Rather than making it a huge bash script in a GitLab include, I opted for Go for Lab Assistant. It’s not very many lines of code, it can unit test, it can be statically compiled into an Alpine container, etc.
Take a look at the new Segregation of Auto Duties projects
And let me know what you think is the next best place to focus on simplification or flexibility!