Software Configuration Management (SCM) is a specialization of configuration management on all activities and results in the field of software development as well as their use in products. This includes, among other things, the appropriate consideration of docking native product components and their variants (e.g. via compatibility matrices) over the entire product life cycle. SCM systems are heavyweights of software development. In addition to minimal requirements, which they provide in a highly advanced version, they offer small-scale rights management, variant management and sophisticated lifecycle management. They are significantly more complex than the lightweight version control systems.
Academic research on the subject takes place only on a very modest scale, and in the university curriculum of computer scientists, the topic of SCM often does not appear at all. As a result, many of the problems that arise and are fundamental to be solved are not present to the young academics, which in turn does not lead to any demand on the market. As a result, none of the large companies sees the need to occupy the market for themselves and thus create standards of the academic paths. The result is a strong fragmentation of the market and specific views on scope, terms, integrations, availability and compatibility.
Basic Objects of Software Configuration Management
Basic objects that an SCM tool must be able to map are project, file, configuration unit, baseline, and product.
---
Project
A project is characterized by beginning, end and scope. Because in development this generally means something bigger, this part is often called subproject, change, change order, change request, task or similar. Although it is possible to get by with only one hierarchical level, the work is usually cumbersome. Therefore, the tools specify several levels or allow them to be freely defined to ensure delegation to other people or teams. Typical hierarchies are Project Task Subtask.
File
With SCM, the file is usually considered a base object that needs to be managed. In addition to simple versioning, it is often necessary to branch out and reunite development for an accelerated production process. In detail, however, other problems are not considered when choosing the SCM tool but can lead to problems afterwards. It starts with the topic of Renaming the file, which is often not possible with simple version controls. Furthermore, the problem area includes moving to another directory or deleting. Directories are solved differently, sometimes ignored. The latter can either only appear in the image on the file system or also be versioned as objects.
The transfer between version control and the file system creates further complications when more than one operating system type needs to be supplied. Problem points are case-sensitive or their conflicts as well as special types such as symbolic and hard links, devices, pipes, etc. Other places to consider are character sets for file names and content, which must be handled separately, or timestamps. Because the operating systems support different times, Windows e.g. the creation time, Unix does not, such things would have to be handled but are omitted for most products. However, the change time is observed more often because it can take two possible values when played out to the file system: the actual time or the change time before archiving. The time to choose depends on the build system the user is using.
Baseline
Because there are numerous versions in the archive, there must be a mechanism that also identifies the related versions. This is called “tagging” or “baselining”. The possible variants that lead to the creation are numerous. Sometimes a view of the versions with rules is created and then marked. Alternatively, rules can also lead to this. The most sensible method, which is rarely sufficiently well supported, is change management using projects in which changes to processes may only be carried out if the processes are mature.
Product
The goal of software development is a product, which usually consists of one or more programs. The subdivision by-product is necessary so that the SCM tool can be used for multiple applications without being installed multiple times. For most real developments, the classification by-product is too rough. Therefore, there are usually subcategories, whereby this hierarchy often serves as a hook for access permissions.
SW configuration unit
In this context, SW configuration unit means a suitable selected unit separated from other SW configuration units (e.g. operating system, driver…). This configuration unit is related to “any combination of other configuration units consisting of hardware, software, Infoware or services”. SW configuration management is therefore not per se bound to a specific application context and system configuration.
Other objects
Practically always exist, depending on the philosophy of the tool, other objects. These often concern the relationships of the objects with each other or the view of them, especially the files (views, worksets). It can be assistance for dealing with certain operating systems, group permissions, delegations, external processes, etc. The problem of how version changes are made to databases remains unresolved. The pragmatic approach is to manage the SQL scripts, but it does not solve the problem that both the data model difference to the predecessor and the rebuild must be provided.
Version control systems
The use of version control systems has now become a matter of course in software development. One speaks of a total of four generations of software version control systems. The first two generations are determined by centrally held data storage. The third generation is decentralized, see Git, Bazaar, Mercurial. Especially in open source projects, the decentralized version control system “Git” occupies a dominant position.
While software configuration management is part of the software design process – and thus part of software design – the version control of software is an independent undertaking.
In some cases, the tasks of an SCM are handled manually in Version Management.
A typical scenario found in companies is version management, which is supplemented with databases based on Lotus Notes or Excel. On the other hand, there are powerful tools that are also used in the industry.
