New Reply

Good news! We have migrated all the Q&A on this site to https://forums.inedo.com, and are currently monitoring questions there!

Here are some important links:

All posts here are permanently locked (and will be redirected soon), and if you have any issues with the new site, please submit a support ticket, use the contact form, or visit our Slack Workspace.

I have some questions regarding the usage of change scripts.

Let's say we have a project with two developers. Each has a local database, with a schema for development (with arbitrary data) and a schema for automated tests, which is filled and cleared by the test framework.
Further, we have three environments: Integration, where the project is built and the tests are run again; Staging, where the application is deployed and the DB contains some example data; and Production.

Now Developer 1 makes a change in the schema and commits updated code to into the trunk. She also creates a change script that can be applied to Staging (and later, Production).

  1. Developer 2 was working on something unrelated and now merges the changes into his working copy. How will his development schema be updated?

  2. After the change was already applied to staging, an emergency fix to the previous release was necessary. Lets say there is also a script to create the original database from scratch. Can BuildMaster be configured to automatically reset the database if its current version is "too recent"?

Hi Arian,

BuildMaster's Database Change Management follows the steps outlined in Database Changes Done Right: http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx

So, basically, each script is assoiciated with a release, and BuildMaster change script executer (action, manual, or self-contained executoer) can tell if the script has been run against a database by maintaining a metadata table.

You can use this to configure all sorts of patterns, including what (I think) you're refering to.

Alex