Comments
Sort by recent activity
Hi Christo,
That first deployment is a bit tricky, it's something that we want to improve. One flow that could work is:
- Restore a backup of production into a test environment
- Deploy a package that represents the current production stage into test using the dynamic mode
- Ensure test and production are identical (using SQL Compare)
- Switch to static deployment mode in Deployment Manager
- Run a SQL CI build of the changes you wish to release to production, make sure that 'generate upgrade scripts' is set. That will generate an artifact that can update the version that is in test to the desired state, and will save an upgrade script in the Nuget package with the exact changes it will run on test.
- Deploy that change to test using Deployment Manager, ensure it works as expected
- Extract that upgrade script from the Nuget package
- Run that same script manually on staging/production as part of your release process
You can then be confident in exactly what Deployment Manager will run into Test, and you can use the same script in future deployments to staging/production.
Subsequent deployments are easier, as you will have a package that represents the production state so the first three steps are much easier.
Hope that helps
Jon / comments
Hi Christo,
That first deployment is a bit tricky, it's something that we want to improve. One flow that could work is:
- Restore a backup of production into a test environment
- Deploy a package ...
Hi Christo,
This is something that we want to improve to make it easier to see exactly what the changes are. Are you using the dynamic deployment mechanism?
Jon / comments
Hi Christo,
This is something that we want to improve to make it easier to see exactly what the changes are. Are you using the dynamic deployment mechanism?
Jon
Great - do let us know how you get on, or if you have any other questions. / comments
Great - do let us know how you get on, or if you have any other questions.
Hi,
Thanks for the info. There are a few different ways that our customers are doing things similar to do this, I'll run through a couple below. Very happy to hop on the phone to talk more too.
One way is to use Red Gate Deployment Manager alongside SQL CI. This can be setup so that whenever you make a commit to either the application or database the CI server will create two packages. One that contains a build of the code and one which contains the scripts folder representation of your database. These are then both passed to Deployment Manager as a 'release' (a specific pair of versions of the DB and code). This release can be deployed automatically to your dev/CI environment . The same release can then be deployed as a 'push button' deployment to QA, staging and production environments. It's a good match if you're planning to run a continuous delivery approach. It ensures that the same pair of versions of code and database end up together as they move through each environment. Diagram of Deployment Manager Workflow
Another approach is to use a version control release branch for each environment. When developers commit code to the 'dev' branch your CI system can build to the dev environment using SQL CI. When it's time for a QA deployment then you can merge the required code onto the QA branch and have the CI system deploy the CI environment. You can do that for both the database and the application (either in separate repos or as a single combined repo). It's a bit more fiddly to work with in my opinion.
There's a Stack Overflow thread with a few diagrams that match this 2nd approach.
Hope that helps
Jonathan / comments
Hi,
Thanks for the info. There are a few different ways that our customers are doing things similar to do this, I'll run through a couple below. Very happy to hop on the phone to talk more too.
O...
Hi,
I think your steps sound correct, your build artefacts include a scripts folder and the compiled code. Say you want to deploy build XXXX to QA
- Look at the scripts folder which was output during from build XXXX
- Run a SQL Compare between that scripts folder and the QA database to generate a script
- Run the script on QA database
- Deploy the code
Just to clarify your intended uses case with migrations v2. I assume you'll be using migration scripts occasionally to add custom SQL scripts for cases when SQL Compare can't work out what to do automatically. For example renaming a table or adding a not null constraint to an existing column.
Migrations v2 are stored within the target and source databases (and thus will be in any script folder representations of those databases). Providing you are using a version of SQL Compare that has migrations v2 beta functionality, then any migration scripts that have not already been run against the target database will be added to the deployment scripts SQL Compare generates.
Jonathan / comments
Hi,
I think your steps sound correct, your build artefacts include a scripts folder and the compiled code. Say you want to deploy build XXXX to QA
- Look at the scripts folder which was output dur...
Happy New Year
Would be great to talk more about what you're looking to setup, hopefully we can help you get this setup how you need.
Couple of questions about what your setup is like:
- Are you deploying code and a database with each build, or just the database?
- Are you using TFS as a continuous integration server?
My email is jonathan.hickford@red-gate.com, if it's easier to have a phone call let me know your number via email and I can give you a ring. / comments
Happy New Year
Would be great to talk more about what you're looking to setup, hopefully we can help you get this setup how you need.
Couple of questions about what your setup is like:
- Are you de...