I’m currently trialling Octopus Deploy along with ReadyRoll (and Jenkins) and have run into a process/methodology issue.
I’m using a ReadyRoll Database project along with an ASP.NET web application and if we are moving forward all web app and database changes are being deployed correctly (I’m using NUGet packages). However i’m not sure how we handle rollbacks to previous database versions (even if there may be loss of data).
Here’s my current scenario:
Release 1.1.72 defines column A and column B in the database
Release 1.1.73 adds column C.
The current release is 1.1.73 but for whatever reason we need to revert back to release 1.1.72. I deploy 1.1.72 which is successful but column C still exists (understandably as this releases doesn’t know about column C). How can i get the database back to the state that it was with 1.1.72 release?
Octopus Deploy doesn’t have any features that can help directly with this, it can execute any set of actions you need it to do. So it’s specific to the capabilities of ReadyRoll. I had a skim over their documentation page on it: https://documentation.red-gate.com/display/RR1/Rollbacks it’s very detailed so that’s your best point of call to learn and experiment.
While you’re setting up and investigating the tools, your best bet is to just try it out for all the scenarios you can think of. Example: you’ve deployed a change, and found the bug several days later, there’s a mix of bad data and new useful data. In that scenario your customers have done significant amount of work, what should you do then? How do you safely rollback or what can you do to roll forward?
As a general note, regardless of the tools being used going forward will most often give you the best outcome, patch the bug introduced 1.1.73 and release 1.1.74 with fixes for any data problems caused by 1.1.73.
Many thanks for getting back to me Nick. I’m still at the discovery stage of setting up CI/CD and there’s still a steep learning curve especially when it comes to the methodology on how we’ll release our software.