Two Strategies for Managing Run-Time Dependencies

DZone 's Guide to

Two Strategies for Managing Run-Time Dependencies

· Java Zone ·
Free Resource
Many software projects have dependencies at run time on other projects that are built and deployed by the software team. Some version of another application must be present in order to run properly.
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 Set

If 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.

From http://www.anthillpro.com/blogs/anthillpro-blog/


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}