Rollback button is not reliable when handling deployment emergencies on stateful pipeline
Rollback relaunches the previous job with the previous commit
Source: Handling Emergencies - https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/
This feature works very well as long as your pipeline build everything from scratch in a stateless manner. There's absolutely no problem with that and it is great!
The problem is, sometimes the project you build has to depend on external ressources - the kind of ressources that might or will change over time, independently of the projects that rely on them.
You can circumvent the problem by making use of artifacts. So, instead of using the rollback button, you only need to manually trigger the build step that deploys the project. And quite frankly, this part achieve the very purpose of the
The problem with using artifacts is that you should set an expiry. In this situation, triggering the last build step can only fail when the artifacts are expired.
The very purpose of the rollback button - to me at least - is to give an easy and reliable way for "anybody" to deploy a previous release because something went wrong with the new release.
Because the build might rely on artifacts that are expirable, this emergency mechanism is prone to fail.
That would be nice, for example, that the rollback button be configurable.
- So that it we can set it to only trigger the deploy build step of a pipeline.
- So that it is only available as long as the artifacts the build step depends on it is not expired.
Another thing that would fix the problem would be to set an
expire_in of the artifacts associated with a deployed build to last longer than the default builds. For example, if we could say "for a production pipeline that is deployed, keep the artifacts for a month", that would work.
We could also say: hey this went into production so we PROMOTE IT and doing so we keep ALL its artifacts so we can deploy it again if needed.