Hacker News new | ask | show | jobs
by tarmstrong 3396 days ago
> But the author's idea that you should generally plan to soldier through to newer code if things go wrong during deployment as a standard operating procedure betrays a lack of experience and sends a dangerous message.

The author says "reverting smaller diffs as a roll-forward is more verifiable" near the end of the article. I agree the title makes this a bit confusing, but I don't think he's arguing that the only way to recover is to write a patch under pressure.
2 comments
kelnos 3396 days ago
Reverting a smaller diff is writing a patch under pressure. Reverting a section of your new code is just as difficult as authoring a new fix. You need to be just as sure that the partial revert will not interact poorly with other parts of the new code that you are not reverting.
link
tarmstrong 3395 days ago
> You need to be just as sure that the partial revert will not interact poorly with other parts of the new code that you are not reverting.

By partial revert, I'm imagining that three people have changesets (A, B, C, in that order) that have been deployed. You notice that A broke and you make A' to revert it. I think the author is arguing that it is easier to review A' to see if it is a safe change than it is to verify that A', B', and C' (the full revert) are safe to revert.

In other words, even if you don't use version control to record that you reverted A, B, and C, you still effectively do that by reverting in full. You just know that the combination of A', B', and C' was safe when it was deployed.

Is that what you're imagining or are we talking about different things? (I don't have strong opinions about this, I just want to make sure I understand your perspective (: )

link
skookum 3396 days ago
Reverting smaller diffs out of order to roll forward IS a patch under pressure. Usually most interesting features, the kind that tend to cause bugs that are not caught until deployment time, tend to come in as several patches over time. So reverting those means cherry-picking a set of patches, making sure you got the full set, making sure no subsequent patches took some subtle dependency on the ones being pulled, and so on. If you're in a compiled language, the set of patches is not too big, and the churn on your repo is low, then you probably have a decent chance of getting it right under pressure even if you have to untangle some refactors and such. If not, good luck.
link