Software configuration management

from Wikipedia, the free encyclopedia

The Configuration Management Software ( SCM ), or software configuration management is a specialization of the configuration management of all activities in the field of software development .

SCM has several goals:

  • Definition and tracking of processes
  • Documentation of all processes
  • Versioning and conflict handling
  • Management of requirements
  • Increased efficiency in automated application creation
  • Integration of all existing tools
  • Access control

SCM is often understood as the version management of software .

Some of the tasks of an SCM are handled manually. A typical scenario encountered 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 industry.

Basic considerations

One speaks of four generations of software version control systems. The first two generations are determined by centrally held data management. The third generation is decentralized, see Git , Bazaar , Mercurial .

Academic research on the subject is very limited, and the subject of SCM often does not appear at all in the university curriculum for computer scientists. As a result, many of the problems that arise and which basically have 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 outside the academic path. The result is therefore a strong fragmentation of the market and each time idiosyncratic views on scope, terms, integrations, availability and compatibility.

Fundamental objects that an SCM tool must be able to map are project , file , configuration unit , baseline and product .

Project

A project is characterized by its beginning, its end and its scope. Because something bigger is usually meant in development, this part is often called sub-project, change, change order, change request, task or the like. Although it is possible to get by with just one hierarchy level, it is usually cumbersome to work with. The tools therefore specify several levels or allow them to be freely defined in order to ensure delegation to other people or teams. Typical hierarchies are project task subtask.

file

With SCM, the file is usually viewed as a basic object that must be managed. In addition to simple versioning, it is often necessary for an accelerated production process to branch out and bring the development together again. In detail, however, there are further problems that are not considered when selecting 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 control. Moving to another directory or deletion also belong to the problem area. Directories are solved differently, sometimes ignored. The latter can either only appear in the mapping on the file system or actually also be versioned as objects.

The transfer between version management and the file system creates further complications if more than one operating system type has to be supplied. Problem points are upper and lower case or their conflicts as well as special types such as symbolic and hard links, devices, pipes, etc. Other points that must be observed are character sets for file names and content that must be treated separately, or time stamps. Because the operating systems support different times, Windows e.g. For example, creation time but not Unix, such things would have to be dealt with, but they do not apply to most products. However, the modification time is observed more frequently because it can have two possible values ​​when it is exported to the file system: the actual time or the modification time before archiving. The time to be selected 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 versions that belong together. This is known as "tagging" or "baselining". The possible variants that lead to the creation are numerous. Sometimes a view of the versions with rules is created and these are then marked. Alternatively, rules can also lead to this. The most sensible method, which is rarely well supported, is change management by means of projects in which changes to processes may only be carried out when the processes are mature.

product

The aim of software development is a product that usually consists of one or more programs. The subdivision by product is necessary so that the SCM tool can be used for several applications without having to be installed multiple times. For most real developments, the classification by product is too rough. That is why there are mostly sub-categories, whereby this hierarchy often serves as a hook for access authorizations.

Configuration unit

In this context, configuration unit means “any combination of hardware, software or service”. Configuration management is therefore not tied to a specific application context and system configuration per se.

see configuration management (KM)

Other objects

There are practically always other objects, depending on the philosophy of the tool. These often concern the relationships between the objects or the view of these, in particular of the files (views, worksets). It can be assistance in dealing with certain operating systems, group permissions, delegations, external processes, etc. The problem of how version changes are carried out on databases is still unsolved. The management of the SQL scripts is a pragmatic approach , but it does not solve the problem that both the data model difference to the predecessor and the new structure have to be provided.

Real considerations

Data storage

It was shown above that the structures in an SCM tool are mostly hierarchical in an indefinite depth, while the individual parts usually have the properties of objects. This makes storage in the widely used relational databases difficult, because the structures and flexibility are difficult to map in a high-performance and maintainable manner. The history of IBM with its SCM tools makes it clear.

IBM originally used CMVC with a relational database for Windows and Unix . His successor was TeamConnect , which was based on Objectstore , an object-oriented database. The next version switched to DB2 . IBM ended the line and bought the company Rational, which Clearcase had in its portfolio. The application is based on a self-developed, object-oriented database, while the supplement Rational ClearQuest uses various relational databases for process tracking .

The Dimensions product , on the other hand, uses Oracle as a relational database , supplemented by the server's file system as a version archive. The data model is only partially normalized .

compatibility

The lack of academic research and the lack of market power of a single manufacturer as well as the complexity only hinted at above, which increases significantly on the time axis, ensure poor compatibility between the individual products. The manufacturers do provide tools that bring the data into their product when they switch, but this happens at a very low level. A migration is therefore to be planned precisely, very time-consuming and consequently mostly incomplete because the costs far exceed the benefits of the old data. After the introduction, further substantial investments have to be made so that the SCM environment can be used and maintained. Manufacturers are aware of the situation and use it to restrict competition to sales. An operating system will only be replaced if there is a wide gap between requirements and the provision of solutions.

Integration into the development environment is also always poor. The only widespread standard SCC from Microsoft is designed for pure version management, but is used by manufacturers for much more complex things. As a consequence, this means that development and administration tools often require specific version combinations in order to function with one another. However, if these versions are also dependent on other factors, the empty set can quickly emerge as the intersection. It is therefore not uncommon for a deeper integration to be omitted or the transitions to show breaks that usually also open security gaps (unofficial versions). Project management, SCM, development environments and test tools should be integrated in order to largely automate the work process.

There is also no difficulty in getting an SCM tool for Windows and a well-known Unix variant ( Linux , Solaris , AIX , HP-UX ). But beyond that, platforms such as MVS , AS400 , OS / 2 or even more exotic ones are only sporadically, often not supported at all, apart from open source version management.

Demarcation

SCM systems are heavyweights in software development. In addition to the minimum requirements outlined above, 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 .

Company introduction

The introduction to operation is difficult and usually a strategic decision. The costs are not limited to the purchase and maintenance for the first year, but include numerous consultations that are provided by the manufacturer at high hourly rates. This business model is tolerated or even wanted by the manufacturers because secondary literature on the products does not exist. The product documentation is mostly limited to explaining the details, but leaves out the interaction of the components to achieve a desired goal. Furthermore, costs are to be expected for user training because most of the products are not self-explanatory in their use or, if the basic product is user-friendly, the complexity of the company processes cannot be represented in a sufficiently simple manner.

In addition, the development teams usually hinder the introduction because processes and working methods often have to be changed, ongoing business is disrupted and “it is not necessary”. The use of the SCM tool typically accelerates the work, but the added value, because it is mostly based on small details, cannot be assessed in terms of costs and therefore cannot be used for argumentation. It is also rarely seen that prescribed or desired reports can be created automatically.

In Germany, the approval of the works council is also mandatory because all changes are logged for each employee. This means that the SCM tool can be used to monitor performance.

Product overview

There are many different systems on the market. An overview of better known products:

Open Source:

The following products are not SCM systems, only version control systems:

See also