Basic Theory of Configuration Management

The goals of using CM are to ensure the integrity of a product and to make its evolution more manageable. Although there is overhead involved in using CM, it is generally agreed that the consequences of not using CM can lead to many problems and inefficiencies. The overhead of using CM relates to time, resources, and the effects on other aspects of the software lifecycle", Susan Dart, CMI.

Many people falsely believe Source Code Control tools or Automated Configuration Management to be a silver bullet for curing all software development ills. However, implemented properly, it can increase the effectiveness of your development and maintenance efforts and lead to better software, and reduced costs.

Lets begin at the beginning. The terms Source Code Control and Configuration Management, are often bandied about, but what do they mean?

Traditional Source Code Control

When many software developers think of SCM/CM they think of of traditional SCC,

• Source code is checked in/out
• One or more developers can check out a file
• Rule based Merging of source code
• Basic archive kept of previous versions.

Tools like CVS and PVCS VM fall into this category. Whilst PVCS VM does have some higher end CM features, it is still primarily a SCM tool.

Configuration Management

Configuration Management takes a much broader look at the process of developing software. The degree to which a particular tool implements CM features varies greatly, however they include:

• Dynamic and insulated views / work areas
• Work flow automation, including online bug reports, and audit controls
• A developer is kept informed of changes relevant to the area in which they are working by e-mailed or other means.
• Changes may only flow from one view to another under defined rules (e.g.: after sign off, code review etc.).

These features make implementing source code control much more worthwhile for the software developer. Allowing each developer to create software in an insulated work area, updating with outside changes at their discretion leads to a much better working environment than one where one developers 'build' is constantly being broken by another developers 'fix'.

With CM developers work on checked-out versions of objects to prototype, edit, build and debug before making their changes available to other developers, without being isolated from the development process.

Read more about Uniface Version Control

•  1. UD6 Overview
•  3. Configuration Management applied to Uniface
•  4. Comparison: VC-Link (PVCS-Uniface Bridge)
•  5. Comparison: Uniface 8 (SCCI Bridge)
•  6. Clustering: What is stored where in UD6
•  7. NLS Support Overview
•  8. UD6 Option Pack
•  9. System Requirements
•  10 UD6 Article Links
•  11 Uniface 8 Migration
•  12 XMLGREP Search and Replace
•  13 UD6 Performance Optimisation
•  14 MAKE Build Management
•  15. UD6IDE: Eclipse editor for Uniface 6, 7, 8 and 9
•  16. theu.info - You in Uniface

References:

The Beginning to your CM Solution, Nadine M. Bounds, Susan Dart.
Configuration Management Frequently Asked Questions, Version: 6.7c

$Revision: 1.10 $ $Date: 2013/09/24 06:51:57 $

[go to top]