Octopus Deploy Initial Migrations

shgrc

I am testing out ReadyRoll on an existing database with the aim to be able to deploy changes via Octopus. I have two instances of this database, one on localhost which is the database against which ReadyRoll is reading changes, the other on a staging environment against which NuGet packages need to be deployed via octopus.

In the ReadyRoll solution I have created the folder 1.0.0-Baseline to hold the initial baseline script and folder 1.0.1 to hold the test script changes (basically added two tables in the database).

In the project properties I have enabled Octopus Compatible NuGet packages and created the relevant NuSpec file and enabled Semantic Versioning and Set Baseline for existing databases.

When building the project in Release mode the target NuGet package is created with the required changes, but I am noticing that the change script contains a migration script to migrate data from every table that exists in the database. Is it possible to disable these migrations and only generate migrations for tables that have been modified (in this case none as I performed no modifications, only additions of tables).

dnlnln

Apologies for the delay in replying.

The migrations included in the NuGet package in order to give you the option of deploying your database from scratch using Octopus. Unfortunately, ReadyRoll does not have a way of excluding the baseline migrations from the NuGet package at this time.

However as you've specified a baseline, none of those migrations will actually be run: ReadyRoll will insert the baseline [__MigrationLog] records at the beginning of the initial deployment to the staging environment, preventing the execution of any scripts in your 1.0.0 folder.

I could add this as a feature request for the team to consider. To add weight to the case, may I ask is there any particular reason you need to exclude the migrations? e.g. is the size of the package a concern, or is it the duration of the actual execution that is factor?

shgrc

Hi, thank you for your response.

The reason behind this I think lies within the process I am trying to set up. Basically I am trying to create a ReadyRoll proof of concept on an existing database. I already tried the tutorial and it was great, but obviously I need the proof of concept to be on one of our own existing databases. This database has references pointing to other databases (some are in tables, others in stored procedures). This means that deploying to a staging environment would require all dependent databases to be present as well. Also there are some issues such as missing references or mismatching collation. Granted these are SQL issues not ReadyRoll issues, and for now fixing these issues could be problematic as it is an old solution and there are always implications of fixing something that is working.

So far my attempt at getting this to work was create a local copy of this database and fixing these issues at a local level, this would be the baseline, and then I was assuming that further changes would be gracefully deployed to a staging environment as creation/updates of tables should not reference these fixes, and where they do I can raise the argument that a fix on live is needed, but until then I need a way of omitting these problematic procedures or tables, either from the baseline or from further changes.

I know that when creating a change script you can manually select which changes should be included, but I am afraid that somewhere down the line someone might include those changes by mistake.

Of course, maybe my initial set up is wrong and I should be tackling the issue from a different angle, so any advice is appreciated.

dnlnln

Thanks for sharing a bit more context of the db environment you're working within within.
May I ask, is it the programmable objects in your project that are causing the problem? These are the files that contain your stored procs, views, functions etc. If so, you can ensure that these are not executed by checking the following option in the project designer: Mark all programmable objects/additional scripts as deployed when setting the baseline. This will cause Octopus will skip these, in addition to skipping the baseline migrations, during the initial deployment to a given environment (they will only be deployed when you next change the objects).
Does that help at all?

shgrc

Hi, sorry for getting back so late. Basically your suggestion did the trick, and now I can deploy successfully, thank you for your support!

dnlnln

My pleasure, thanks very much for letting me know.

I've just realized that this option isn't mentioned the documentation. I've gone ahead and updated the relevant pages:
https://documentation.red-gate.com/display/RR1/Working+with+existing+databases#Workingwithexistingdatabases-SemVermethod(recommended)
https://documentation.red-gate.com/display/RR1/Semantic+Versioning#SemanticVersioning-IncludingProgrammableObjectsinthetheinitialbaseline