Question: How to handle rollback?

[lktslionel]

Hello,
Huge thanks for this great specification of the GTF. I've something similar except for the deployment process.
In fact, it is a good idea to use tag and this awesomely described pattern to trigger deployment. The only drawback is that you lose a clear view of the deployment history. You will need new tooling to gather that information.

This leads to what I wanted to point out: the rollback workflow. If you wanted to do a rollback, you would need to delete/recreate the tag or use a tag pattern like rollback/<env>/<version>. What are your thoughts on this?

Looking forward to hearing from you
Regards

[vasdee]

Apologies for the very late reply, I must have missed the notification.

Rollbacks are interesting, generally I feel that where possible a roll forward should be the preferred option. However, I know that's not always possible for every scenario. The way I have addressed this in the past is to simply re-release the previous version of the production artefacts, by the same release/, or if you prefer, deploy/ tag pattern, usually this can be triggered via whatever pipeline tool you are using github actions, azure devops etc. The other way I have achieved it when I want to 'stay in git' is to add an extra release number to the release/ tag, eg if I wanted to rollback to v1.0.0 I might tag the release/1.0.0 commit with another tag, release/1.0.0-1 to differentiate and preserve the history. This might violate semantic versioning principles though.

Where it gets complicated is with database migrations, but that's a huge topic to get into :)

The only drawback is that you loose the clear view of the deployment history. You will new tooling to gather those information.

I believe the opposite, you have have a complete list within git, git tag --list 'release/*' and it ties directly back to your source code. If you need more, usually the pipeline tooling has a nice UX for displaying previous pipeline runs.

BTW, the idea of introducing more tags into GTF isn't discouraged at all though, if you are using git tags to trigger more and more actions, then I feel that promotes git ops and should be encouraged.

[sthysel]

If your services are each contained in its own repo, and you have a "controlling" repo explicitly specifying the version of the release, a rollback is a simple decrease in version in the controlling iac definition and a re-deploy. The deployment history is captured in this service definition repo. That seems to me to be the simplest way of going about it.

[vasdee]

That would be a good example of roll the deployment manifest forward, by rolling back the services to the previous version.

Eg

release/2.0.0 went to production, but needs a rollback to the v1.0.0 services.
edit the deployment manifest to match the v1.0.0 service versions
commit
git tag release/prd/1.0.1

[lktslionel]

Thanks to you both for your explanations and examples.
@vasdee @sthysel

[haydster7]

@vasdee
Would this be worth adding to the spec/readme?
I came back looking for exactly that, and didn't realise it was in a closed issue

I also thought of an alternative that shouldnt violate semver
You could use a tag like redeploy/<env>/<version deploy count>/<semver>
This would keep the tags unique and although its a bit of extra setup in the CI/CD, it prevents violation of semver

[vasdee]

@haydster7 I think it is worth a foot note, but tag flow isn't prescriptive about how your want to implement the rollback strategy.

raised #12 for discussion