Code versioning and building for Rational team concert

This article expands the RTC construction function, simplifies the user operation, facilitates the http://www.aliyun.com/zixun/aggregation/7155.html "" "" "" "" "" " and prevent the newly committed code from causing the build failure dependency. At the same time, the results of the comparison of the construction of the expansion, can quickly compare the new features rather than a simple changeset. Finally, automatic deployment is done by customizing the user Configuration.

The Rational Team Concert (RTC) is a collaborative software development environment built on the IBM Rational next-generation collaboration platform for software delivery technology, which includes integrated source control, work item management, and build management capabilities. The RTC has a very strong automatic build capability, and its supported build process is as follows:

Build definition: Define a build, for example, a weekly project scope integration build. Build Engine: Represents a build system that runs on a build server. Build Request: Represents a request that requires a build to run. Build Result: Represents the output of the build.

All building-related items are part of the project area, and the build-related operations are managed by the project's processes. The RTC can also complete the following tasks:

Submit a request to run a build definition. Check the build status. View completed build outputs, such as logs, download resources, and artifacts.

However, because the current RTC code version management and construction is relatively independent, the lack of timely and correct inspection of the construction of the final results of the mechanism. Only after the newly added code has been submitted to the workflow (work stream) can the developer verify that the newly added code will affect the entire system's build. If the developer forgets to verify the correctness of the build, submits the code to the final workflow (work stream), the newly added code can cause the entire system to crash; Moreover, the comparison of the build results is relatively simple, and there is currently only a comparison of the different build result changesets (change set). However, the difference of the work iteam corresponding to the change set cannot be viewed directly, and a lot of manual operation is needed to find out the work iteam of fortune-teller associated with the change set to meet the actual demand. However, the RTC is a platform with extremely strong extensibility, as shown in Figure 1:

Figure 1.RTC Extension Schema

We can extend the RTC through the REST API and the Plain Java API. The Plain Java API also includes the Work Item API, the Source control API, and the build API.

Figure 2.Plain Java API

Where the build API provides three main interfaces:

Iteambuildclient: Used to access build iteambuildrequestclient in Repository: The request to create, get, and manipulate builds Ibuildrequestquerymodel: query build Results

This article will focus on how the build API can be used to automate the implementation of the RTC extension. By applying the build API to consolidate the execution of code submission and construction, this allows developers to submit their own code at the same time to build their newly added code, to verify that it will affect the entire system construction, can be found in a timely manner and resolved; Thus, the work iteam of the construction result is compared; Finally, we introduce how to introduce the custom parameters into the automatic construction of RTC.