Fetching properties from codestation projects to perform component based automated database deployments using AnthillPro
In the case where you have a 3rd party component that does not have its own ability to mange its database changes, along with its incremental deployment. Each database change for the entire life-cycle of the component should exist as changes which can be referenced by number. A good way to do this is with dbdeploy, where each database change is stored as a file, prefixed by a change number and an underscore like so:
- 0001_init.sql
- 0002_add_columns.sql
- 0003_new_feature.sql
- etc…
When the dbdeploy task is called, an additional optional property can be passed called: lastChangeToApply which tells dbdeploy up to which version to apply. All that we would need to know at this point is which version of our component goes with which database change and simply assign it as a property to the particular version (stamp) of the codestation component. Here is a test codestation project of version 1.2 where we see that with 1.2 we want to deploy up to database revision 3. To learn more about all the things you can pass to dbdeploy, visit their Google code Wiki site.
In your deployment, you will need to have a step that resolves (downloads) this version of this component to some target host in the environment. Just because you perform a “resolve another projects artifacts” step, doesn’t mean you also see the properties set in that codestation project. Therefore, you need to run a quick beanshell script that will allow you to take the db_revision property in the codestation project for that components particular revision, and populate it to a global anthill property that you can use to pass to your dbdeploy task, so it can do something meaningful with it. In order for this to work, we require 2 pieces of information. The COMPONENT_VERSION which is a version that you’ve previously defined of the component we’re deploying. Also the COMPONENT_NAME is the name of the codestation project that contains the property we want. The script will store the value in the anthill property db_revision, this can be addressed inside anthill as ${p:db_revision}. The script also outputs the number to standard output using the commandOutput.println method, for audit purposes. You should simply create project variables, per-environment in the “ALL” tab of your project as COMPONENT_VERSION and COMPONENT_NAME and set them properly. Or, use your own names and change the script as you like below. Once complete, simply be sure to run this step in your deployment job as: Miscellaneous -> Evalulate script.
Paste in code:
import com.urbancode.codestation2.domain.buildlife.*;
import com.urbancode.codestation2.domain.project.*;
import com.urbancode.anthill3.runtime.scripting.helpers.*;
String component_version = PropertyLookup.get("COMPONENT_VERSION");
CodestationProject csp = CodestationProjectFactory.getInstance().restoreForName("COMPONENT_NAME");
CodestationBuildLife csbl = CodestationBuildLifeFactory.getInstance().restoreMostRecentForProjectAndStatusAndStampValue(csp,null,component_version);
PropertyLookup.set("db_revision",csbl.getProperty("db_revision").getValue());
commandOutput.println(PropertyLookup.get("db_revision"));
Now that we went through all that, we can pull it all together by having the ability to pass this new information to any script as in this example of an ant task property.
