We use the DBUp DB upgrade utility, and we have an alternate environment we would like to apply releases to on a scheduled basis but nightly. We use this alternate environment during the day for performance testing, and would like to update the environment at night with the day’s activity (we release 1-3 times per day). Is there a way to achieve this in OctoDeploy? Since its DBUp what we are doing is applying all incremental DB Migration scripts in sequence at the end of the day, so to illustrate say we have a 3 releases today of the following packages
1.2.1
1.2.2
1.2.3
There is a release for each of them, they are promoted to our production database. At night we would like to run each of those in order against the server we have registered in a test environment. The way triggers appear to work currently as I understand it, instead of deploying 1.2.1, 1.2.2, 1.2.3, the trigger would only apply 1.2.3 at the nightly interval. Is there a way to achieve the behavior I am looking for?
There’s no way to do this in Octopus right now. In your example, you would probably want some external scheduled task (external to Octopus) that runs a nightly script, where that script would query against the Octopus API in order to determine which releases need to be deployed to the alternate environment, and then deploy those releases sequentially.
Octopus is a little bit opinionated in this regard - we think that ideally deploying a release to an environment should have no dependencies. That is, the deployment should succeed whether that project had been previously deployed to that environment or not, and it should also succeed regardless of which version was previously deployed to that environment.
In your case, that means that you should be able to deploy version 1.2.3 without first deploying versions 1.2.1 or 1.2.2, and you should therefore be able to make use of a scheduled trigger which simply deploys the latest version (1.2.3) to your alternative environment.
Indeed, this is how DBUp has been designed. Unless you are doing something particularly unusual with DBUp, it should be comparing the state of the existing database (specifically which scripts have been executed against that database) to the list of scripts you are shipping with your deployment package, and then only run any new scripts. This means that if you were to only deploy version 1.2.3, it would firstly run any scripts that were originally shipped with versions 1.2.1 and 1.2.2.
Hope that helps, let me know if you have any other questions!