Revision: Automated build scenario

Introduction

In case you can access Radical wiki we have full description of build tooling use cases

Build tool (CCB) is used for construction of many Rational products. Each product is subdivided into a set of smaller components which are built in parallel. Builds can be kicked off either from command line, or from RTC IDE either manually or on a schedule.

Scenario 1: single product build

1. A build request is made, either explicitly by a user, from a schedule, or triggered by another event such as a source file change.
2. An associated build result is created and tagged with a unique version number that’s higher than the version numbers of all previous build requests associated with the build definition.
3. A bill of materials or snapshot is created. This bill of materials contains the version numbers of everything that affects the build result. This information is published to the build result. The purpose of the bill of materials is to make it possible to re-run the build.
4. Using the bill of materials, the source code is fetched. This could either be done by the build tool (CCB, for example) or by the build system that invokes the underlying tool (RTC, for example).
5. The build runs, creating artifacts (downloads), running predefined analyses and scans, and running user defined tests.
6. As the build is running, information on artifacts, scan results, and test results are published to the build result and visible to the user. That is, the user does not need to wait until the build is complete to see these results.
7. The build completes.
8. The state of the build result is changed to indicate that the build is complete and has a specific state such as pass, fail, or warn. It’s unclear how many states there should be or if they should be user defined.
9. Consumers of the build should be notified that the build is complete and given information that lets them find the build result.
10. After the build is complete users may want to augment or modify the information in the build result. Here are some examples –
    • marking a build result as a milestone or released build,
    • tagging it for cleaning or preservation,
    • changing its status to fail after running additional tests,
    • augmenting its state after performing additional operations (adding translation or intellectual property information),
    • adding information about where find artifacts after mirroring them to additional sites.

Scenario 2: main product build followed by system test build

1. Same as Scenario 1 but in addition as soon as main product build is complete, a second (System Test) build is kicked off
2. System test build executes a set of tests based on artifacts produced from the main build
3. System test build publishes its results to the main product build
4. System test build may want to change the state of the build result. For example, the state should be changed to indicate that additional tests were run. Also, in some cases, we might want to change the state from pass to fail (or vice versa).
5. When the new test completes, there should be a notification to consumers.

Scenario 3: stack of product builds (special case for Scenario 1)

This is the case when several interdependent products (like CLM which consumes Foundation, RQM, RRC, etc) are built in certain order based on their dependencies.There’s a definition (or plan) for the whole stack, each invocation creates a new build result, at the beginning of the build it creates a bill of materials, when the build completes it creates a status, and notifications are sent out. I’m not going into details about how dependencies between products from the stack are managed (except that downstream build results will likely be accessed from main stack build to determine if the build should continue). Product builds from the stack can happen in parallel too.

1. Stack product build is kicked off which in turn kicks off downstream product builds
2. Jazz build results are created for both stack build and individual builds from the stack
3. As each downstream product build finishes it publishes its artifacts to either is own build resuilt or to the stack build resuilt or both
4. When all product builds from the stack are complete the stack build result is completed
5. Optional. Same as Scenario2 but applied to the stack build. This is the case when test build for the whole stack is executed.