Cycle of articles on the basics of Software Configuration Management

Prologue

What is configuration management in software development? Why is it needed? I think few are able to fully and clearly answer this question. Most usually recall version control systems that they themselves use. Someone mentions bugtracking. Someone thinks the top of CM is growing branches in your favorite version control system. And someone even goes to the side and starts talking about ITIL and how it writes the parameters of all the software that it has installed in a company in some database.

Somewhat strange and a little annoying to watch it. The fact is that I worked at SCM for a total of about 5 years, of which 3 years I’ve been an integrator at Motorola, on one of the projects to develop software for cell phones. Along the way, I read a bunch of materials on this topic and gained a lot of practical experience - including working with one of the most powerful version control systems of IBM Rational ClearCase (see linkedin in the profile). As a result, a holistic picture of what it really is — a software configuration management.

And then I saw an article from comrade altern , in which he began to talk about CM. He went a little differently - on specific tools and the naming of configurations. Therefore, writing off with him, so as not to overlap on the topics of our articles, I decided to write about the basics of what is called software configuration management.

Now I have already written material of about 50 thousand characters - this is about 5-7 average size posts for Habr. And the writing process continues. I am going to post written with a small periodicity here and, as questions and discussions are exhausted, post new notes.
')
The task is to give an overview of what CM is all about, what tasks it solves and what techniques are used. It will not be about specific version control systems or tools at all - this is good bulk in the network. The task is to show the basics universal for all tools.

So let's go.

What is CM and why is it needed?

Configuration management

To begin with, let's define what a configuration is , because this word is displayed in the title. A configuration is a collection of versions of work products. Keywords - "product versions."

In any project there are work products - it can be marketing documentation, requirements for the final product, source codes, tests, auxiliary tools. What should be considered a work product depends on the project (the definition will be given in the next note). Further, each product changes over time (this is the point of development), and these changes must be somehow taken into account - who, when, what exactly made and why he did it. In other words, consider how the product versions appeared.

A version is a state of the work product that can be restored at any time, regardless of the change history.

Accordingly, configuration management is the management of work product sets and their versions. This process is the scope of the CM.

The English-language literature uses the term Software Configuration Management , abbreviated as SCM . Further, for simplicity, the term configuration management and abbreviation CM (read: “siem”) will be used.


Scheme 1. Elements, their versions and slices-configuration.

CM is one of the basic practices of any software development methodology. Suffice it to say that in the SEI CMM / CMMI (Capability Maturity Model Integration) model, the presence of a streamlined configuration management process is a necessary condition for an organization to receive a CMM / CMMI Level 2 certificate.

I note that Level 2 is the most minimal, initial level of maturity, according to the CMM model. Level 1 gets an "automatic" organization that has successfully completed at least one development project. Therefore, the presence of CM is the minimum requirement for certification. By the way, at the second level it is necessary to have, among other things, an established process of testing and managing requirements. This suggests that from the point of view of the CMMI standard, proper configuration management is as important as proper testing and requirements management.

So what is the value of CM?

Directions of responsibility CM

Configuration management works at all stages of the project life cycle. A working product appeared (for example, a source file) - it falls into the field of CM activity. The product has started to change (we are writing the functionality) - it means CM should provide the means to control the changes and automatically conduct the control itself where it is required. It was necessary to break the work into a team of developers, or even into several - the project CM provides rules and tools for work. There is something to offer the customer - then CM determines the rules for stabilizing development products and their release. It is necessary to roll back to an arbitrary release - again in the work of CM. It took change metrics or documented policies - well, you understood who to contact.

So, first of all, CM is responsible for identifying work products, i.e. responsible for determining what will be monitored in the future. In the next article will be described in more detail.

Products highlighted, then the team begins work. In the course of the work, it is necessary to periodically stabilize the results obtained, to draw some line under the developments, and also to determine the basis on which the development will proceed. All this is also within the scope of CM'a.

In addition, CM is responsible for what is generally called tracking change requests. Most of this area is known as bug tracking systems. After all, no changes should take place spontaneously - each of them needs to be registered and then correctly assigned and monitored - up to and including into the final product. Here again remains the extreme CM. We make changes to products, it is necessary to track them - version control starts to work. Nothing will be lost - CM is on guard.

Means for controlling changes and ensuring versioning create conditions for parallelizing development in large teams. This is achieved due to the fact that, having described these tools, we give developers documented procedures to share responsibility and limit the scope of each of the developers.

And, as always, “one cannot control what cannot be measured” - (c) De Marco. Metrics - a couple of words will be said about them too. Where measurements are, there is formalization. In other words, everything related to CM would be well documented. This will also be briefly mentioned.

So what are the configuration management tasks?

It:

• identification of work products;
• stabilization of work results and determination of the base for further work;
• tracking change requests;
• version control;
• ensuring parallel development;
• collection of metrics and formalization of applied methods.

Who is interested in reading a little more theory and imbued with the terms and formal descriptions of the area of ​​responsibility - to you to the CMM / CMMI standards (see links at the end), there it is considered a lot and fruitful. True, it is not always clear and almost always dry and boring.

For a start - enough. The next part will be devoted to how the products and configurations that we will manage are determined. I will also touch on the issue of component development, product lines and their relationship with SM.

Links to expand horizons:

1. en.wikipedia.org/wiki/Software_configuration_management Software Configuration Management on Wikipedia.
2. www2.computer.org/portal/web/swebok Software Engineering Book of Knowledge.
3. www.sei.cmu.edu/cmmi SEI CMMI Website.
4. www.cmcrossroads.com CM Crossroads the Configuration Management Community.

To be continued.

UPD : at the request of workers, a link to the second part: habrahabr.ru/blogs/pm/67839