Two Strategies for Managing Run-Time Dependencies
We see this situation appearing most often with Web Services, J2EE environments where EJB clients and applications must match, and even in the roll-out of related database schemas.
The basic problem these scenarios face, is that deployments must be orchestrated so that any related projects move through the life-cycle at the same time. The strategies for addressing this in AnthillPro are pretty straight-forward.
First create a new AnthillPro project that uses dependency rules to represent the full set of components that get released together. A "Build" of this project is mostly responsible for assembling a set of components that will be deployed together. At this point there are two main paths to follow:
1) Assemble and Deploy
The first strategy builds a single release package. The deployable
artifacts of the various components are assembled as part of the build.
Deployments of the meta-project move all the projects out together.
2) Chained Deployments
The second strategy doesn't assemble the components. The "build" just
establishes the dependency relationships without moving artifacts
around. The deployment of the meta-project uses the Miscellaneous >
Run Dependency Workflows step. This step will call the "Deploy"
workflow on each dependency. In this case, each component knows how to
deploy itself, and the role of the meta project is to just ensure that
those deployments are run together.
For better or worse, this will also allow the team to deploy a single component on its own. If that is not desired, give nobody execute permissions on the Deploy workflow of the components to restrict them to only being run by the master deploy workflow.
Applying a Label to the SetIf you want to apply a stamp or source control label across all the components in the meta-project, variables like the meta-project's stamp can be passed down the Run Dependency Workflows step to the children. These can be used for labeling or stamping.
Working with Subsets
The subset of services that need to go out are not known until deployment time approaches: In this case, have the meta-project's build take a release id paramter. Add workflows that mark applications to deploy with the release id as well. When the meta-project is build, it's dependency rules or a beanshell script can take all sub-projects with matching ids and make them dependencies. After that point, everything works the same.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)