This section describes the phased deployments feature, a.k.a. changesets feature, that can be used if you need to orchestrate a release in multiple steps. An example use case is for a long-running deployment (e.g. creating indexes) that you would like to run separately after the rest of your regular DDLs are run.
Let’s take a regular deployment going from version 1 in the database to version 2 in your source code. Say that the delta between them is 5 changes: c1, c2, … c5. Normally, the deployment will execute all 5 changes in one shot, and this is the recommendation.
However, in certain cases, teams may need to execute their deployment in phases. The prime example is for index creation; teams may want to deploy their structural DDL changes for their main deployment so that their application can move to a new release, but not deploy their index changes as those would take much longer (hours potentially depending on the table size) and the application could still run without them. Instead, these index changes could be deployed separately (say if a team prefers deploying table changes on weekdays and indices on weekends)
We stress that this is not the ideal case; preferably, all DDL changes can be done in one shot, and even if some changes take longer, if you can find downtime on a weekend you can do the full release then. However, as practicality dictates that some teams will need to do a phased approach as described above, we will provide this functionality in Obevo.
Add the changeset annotation to the CHANGE that you want to deploy separately. e.g.
[mytable1.ddl] //// CHANGE name=c1 abc //// CHANGE name=c2 abc //// CHANGE name=c3 changeset=set1 abc //// CHANGE name=c4 changeset=set1 abc //// CHANGE name=c5 changeset=set2 abc [mytable2.ddl] //// CHANGE name=d1 abc //// CHANGE name=d2 abc //// CHANGE name=d3 changeset=set2 abc //// CHANGE name=d4 changeset=set3 abc
Given this example:
Change calculation with these changeset attributes is calculated as follows:
Onto the argument types:
For a particular release, the deploy commands can go as follows:
For regular deploys, the default is to not deploy changesets as this optimized for the production use case.
However, for testing, we’d encourage deploying all changesets to ensure that no changes get missed out. Hence, this is enabled by default for unit test deployments and the maven “test” goal.