Stabilization

So, we have defined the working products, components, rulers. The development cycle begins. Work is on, working products appear, change, new components are created, rulers are divided. As always, at some point you want to stop, look back and understand – at what point the product is located, what and how has already been done, what are the plans. To get the full picture, you need to bring the development to some common denominator. From the point of view of management, this can be done in different ways – you can, for example, see the progress of work, get a cut of metrics, etc. – and further to make some decision concerning the distribution of tasks.

From the point of view of SCM, this means that it is necessary to stabilize the configuration of work products. For example, having a team of 20 people, you need to take all the pieces of functionality worked by different people – documents, code and other results – and bring them together.
Stabilizing the configuration is the process of obtaining a new configuration from the available intermediate configurations. The term “release” is also used for this process. The result of stabilization can also be called, in turn, a release.

For example, there is a basic configuration – version 1.0 of the product. There is an intermediate configuration – a new “feature” created by the developer. There are also 2 other configurations – corrected errors from the other two developers. Stabilization in this case will be the consolidation of the results of the work of all three developers and creating from them a new configuration, i.e. set CI, which form a finished product.

The resulting configuration is checked for compliance with the requirements of its constituent work products. Requirements can be varied, as a rule, these are quantitative quality criteria. For example, in the example with 3 developers, a similar requirement for the code is the successful passage of 98% of the regression tests. The code from all developers is integrated, the configuration is stabilized, the product is collected (for example, rebuilt) and given to tests.
Release notes are also made for the release.

The notes on the issue details:

• the name of the new release;
• the basis on which it is based (see “basic configuration”);
• the changes included in the release;
• a description of the procedure for upgrading a working copy of the system, if necessary;
• also, if necessary, includes a description of the procedure for self-preparation of executable files.

The upgrade point is optional and is used when the final system requires installation before starting work or development. For example, if you write software for mobile phones, this paragraph indicates how you need to flash this release.
The last item is added if the receipt of the final product requires additional action. For example, the process of starting compilation and linking can be described here.
If the configuration meets the requirements for stable releases, then the configuration is considered stable. For example, if the percentage of passed regression tests is 98%. At the choice of management or CM engineer, it becomes what is called “baseline”.

Basic Configuration

Baseline is a configuration chosen and fixed at any stage of the development life cycle as a basis for further work.
If we go back to our example of three developers, then the stabilized configuration has passed the quality assessment. The same is also necessary with the release of the basic configuration. Management (timed-lead or SQA) looks at quality indicators, as well as on other factors – for example, on the results of code inspections or something else that may cause doubts. Then he decides that the release should be taken as the basis for the work of all other developers, to be the basis for development. Then the CM engineer performs various actions (for example, hangs a label and rebuilds the product code) and the selected configuration becomes the base one. At the same time, it (at least in the form of source code) is laid out in an open for the whole team access.

A variant is possible when the configuration does not pass by the quality criteria and can not be used at all to assemble the final product. For example, the product has only just begun to be developed and only the code of the individual components is ready, and even those stubs instead of working functions. You need to make the configuration the basis for the whole team, but at the same time to avoid the release procedure – simply because you can not put anything together yet. Such a configuration also has the right to be used as a basic one, the main thing is to clearly identify the existing restrictions on use in release notes.

Any release of the basic configuration is necessarily provided with notes on the release. A team member, who takes a similar configuration for work, should know – from what it will be based on the work. You also need to know if there are new functions or bug fixes in the new configuration, on which its work can depend. It will not be superfluous also to know whether any special procedures for upgrading its instance of the system are necessary before using a new development database. All of the above information is given in the release notes.

In many teams, the results of integration work (appearing releases and basic configurations) are laid out in a specially designated place – release area. The organization of this area and its maintenance in actual form is the task of SCM engineers.

The diagram shows a small example of the appearance of configurations in time. The initial state of the project is configuration 1. It is also the first basis from which further development will take place. Suppose the project is at the initial stage. After some time, an updated  appears configuration 2. The development has just begun and we released the release to give the team at least some basis for further work. During the audit, it became clear that this edition can not serve as a base for work – there are incomprehensible and contradictory places.

To eliminate them, development teams are making improvements. As a result, configurations 3 and 4 appear – they are both based on 2, but they do not agree with each other, because they do not include changes from each other. The SCM engineer creates the final configuration 5, based on 2, 3 and 4. After verification, management gives a visual – the basic configuration is! For this signal SCM-team releases this release as the official base configuration and the developers take it as the basis.
Then the story repeats – the development team makes changes – the  appears configuration 5. It is in turn integrated by the SCM engineer and it gets the number 7. It also becomes the official development base.