January 14, 2021 at 8:55 pm
I'm wondering what other people are using to create deployment scripts. We have to create a script and deploy to 3rd party tool for deployment to each environment. We use TFS/Jira, so any scripts that get created are associated to a Jira item as well as put in TFS. The issue is, that when our iteration is done, I determine which JIRA items are being moved to production and combine the scripts into 1 script I can put into the deployment tool. I've tried using various compare tools to generate the script and they're fine, to a point. But it's still manual to figure out what to include and what not to include. There's got to be a better way (i.e. automated) that this can be done without all the manual work. Can anyone provide some insight?
For better, quicker answers, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
January 15, 2021 at 9:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
January 20, 2021 at 2:59 pm
If you do each iteration in a branch and only merge those Jira items you want to promote into Main prior to deployment, you can generate a script by comparing Main to the actual database. I'm assuming here that you're using Visual Studio database projects or something similar in conjunction with TFS.
January 20, 2021 at 3:06 pm
If you do each iteration in a branch and only merge those Jira items you want to promote into Main prior to deployment, you can generate a script by comparing Main to the actual database. I'm assuming here that you're using Visual Studio database projects or something similar in conjunction with TFS.
While this is totally doable, it does assume that the changes which are being deployed are in no way dependent on those which are being left behind. Also, unless you are deploying to a 'pre-production' environment for testing, it means that your production environment will be in an untested state (when taken as a whole, even though the changes have been tested and signed off individually).
I'm a bit surprised that none of the Redgate guys have jumped on this thread, as I think they may have some tools which may be of interest ...
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply