Different script being applied on deployment
Johannes
Posts: 9 Bronze 2
In the process of setting up the DLM automation on Octopus Deploy I have a manual step to stop the deployment to production so the deployment script can be reviewed.
A script that was generated in one of the initial releases had a table rebuild process because the identity seed and increments are different in source control than in production. I stopped that build from running in production and configured the release step to ignore the identity increment and seed values.
I triggered a new release in Octopus and this worked perfectly fine because the script in the artifacts no longer wants to rebuild the table.
I then pushed it on to production, but it then times out because it tried to drop the primary key of the table it wanted to rebuild in the previous discarded release.
I ended up deploying the script found in the second release's artifacts manually to the database which worked fine.
Even now if I generate a new release with no new database changes it comes up with a script with comment lines that says there are no changes. This is expected, but if I push the build through to production it then again times out trying to drop the primary key of the initial script that was generated a few releases back.
How is it that the automation is executing something completely different than the scrip in its artifacts?
A script that was generated in one of the initial releases had a table rebuild process because the identity seed and increments are different in source control than in production. I stopped that build from running in production and configured the release step to ignore the identity increment and seed values.
I triggered a new release in Octopus and this worked perfectly fine because the script in the artifacts no longer wants to rebuild the table.
I then pushed it on to production, but it then times out because it tried to drop the primary key of the table it wanted to rebuild in the previous discarded release.
I ended up deploying the script found in the second release's artifacts manually to the database which worked fine.
Even now if I generate a new release with no new database changes it comes up with a script with comment lines that says there are no changes. This is expected, but if I push the build through to production it then again times out trying to drop the primary key of the initial script that was generated a few releases back.
How is it that the automation is executing something completely different than the scrip in its artifacts?
Tagged:
Comments
It was my misunderstanding of the different steps. I thought the release creates the script for the deploy step. It is not the case. The deploy does the same as release in the way it calculates changes, only difference is that it applies them to the database.
Whatever parameters are specified in the release needs to be repeated in the deploy step to get the same results.
Thank you for taking the time to post the solution. I'm glad that's all sorted for you now.
If you have any further issues just let us know.