Workflows

A workflow is a series of jobs that should be run, and determines how, when and where the jobs should be run. Workflows assemble jobs into processes, and are the unit of automation. Workflows, also manage the order and parallelization of jobs.

As a rule, when manually starting a build or scheduling work, a workflow is being executed. Workflows assemble many of the other configurable items into something usable:

A job is a series of steps detailing how to get something done. It may specify the steps in a build, deployment, or other business need. The job configuration also dictates what types and number of machines the job will be run on (a deployment job may target every machine in a cluster).
A trigger is an automated mechanism for kicking off a workflow.
Source Configuration identifies exactly which source code should be retrieved from a repository. How these are configured will vary between source code management tools.

To start, AnthillPro has two basic types: originating and non-origination. Originating workflows are used to start Build Lives, utilizing Life-Cycle Models, source configuration, and dependency information. Non-origination workflows specify secondary processes that can be run on an existing Build Life (e.g., a deployment). Underneath, the difference is that originating workflows have corresponding BuildProfile objects.

Components of a Workflow:

Workflow Definition. Defines which job should be run, specifies the order of jobs, as well as the elements to be run in parallel.
Environment. For builds, this will almost always be the Build-Farm. For workflows that handle deployments, these might be deployment targets like QA Servers or production.
- An originating workflow may only select one environment, while a non-originating can select any number of target environments.
Notification Scheme. Determines who to notify of build status, what conditions to notify them on, and what mechanism to notify them with.
Lockable Resource. Specifies a resource that might be used by multiple workflows, gives it a name, and forces arbitrary workflows to run one at a time or in small groups.
Properties. Identifies various properties that must be specified when the workflow is executed. See Workflow Property.
Triggers. Allows workflow to be kicked off automatically.
Source Configuration (Originating Only). Specifies the source that should be used for the workflow. Often this means selecting a branch of your project to run a workflow against. By creating a workflow for each branch, the stamping strategy used for each can be unique, while activities and jobs only need to be configured once.
Stamp Mapping (Originating Only). For every stamp style in the project’s stamp style group, one must specify what stamping strategy will be used. A typical stamp style group might specify the styles of development and production. In the workflow, you map the concept of a style used for development builds to a version number and strategy for incrementing that number.
Dependencies (Originating Only). Specifies the specific artifacts, including version, from other projects that should be retrieved in order to support the workflow. Also specifies the artifacts from other projects and the directory in the checked-out source that those artifacts should be placed in.
Artifacts (Originating Only). For any artifact associated with this project, the files produced by a workflow published as the artifact.

Workflows can either be created for individual projects or be used by multiple projects. To use the same Workflow for multiple projects, a Workflow Library (Workflow Definition) is created. Once configured, Workflow Definitions are added to existing projects as part of the project-workflow creation process (on the project-workflow Definition tab). Workflow Definitions do not necessarily have to be placed in Workflow Library folder. Any Workflows (on the Administration page) not in a folder or as part of a project subdirectory are Workflow Definitions.