ReadyRoll - database production deployment
Hi colleagues,
This is probably a dumb question, but I just want to make sure that the real customer's data will stay intact in Production, when we deploy new database changes. Can someone point me to a documentation that explains this bit in more details?
Also, building a release pipeline I noticed that all three environments (DEV, Staging and Prod) are sharing the same 'Shadow' database. What bothers me is that Prod database will be verified against Shadow database that was instantiated to DEV. Is this the right approach? I feel I'm missing something here. Please help me to understand all these 'nuances'.
This is probably a dumb question, but I just want to make sure that the real customer's data will stay intact in Production, when we deploy new database changes. Can someone point me to a documentation that explains this bit in more details?
Also, building a release pipeline I noticed that all three environments (DEV, Staging and Prod) are sharing the same 'Shadow' database. What bothers me is that Prod database will be verified against Shadow database that was instantiated to DEV. Is this the right approach? I feel I'm missing something here. Please help me to understand all these 'nuances'.
Tagged:
Best Answers
-
Grant
Posts: 89 Silver 5
The first question, what, if anything, will break in Production is a big part of what the rest of your process should be all about. We generate the safest scripts we can, but there's no guarantee that every script in every situation will always protect against any possible data loss. That's why a process of testing and validation is so vitally important. You want your dev, test and pre-production environments to mirror production as closely as possible in order to validate that the scripts generated and run won't negatively affect production.
If all three environments are sharing a database it sounds as if you're manually running Readyroll against all three. I wouldn't suggest this. Instead, you should be using different tools, such as the Visual Studio Deployment Manager or Octopus to automate secondary processes and testing of the deployments. Every deployment shouldn't be straight out of Visual Studio.
I hope that's a little helpful. -
robertchiha
Posts: 6 Bronze 1
Hi Allaire,
I was of the impression that the shadow database is only used when generating the scripts initially during development?
Scripts should not be regenerated for each new environment but instead the same deployment script run on all environments and only those sections that have not been previously executed will execute.
Answers
Thaks for your reply. The first question is crystal clear. The second one requires some clarification. You see, we're using automated build/release pipeline in VSTS, that includes database deployment as well. The only place where shadow database is created is a build step ("ReadyRoll set target database"), see the screenshot below:
Build process creates the deployment package that is used then by the Release pipeline in order to deploy database changes to all environments (DEV/QA/PROD).
In turn, release pipeline only has a deployment step (see the screenshot below). It doesn't set a shadow database (as build procedure does). Instead, it uses the package that was already produced by the build pipeline to deploy the changes. The situation shows that all three environments are using the same shadow database, which is no good. That's what I meant by "the same shadow database". If I understood Release procedure correctly, it doesn't assume "ReadyRoll set target database" step. What's the correct way to have a separate shadow database for every environment???
It sounds logically correct. Assuming that databases on all the environments I listed were created from the same source, they are identical, so, updating them with the scripts package generated during build procedure should not be a problem. Documentation is not clear in this regard.
Thanks for the clarification!