How to develop an effective configuration management process

The following is an example of our actual work, and this example fully illustrates the importance of the correct workflow to ensure the quality of the SOFTWARE PRODUCT.

1 Problem Description

A development team for their customers to develop business software, the system has a lot of changes in the business requirements, but also many business units in the use of the software defects found in the process, we have to change the requirements and software defects collectively referred to as changes. The development team needs to respond quickly to the customer's request for change and install the corresponding software version to the production system in a timely manner.

To ensure product quality, the development team has established the following software release processes:

These four links correspond to the following four different environments:

Development environment: developing and implementing customer change requests

Test platform: Development team to do internal system testing before releasing software to customers

Quasi-production environment: customer to do the acceptance test before releasing the software to production system

Production System: The final production system

When the development team submits the change implementation to the user acceptance test, any changes that have not passed the acceptance test will be rejected, and only changes through the acceptance test will be deployed to the production system. The entire process, as shown in the following illustration, assumes that the development team implemented a total of 3 changes, in which change 1 and Change 2 passed the system test to submit the user acceptance test, but only change 1 passed the user acceptance test, and finally only change 1 was deployed to the production system.

To support this workflow, the team managed four source code versions in the Configuration management system:

The source code version of each change in each link will be copied to the next link's version baseline. It seems to be a very reasonable process, isn't it.

2 Quality Traps

Let's take a look at the two application cases for this process.

Scenario I: Untested version combinations

In the following example, the file F1, F2 before the modification of the version is 1, after the implementation of the change 1, change 2, their version has become version 2, expressed as F1 (v2), F2 (v2). Throughout the testing process, the version of the code tested on the previous three environments is always version 2 of file F1 and F2, but the final change of 1 did not pass the acceptance test and the change of 2 was passed, and the version that was eventually deployed to the production system would be:

F1 (V1, this is the original version of F1 on the production system)

F2 (v2, which already contains the corresponding version 2 of the Change 2)

But F1 (v1) should be a combination of versions that match F1 (V1, change 1), and the F2 (V2) matching version should be F1 (v2), which could result in:

An untested version combination is running on the production system!

Scenario II: Untested versions

In the following example, in the previous three test sessions, the version of the file F2 was tested in version 4. When change 2 fails the user acceptance test, the file F2 is eventually copied to the version 3 on the production system, and this version is untested.

The result was unbelievable:

is the untested version running on the production system ?!

Any software system, all its code should be delivered as a whole, rather than just part of the code (change-related code) as in the example above, which is the root cause of the quality trap. There is an inherent flaw in a seemingly reasonable process.

3 Improvement Suggestions

To avoid the quality traps described above, we should improve the existing configuration management process. 3.1 Establish a closed-loop quality assurance process

