In AnthillPro, there are three project types: Life-Cycle Based, used to run builds, deployments, etc.; Codestation Projects, used to manage dependencies of third-party tool kits and software libraries; and Operational (Non-Life-Cycle Based) Projects, used for administrative, operational, and system maintenance. Following is a brief outline of the major components of each project type:
Life-Cycle Based Projects provide a wealth of information and visibility into the build and release cycle. The Life-Cycle Based project is used when configuring builds, and always creates a Build Life (in its simplest terms, the Build Life can be thought of as a build number) every time a build is run. Life-Cycle Based projects correspond to components of your application, and build independently of each other. For example, a typical web application might have UI, database, and logic tiers. In AnthillPro, these can be mapped as three projects that build separately. Configured in this way, you don't have to build the entire application to make a simple UI change, etc. The majority of the projects you set up in AnthillPro will be Life-Cycle Based. A Life-Cycle Based Project is defined by its:
Life-Cycle Model. Provides a template for managing the dependencies, artifacts, deployments, etc., associated with every build of the project. Because a Life-Cycle Model is reusable, it allows you to apply the same standards to any similar projects. See Life-Cycle Models for more.
Environments. A project will usually participate in many environments that correspond to the different stages the project goes through. For example, most organizations will have something similar to DEV, QA, and PROD environments that correspond to their different teams, etc. Essentially, a project's environment groups is the collection of environments it uses. If a project will never build on or deploy to certain environments, an environment group can be used to help segregate the project. See Environments for more.
Build, or originating, workflow. Defines the process for running jobs. When manually starting a build or scheduling work, a workflow is being executed. Each originating workflow will contain at least one job that runs your build script, etc. The originating workflow is also where you let AnthillPro know what specific source code is being built by the project, as well as configuring any dependencies. Any secondary workflows (to perform deployments, testing, etc.) configured for a project will inherit much of the information from the build workflow. The best way to learn about originating workflows is to set up a build process.
Codestation Projects model products not built by your organization as an AnthillPro project. This allows the use of third-party tools as dependencies, testing them as new releases come out to track their approval status within the Application.
In addition to making stored artifacts available to the build process, Codestation Projects also make 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. See Using Codestation Projects and Codestation (Developers).
Operational (Non-Life-Cycle Based) Projects provide a simplified interface that allows AnthillPro users to execute ancillary tasks not easily run during a build, deployment, etc., workflow. Because of their flexibility, Operational Projects can be used to automate most tasks associated with the traditional build and release cycles. For example, an Operational Project can be used to verify the integrity of deployed artifacts; start and recycle services on restricted machines; and automate other process that do not fit neatly into a traditional build. Steps can be run in parallel, on different agents, execute arbitrary commands, integrate with third-party tools, execute scripts, or perform any task or series of tasks that a normal project can perform. Similar to Life-Cycle Based projects, Operational Projects are defined by the environments they participate in and their workflows. See Using Operational Projects.