Dependencies and Artifacts

Dependencies between projects are very common. Often a project will produce a library used by another project. When few project dependencies exist, manually adding the products of one project into another is straightforward. However, when dependencies start to get complicated, you need an automated solution.

Dependency relationships are often used to configure build scheduling. Typically, there are three main approaches: use of a scheduling method independent of the dependency graph; a pulling model; and a pushing model:

Independent Scheduling. Related projects do not need to know about each other for independent scheduling. A dependent project starts each build by gathering the most recent artifacts from its dependencies.
Push Scheduling. Also called the bottom-up model. When an originating workflow (that other projects depend on) builds, the workflows that depend on it automatically build. Because changes to the dependency result in changes to the dependent, rapid feedback as to whether the dependent was broken by the changes is available.
Pull Scheduling. The dependent is not automatically built whenever the dependencies are built. Rather, it is built according to its own schedules. When it builds, however, it starts the process by checking to see if there have been any changes to the dependencies and building them first if required. This is helpful to ensure that the latest check-ins are tested together.

In AnthillPro, dependencies between projects are described at the workflow level. Workflows in dependencies specify the location (in the working directory) of the artifacts used by dependent projects. A workflow may be both a dependency and dependent, but cycles are not allowed. When a workflow uses dependency artifacts, AnthillPro maintains a record of which build life the artifacts came from. This provides instant traceability from the dependent project back to its own source files, as well as those of each of its dependencies. See Configuring Dependencies.

AnthillPro provides an internal artifact store to track generated artifacts, tie them to build lives, and provide them to the dependent workflows. This store also makes it easy for a workflow to specify that it needs an artifact from a dependency that comes from a specific build life. For instance, this could be a requirement that the shared library has passed testing. Or an artifact could be locked down to a specific version. This approach is common as a project nears release because it helps prevent the team from making any deleterious changes. See Using Codestation Projects.

Codestation. The name for AnthillPro’s artifact repository. In addition to making stored artifacts available to the build process, Codestation also makes the configured dependency graph, and the artifacts themselves, available to developers. Through either an IDE Plugin, a command-line utility, or Ant tasks, a Codestation resolve operation on the developer’s machine fetches the appropriate artifacts.
Third-party Artifacts. Codestation provides a utility for uploading approved versions of third-party libraries. It provides these libraries to builds (similar to the way in-house dependencies are managed).