We continue the series of articles about Software Configuration Management. Recall that Software Configuration Management (SCM) is the management of work product sets and their versions. In this part, we will pay attention to the configuration for component development and configuration of product lines.

Configurations for Component Development

Similar to the basic approach, it is also used for component development. Within each component is work, in the work products and their configuration elements there are constantly changes, it is necessary to periodically, or at the request of management, to stabilize. Each component does this in the general case on its own and with the schedule that is required for it. Therefore, for example, for one team, stabilization and release release is done 5 times a week, for another one – once in 2 weeks.

Since components are integrated into a single whole, there must be separate procedures and resources for such a system integration. In this case, the work of the integration command of the higher-level component or the entire system is only slightly different from that of the component integrators. Only the scale differs, and also, perhaps, the tools and criteria for assessing the maturity of the releases received.

In particular, after the integration of the entire system, you need not simply pass regression testing of each incoming component. It is necessary to drive out system tests that test the interaction of different parts of the system with each other – as a rule, this is not included in the testing area of each individual subsystem. In addition, the SCM command of the entire product may need to collect additional metrics. All this requires large resources and some refinement of the policies of the SCM command of the higher-level component.

Product Line Configurations

How do SCM policies change in the case when we have not one product but a whole lot of them, i.e. product line? Everything becomes much more interesting. Of course, work within component commands continues the same way as in other cases. Their interaction with each other changes.

First, the component command must take into account all possible dependencies of their code on other components. And take into account that the interfaces and behavior of some functions may vary from product to product. Tracking dependencies is a separate big topic, so do not touch it yet.

Secondly, the order of integration of each component into final products is changed. Now every basic configuration should be given to integration only in those products that require the functionality developed in it. Or it is necessary to check that the new functionality intended for one product does not suddenly start working in the other and cause breakdowns.

Thirdly, the developer must constantly think about how his changes will work on different products. After all, they can be involved in completely different sets of functionality – so in the code you need to do appropriate checks.

This is followed by two possible lines of behavior of the component commands:

1. Production of so many component lines, how many products are now in work and maintenance. An overlaid version in terms of tracking changes and configurations, and also difficult from the point of view of integrating the same changes into different component rulers.
2. Support for all products and their functionality sets simultaneously in one component line. At the same time, it is necessary to organize the code in such a way that it is possible to flexibly “turn on” and “turn off” the functionality through the settings during the “tune-up” of the system or during its installation and commissioning. There are also overheads for developers who, expecting each change they make, have to consider how this change will affect the performance of each feature affected by the modified code.

Hence the behavior of the SCM command follows. It is necessary to take into account how the teams work and stabilize the components / products and release their basic configurations accordingly. In general, this topic is extensive and is a separate article with a large number of examples from life. So far, we simply take for granted the following circumstance: products and components have properties to branch out and policies, and project documentation for SCM must take this into account.

Of course, the material presented is not exhaustive, and this topic can be studied for a long time and deeply. We have tried to touch upon all the key points and important aspects of the Softwares Configuration Management theme.