Release-tools coordinated pipeline could benefit from disconnecting from Deployer
When we tag our product for Auto-Deploy, we also tag deployer. This has historically been utilized to quickly find pipelines when viewing things from the Deployer pipeline view. Unfortunately this creates an issue where if we introduce a flawed feature into Deployer, we cannot pull away from that flaw without an entirely new tag. Our current method(s) is to either wait for the next auto-deploy pipeline to have been created, force that procedure early, or leverage chatops to manually deploy. Either way, the current deployment that are bound for production cannot be utilized thus the MTTP goals of our team are negatively impacted.
Proposal
- Consider removing the tag on Deployer
- Consider writing a procedure where we potentially retag Deployer
- ...
Removing Deployer Tag
Doing this has the benefit that we are never tied to a specific version of Deployer and we can make changes as necessary, sometimes between deployments of the same package to differing environments. This is also a downside, however. This options allows us to remediate problems quicker, and since we, for the most part, rely on our messaging that comes from slack, we do not navigate the pipelines in deployer often. So having this tag is probably not as beneficial as it once was.
Procedure to retag Deployer
The goal here would be that if we revert a change, we then retag deployer appropriately such that we can then re-run existing jobs that will instead trigger Deployer pipelines using differing code. This is considered poor practice amongst most of GitLab so this is probably not the best option as it will introduce confusion. I'm not even sure if we allow this with our current permissions model.