The root cause of this quality risk is that the system code is not being treated as a whole, and that we are releasing the source code during the release process, and that the correct process (and the industry's more common practice) should release the build target code rather than the source code. We can create a closed-loop quality assurance process (as shown in the following figure) to distribute the software in batches.

The defects found in the system testing process should be corrected by the developers in time, and then build, then test, until a relatively stable version will be released to the acceptance Test link. Similarly, problems found in acceptance testing will be restored to the development process. This should be a process of multiple loops, constantly discovering errors, then correcting them, and then testing them. When does this cycle end? This depends on the actual situation of each software project:

Ø the ideal situation is, of course, that all defects are corrected, but the time spent is longer and may not be able to keep up with the project's schedule, and the actual work is unlikely to do so.

Ø The tradeoff is that all the serious flaws (i.e. those that affect the system's use) must be corrected, but allow some of the found defects to be left behind to resolve, provided that the remaining defects do not affect the implementation of the other changes. It's usually the case that the known defects (known Defects) listed in the release notes are often seen in a new version of some commercial software.

When we presented this proposal to the development team, we were immediately objected to by the project manager: "There are some urgent changes that the customer needs to implement immediately and deliver the production operations, and there is little time to go through the complete closed loop process." " 3.2 differentiate between defects and new features

By further understanding we find that urgent changes generally refer to software flaws that affect the normal use of the system, which need to be fixed in a timely manner, and that new requests for functionality are generally less urgent and allow the development team to develop the implementation for a period of time. But developers are now mixing all of the urgent and non-urgent change requests together, often a critical flaw has been fixed, but another new feature being developed also modifies the same set of file versions, resulting in a version dependency between the two, resulting in an emergency defect fix not being submitted on time.

We recommend that the repair of defects and the development of new features be differentiated, which involves multiple versions of concurrent development, with the development team facing the development of the following three versions:

Repair of defects in øv1.0

Øv1.0 's new feature version v1.1

Ø Next Version v2.0

Such bug fixes and new feature development are independent of each other, ensuring that emergency bug fixes are not affected by new functionality. 3.3 Release builds (build) instead of source code

In this case, there is a separate configuration management practices in the development, testing, acceptance, production of four aspects of the release of the source code, each need to build (including the compilation) before deployment to the corresponding platform. As the results of software builds are likely to be affected by the build platform and the corresponding compiler version, the final operating code on the production system (built on the production system) and the running code on the quasi-production environment (built on the quasi-production environment) may not be exactly the same, potentially creating a quality hazard. It is more common practice that the build code that runs on all platforms should be generated only once on the build server and run around once, to ensure that the same version of the running code used on each platform is the product of the same build. The build server is usually the same as the development platform, but if you are publishing a version of several different platforms, you can have multiple build servers, such as a running version of the AIX + DB2 platform and a running version of the HPUX + Oracle platform for the same software.

In addition to some special operating environment, such as the IBM Host System (mainframe) explicitly requires the operating platform for the source code to build, the development of general software systems can follow this principle of work.

Release management for release 3.4

For the released build, we also need to be managed in an orderly fashion, with a version number to uniquely identify each release version. It is generally possible to refer to the internal release version of the internal system test for the development team, which is referred to as an external release, and the two release versions of the software are unified numbering management. In our example, an internal release version can be simply represented by a build number, such as:

V1.0_build_008 represents the 8th build external release build generated during version v1.0 development can be combined by version number and publication number, such as:

V1.0_REL01 represents the first external release version of version v1.0

For bug fixes in v1.0, we can release it through patches, a patch can contain multiple bug fixes, and the repaired defect needs to be stated in the patch's release notes, and the patch name can be combined by version number, release number, and patch number, such as:

v1.0_rel01_p001 represents patch No. 001 for release version v1.0_rel01

For new features in v1.0, we need to develop a release plan that based on the urgency of the customer's new feature request, a release can contain several new features and include all corrected software flaws that must be stated in the release notes, and the release version number can be incremented on the basis of the previous release, such as:

V1.1_REL02 represents the second external release version of the version v1.1

For the next version of V2.0 development, it is exactly the same as the release management developed by version v1.0, such as:

V2.0_BUILD_002 represents the 2nd build generated during the development of version v2.0

In the release management process, the release version should be installed by a dedicated role, either as a configuration administrator or as a set member (integrator), and developers are barred from installing any software on platforms (test platforms, quasi-production environments, production systems), and the version number of the software installed on each platform is tested. 0.0 Notes 11 should have detailed records. When a software flaw is discovered, we can clearly know exactly what version the problem is.

The internal release version will only be installed on the test platform, and the quality of the internal release builds up after several cycles of "developing à-build à-test" to discover bugs to modify code, and the development team decides to make an external release version.

External releases are installed in a quasi production environment and can only be installed on the production system through user acceptance testing. If the version does not pass the user acceptance test, then the development team needs to provide a patch to solve the problems found in the user acceptance, until the release and all of its cumulative patches are installed on the production system through the user acceptance. In some cases, the final acceptance test may also be the next release, so the release version installed on the production system is not necessarily contiguous, and the intermediate may skip some of the less mature versions.

Similarly, only patches that pass the user acceptance test will be eventually installed on the production system. Emergency patches after the user acceptance test will be installed immediately to the production system, the emergency patch can accumulate a few after the bulk installed up.

4 ClearCase Tools Implementation

Configuration management Tools IBM Rational ClearCase can support this parallel development pattern well. In the working mode of the ClearCase UCM (Unified change Management, unified changes management process), we can build on the version V1.0 release baseline (V1.0_REL01) for each of the three versions (V1.0_bugfix, v1.1, v2.0) development project (as shown in the following figure).

Under ClearCase Management, these three versions are located on different branches, their development is independent, and the defect fixes in version V1.0_bugfix can be merged into version v1.1 and v2.0 in time, version v1.1 The new features in can also be merged into version v2.0 when needed.

ClearCase also provides developers with a user-friendly working interface, ClearCase Explorer, which allows developers to easily select any version of the project for development, and ClearCase Explorer can quickly and accurately prepare the appropriate working version. So these three different versions of the development can be completed by the same group of developers, greatly improving the efficiency of development.

5 Summary

In this case study we see that the configuration management process is very important to ensure the quality of the software, the improper process may lead to potential quality defects, the development team needs to be based on the situation of their own projects to develop an efficient and reasonable configuration management process. With a good process, we also need a good configuration management tool to simplify our management to ensure the developer's productivity and software quality.