Best way of handling hotfixes?

[henwev]

First of all a big thank you to everyone involved in developing schemachange. It really is an awesome tool to work with!

In our environment we sometimes need to wait a bit for tests to be completed before we can introduce our changes from the the dev/test database to production. In the meantime there might occure the need of doing a hotfix in production and I wanted to ask about best practices of handling them.

I saw that the author of #21 had pretty much the same question, but the answer has a flaw in my opinion (unless I am missing something):

in my experience the best way to handle the situation you're describing is with version control and branching strategies. You would create/use a hotfix branch, add a change script with the next version number, deploy. Then merge that back to your dev branches and rename the scripts in development appropriately.

If I merged the hotfix back to dev, then rename the script in dev to a higher version number, it would re-apply the script in production once I merged the dev branch into the prod-branch some time later for the next release, wouldn't it?

One possible solution I could think of was to apply every hotfix as an repeatable R-script and never touch the script again afterwards. This would ensure that the hotfix is only applied once in every environment. The only drawback I see is, that it more or less abuses the idea behind R-scripts, because a hotfix-script might have non-repeatable content. This might confuse a developer but I think if hotfixes are stored in a dedicated "hotfix" folder it should be clear.

I also had a look at flyway and found in their FAQ about hotfixes that there an "outOfOrder"-option to also apply version numbers, that are lower than the currently highest deployed version number (source: https://flywaydb.org/documentation/learnmore/faq.html#hot-fixes). But from browsing other issues of schemachange I already noticed that the maintainers are not the biggest fans of the outOfOrder idea and I definitely get the arguments against it.

To conclude I have these specific questions:

• Has anyone else dealt with hotfixes in a different way that I did not yet think of?
• Do you see any issues with the proposed way of handling hotfixes via R-scripts?
• Or is it worth to get into the discussion of the outOfOrder-option again to tackle the hotfix-scenario?

Thank you!

[UberDoodles]

I haven't had to deal with hotfixes yet, so I'm speaking entirely theoretically.

I think the R-script approach could work. To protect against the possibility of the script being repeated, you might be able to make any hotfix code repeatable, but it might be a headache sometimes. You might have to create a temporary stored procedure as part of your hotfix script, which worked out whether the hotfix had already been applied.

A slightly different alternative I can think of would be to introduce a new script type to schemachange (maybe H-script for Hotfix). This would be essentially the same as an R script, except it only executes once (it wouldn't be re-run if the hash changed); so would protect against the hotfix being re-run.

[UberDoodles]

One thing that was still bugging me after I wrote that response was "but when would the H-scripts run?". You really need them to run in the correct order; scripts that are added later might depend on the hotfix having been applied. If the H-script ran at the same time as the R-scripts, that wouldn't be the case.

I came up with a potential solution for that this morning. I said in my original response that H-scripts would be a lot like R-scripts, but actually they should be more like V-scripts, and they should have a version number which indicates where they fit in. The difference between a H-script and a V-script would simply be that H-scripts are run retrospectively; a bit like having the outOfOrder option specifically for these scripts.

I think if used correctly, this might be a good solution. I just have two concerns with it.

First, any scripts which are already in your branches and have a higher version number than the H-script will not have been written with the hotfix in mind, and might not be compatible; you'd need to verify this.

Secondly, the H-scripts would be open to abuse/misuse. Whilst they are intended for applying hotfixes, there's nothing to stop someone using them to try and re-write history. E.g. "Oh, back when I put that change in, I should have also made this other change. I know! I'll put a H-script in!".