Redgate Change Automation 4

Baselining your downstream environments

If you are working on a project with existing databases (e.g., not a brand new greenfield project where the databases don't exist yet), then you will need to baseline your downstream environments before you can use Redgate Change Automation to deploy your database changes to those existing environments.  Baselining each of your downstream environments (Test, Staging, Prod, etc) is a one-off task and ensures the baseline script in your Redgate Change Control project that represents what has already been deployed is not re-applied to the target environments, which would fail since those objects already exist there.   

It's easier if all your downstream environments are at the same starting point. This might be right after a release happens or if your dev and test environments were just refreshed with a cleansed copy of Production.  You can use Schema Compare for Oracle, which is part of the Deployment Suite for Oracle, to make sure all your environments are in sync.  If your environments are not in sync, then you may need to create multiple baselines, which is described in the section below. 

To baseline your downstream environments, use rca baseline against each target database. Set the --target argument to one of your downstream environments (Test, Staging, Prod, etc.) and the --baselineVersion to the number that corresponds to your baseline script.  Repeat this step for each downstream environment.

What if my environments are in different states?

If possible, it’s easier to synchronize your environments as much as possible.  You might need to wait until a release or blow away dev/test environments and re-create them.  If this is not the case, then create different baseline scripts using Schema Compare for Oracle for each of the target databases.  Example:

  • Dev is at v3.1
  • Test is at v3.0
  • Staging is at v2.0
  • Production is at v2.0

Create a baseline script that captures the current state of Production at version 2 and another script for version 3 that captures all the changes from version 2 to version 3.  For your Test database, set the --baselineVersion argument to 3.0.  This will still run any scripts since 3.0 against your Test database.  So, it will correctly apply 3.1 to your Test database.

For Staging and Production, set the --baselineVersion argument to 2.0.  The next time you deploy it will apply the version 3 migration script and then apply version 3.1.

Schema Compare for Oracle, which is part of the Deployment Suite for Oraclecan help you understand the differences between your environments and generate the baseline and delta scripts between two versions


Didn't find what you were looking for?