How can we help you today? How can we help you today?

Database and code dependencies!!!

I'm new to Redgate and looking for some help on how best to setup my deployment process.

All the Redgate examples I've seen online always understandably demonstrate how to source control, commit and deploy DB changes. However I have not found anything that demonstrates how one would deploy db changes and dependent code changes.

I have many sites and a few databases, many of the sites share one or more databases. All my sites live under c:/webapps/site.one.com, c:/webapps/site.two.com and so on. The databases live on d:/db/db_a, d:/db_b etc.

If I make changes to my web code and I have associated db code changes what can I use in order to create a builds that will deploy my code and db changes together?
nhungthientai
0

Comments

1 comment

Sort by
  • Kendra_Little
    Hello!

    Great question. One quick note: you're in the "discontinued and previous versions" section under DLM Automation, I am not sure if you meant to be in the SQL Change Automation section?

    With the migrations-first approach in SQL Change Automation, you are able to put multiple projects in a single Visual Studio solution if you wish. 

    However, personally, my experience is that it is valuable and important to de-couple your database changes from your application changes when it comes to important.  A simplified model is:
    • First, deploy initial database changes to "stage" the scene, but do not change customer-facing functionality. Build and deploy these independently, verify they are in place. (Example: add a column that will be used later, but it's not used yet.) This may be multiple changes rolled through the pipeline over time.
    • Later, deploy application changes that add the feature, but include a "feature flag" which determines whether the feature is visible to customers or not. Again, this may be multiple changes.
    • Eventually turn on the feature flag, and expose features to the customer
    There's a lot of benefits to decoupling the changes this way: if you need to do a rollback, it's quite easy (simply turn the feature flag off). And the design of staging incrementally allows you to make minimal risk incremental changes.

    Is your question also about building databases with cross-database dependencies, such as a view in one database which references external databases? If so, I can speak to some approaches for that as well, just not sure about the scope of your question.

    Hope this helps,
    Kendra
    Kendra_Little
    0

Add comment

Please sign in to leave a comment.