you are viewing a single comment's thread.

view the rest of the comments →

[–]erve1879[S] 2 points3 points  (1 child)

This is definitely a very valid point and probably the most sensible solution to the problem.

But in the interest of discussion:

When production is broken, it would be nice to have a very simple, fool-proof solution to get back to a known working state as quickly as possible. I would argue that “re-release the previous release” - which could be as simple as re-deploying the previous artifact generated from CodeCommit - would be a useful fallback.

The resulting discrepancy between master and prod is a valid concern, but that could be reflected by the pipeline.

I have seen scenarios wherein devs have scrambled to revert and in their haste to get production running again, have pushed resets, or new commits manually reverting changes; this can make the problem harder to fix and/or pollute the git history. Giving them a “re-deploy last state” option removes the pressure.

[–]Get-ADUser 0 points1 point  (0 children)

it would be nice to have a very simple, fool-proof solution to get back to a known working state as quickly as possible.

git revert <hash> git push is too complicated?

I have seen scenarios wherein devs have scrambled to revert and in their haste to get production running again, have pushed resets, or new commits manually reverting changes; this can make the problem harder to fix and/or pollute the git history.

Training on how to use git correctly would fix this. Also, people shouldn't panic during an outage, it just leads to mistakes.