In a continuously evolving product, where it is extremely important to integrate the product components as often as possible, the integration of these components has to be reliable in terms of planning, controlling, coding, building and documenting.
In a continuous integration environment it is very hard to set up a development pattern, especially if you have never worked in an environment that practices it. Some questions have to be solved in order to keep control of the product evolution during its life cycle. The most important of these questions are: - How will the numerous components of the product be identified?
- What mechanism needs to be used to keep them under control?
- What makes a successful build?
- How will the release be secured?
Continuous integration needs a certain amount of discipline, and a software environment needs to be set up. The discipline is the configuration management, while the software environment is a version control tool that implements the parallel development (i.e. ClearCase, PVCS, etc). Reason for the continuous integration - Change of the set design base
- Implementation of unplanned features
- Reported problems to solve within the ongoing development
- Incremental development
- Incremental releases
- Maintenance
Planning The planning includes the identification of a product where a product is a collection of software and documentation. The identification must take the product evolution into account. The product should be structured in a top-down approach and the product components should be identified in accordance with this structuring. Furthermore, the product should be organized in a hierarchical structure, including all the possible components and variants. The product hierarchy can be set by product functionality, developing organization, or product characteristics. A number of variants should be planned for each product component and this organization should be translated into a version control tool. Design Base Once the product has been identified it can be considered as a design base. All changes onto this base should be monitored and controlled. A version control tool environment should be planned in accordance with the incremental releases or developments. Every change of the design base should be monitored through the configuration control system such as baseline reviews, configuration control and configuration audit. Implementation of new features or solved problem reports When a new feature should be implemented, a separate environment in the version control tool should be set. The parallel development should involve a clear and dynamic strategy for branching and labeling. Another problem comes out when integrating the new functionality with the ongoing development or testing. An integration plan is needed as input. In accordance with this plan some of the software should be labeled, compiled and tested. Furthermore, the related software documentation should be identified and changed accordingly. Incremental release An incremental release is when the software is released in stages. Each stage should be consolidated, and the status should be set as ready for release. In a version control tool that organizes the software in branches it can be seen as merging the software from a development branch onto the main branch (see [Figure 1]). Meaningful labels must be set to make this operation clear. Maintenance During the product maintenance phase, several versions of the same product configuration change due to problems encountered on the design base. The most important aspect is to control the integration of the problem solution into onto ongoing development. Each problem report should clear identify what individual component they involve, and the problem to be corrected. The merge operation between ongoing development and maintenance corrections must be well organized. The product revision should increase every time the product changes due to maintenance releases. Continuous integration in a daily life [Figure 1] shows the ClearCase scenario of a continuously evolving product. Each arrow represents integration between product versions (merges) [Figure 2] is an example of a product baseline. Conclusion To integrate a continuously evolving product there are some major points to sort out: - Keep clear what are the cases of continuous integration:
- o Change of the set design base
- o Implementation of unplanned features
- o Reported problems to solve within the ongoing development
- o Incremental development
- o Incremental releases
- o Maintenance
- Identify the mechanisms to control a continuously evolving product (discipline and tools)
- Define the scope of the product (Planning)
- Identify each product component (Software and documentation)
- Organize the product component in a hierarchical structure
- Set a product design base
- Translate the product structure into a version control tool, that implements the parallel development
- Define the tool such as branching and labeling
- Plan the integrations, and use this plan to organize the product components merges.
- Control the product integration by setting an integration plan
The most important thing when is a continuous evolving product is what when and how to integrate the product components. The control of the changes is also important to keep the tractability between the requirements and the final release. The configuration management discipline provides the method while a good organization of a version control tool, provides the instruments for a successful integration.
Sabrina Tafuro
Sabrina Tafuro is a contributing editor for Crossroads and has worked in the CM field since 1996. She has experience with CM methodologies and processes in both spatial and telecommunication environments. She also contributed to set up the Ericsson corporative configuration management process. Sabrina also has experience in Software Development, Quality Assurance, and Requirement Management disciplines You may reach Sabrina by email at sabrina.tafuro@ericsson.com
Trackback(0)
Comments 
Write comment
 |