About Engineering Workflow Management Build
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.
- 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.
- 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 figure below. The figure shows the traceability between change sets and work items when you run a build against files from a team stream.
|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.|