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.

Outline of the use case for building a chance request, as worked on by the ALF build vocabulary committee:

Second version from ALF build vocabulary call 7/17/2006

We are assuming that the calling service that is requesting a build does the necessary prerequisite preparations and integrity checking, such as checking for files not checked in yet associated with the CR, creating the proper workspace to build in, etc.
While this use case was designed with the use of a CR system in place, it is not necessary to have a CR / tracking / defect system in place to execute this build use case in ALF.

• Step1:
  Request is made (ALF event raised in CR/SCM system) to build service to build a unique CR id
  
• Step1b:
  Should the state of the CR be checked first before the build proceeds? A: keep as a branch, but in general we will not be doing any redundant or sanity checking
  
• Step2:
  A workspace needs to be prepared for the build. Need a reference/link to a shared workspace that has been previously generated
  
• Step2b:
  Miscellaneous integrity / sanity checking could go here; by default, the build service flow will not re-verify a workspace that is referenced.
  
• Step3:
  Build
  
• Step4:
  What to do with build results- derived objects, binaries, reports, etc ? Produce a list of build results, reports, other artifacts that maybe of interest to the calling service. Can’t assume the build environment has client access to the SCM / CR tool. The calling service should have access to the same file system workspace it created before it initiated a build service request.
  
• Step5:
  Raise an event in ALF captured by the service flow mgr - the build is complete
  
• Step6:
  Updating the CR item – the CR system can act on the CR depending on the build event status results and associated list of produced items. If no CR system is in place, the event is simply ignored.
  

Steve noted that we could re-use this basic use case template for SCM requests, enhancement requests, helpdesk requests, etc. since the build logic is now isolated from specific SCM and CR operations being performed. Events raised can be captured and acted upon if the user has other tools or technologies hooked into ALF, but if they do not it still does not hinder them from taking advantage of basic build capabilities within ALF. This “purification” of the build use case logic should also allow for a more efficient execution, but again assumes the proper verifications and integrity checking have been performed beforehand by the calling service.

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.