About Engineering Workflow Management Build

Edit online

The Engineering Workflow Management Build component of the Jazz® technology platform provides support for the automation, monitoring, and awareness of builds for teams. The Engineering Workflow Management Build provides a model for representing the definitions, engines, and results for team builds. The model supports teams with different build technologies.

Jazz includes the Jazz Build Engine and an Ant build toolkit that can publish build information to the Jazz repository. The build toolkit is best suited for Ant builds, but you can also use any scripting technology that can invoke Ant. For example, a team can use Perl, DOS batch files, or Make, to create build scripts that interact with Engineering Workflow Management Build.

A team typically has a build system that runs builds from a dedicated machine. The Jazz Team Server is situated between the developers and the build system. The following generic build-related items are stored in the Jazz repository and support the build process:
  • Build definition: Defines a build, such as a weekly project-wide integration build.
  • Build engine: Represents a build system that runs on a dedicated server.
  • Build request: Represents a request to run a build.
  • Build result: Represents the output from a build.

All build-related items belong to a project area. Build-related operations are governed by the project process.

You can use the Jazz client to perform the following tasks:
  • Submit a request to run a build definition.
  • Check build status.
  • View completed build outputs, such as logs, downloads, and artifacts.

Builds and Engineering Workflow Management source control

Jazz builds can have traceability between change sets and work items. You typically run a build against files that come from a designated build repository workspace that has incoming flows from the main development stream for the team.

The following table describes the relationships between the build, source control, and work item concepts that are illustrated in the following figure. The figure shows the traceability between change sets and work items when you run a build against files from a team stream.

Table 1. Build, source control , and work items
Stream → Build Workspace (accept) Source control changes are accepted into the build workspace.
Build Workspace → Build After the accept operation, a source control snapshot is created, which captures the baselines across all components in the build workspace. The build links to both the build workspace and the snapshot. Also, Included in Build links are created between the build and any work items that are associated with change sets that were accepted.
Build → Stream The snapshot can be manually promoted (using Set Owner action on the snapshot) to be associated with the stream instead of the build workspace (for example, for release builds). The Post-build Deliver option in a build definition can also perform this promotion of the snapshot to the target stream of the deliver.
Build → Release A release can be created and associated with the build (using the Create a release to associate with this build action from the build result).
Release → Work Item After a release is created, it becomes available as a choice in the Found In field of work items in the same project area as the release.
Build → Work Item (not shown) The Included in Build links mentioned previously link directly between the build and the associated work items. In addition, if you use the Create a new work item or Associate an existing work item actions from the build result, then a Reported against Build link is created between the build and work item. These are intended more for tracking issues with the build itself, not its content. When using Found In for an associated release, no Reported against Build link is created.
The figure illustrates the traceability between change sets and work items when you run a build against files from a team stream.