ALF/Build Use Cases

Assumptions

These Build Use Cases assume that an SCM tool or another process has populated the build area and source code locations with the appropriate files to be involed in the build. To keep inline with the ALF Service Flow process the Build portion of the Service Flow will be notified to start running. The pre and post processing will be handled by the complete Service Flow which is constructed by the End Users.

• Best Practice Build Service Flow needed.

Build a Change Request

The problem management tool would provide the change request info which would execute a check out of the corresponding code from the SCM tool. The SCM tool would request an incremental build of only the changes or request a full build. The build results upon success would be checked back into SCM tool via an ALF notification. On failure, the problem management tool and development team would be notified.

Build a Requirement

The requirement tool would provide the enhancement request info which would execute a check out of the corresponding code from the SCM tool. The SCM tool would request an incremental build of only the changes or request a full build. The build results upon success would be checked back into SCM tool via an ALF notification. On failure, the requirements tool and development team would be notified.

Change Request Impact Analysis

The change request tool would provide the change request info which would execute a check out of the corresponding code from the SCM tool. The SCM tool would request an impact analysis report and return he information to the Change Request tool.

Audit Build for Non-approved components

The SCM tool would request a build that displays all components not managed within the SCM repository. The build would execute with dependency gathering, listing all components that were used in the build, but not managed within the SCM repository and return he report to the SCM tool.

Build with IT Compliance Audit

The SCM tool would request a build that created a audit trail showing all components used in the compile/link process and create a footprint validating matching source to executables. The footprint would be embedded in the executables and the executables would be checked back into the SCM tool.

Reproduce Build

The SCM tool would request a build of source used in a previous (historical) build. A build label or timestamp would be used to determine which files are to be included in the build.

Build Report

Also commonly known as a "Bill of Materials" output. A request would be made to obtain a human-readable format report that contained a summary of the metadata contents of the build. This can include build server-specific data like the hostname or operating system, time/date of build, who initiated the build, files used for the build, and the build results/output. For files that are under source control used for the build, the build application could make a request to the SCM tool repository or interrogate the local SCM workspace to display the version number next to each file used for the build. Further report data could also be included that displayed incremental data related to that build, such as files modified since the last build, or new activities/defects/issues contained in the build.