Software Configuration Management // Configurations and baselines
So, in hot pursuit, I continue to publish materials concerning the basics of software configuration management. Read the previous note if you suddenly missed it.
Below we will discuss the following things:
- Work products and configurations;
- Component development;
- Product line;
- Stabilization of work results;
- Baselines AKA basic configurations;
- Configurations in component development;
- Configurations in the presence of product lines.
What will be the working products within the project? It is clear that for marketing and management the product will be exactly one - the one for which the company will receive money. Well, or several, according to the number of types of boxes issued to the market. We are also interested in the “lower level” - what the task designers, developers, testers, and in general each project participant will operate with. The task of the CM is to determine the set of those elements that will be created and changed by the team. At this stage, the concept of a “configuration item” appears. This is an atomic element that is most convenient to manage within the framework of development. In the following, we will simply call it “CI” .
')
This includes such objects as:
It turns out that CI is any file within the project? No, we are only interested in those files that are necessary and sufficient to create the final product for the customer. Therefore, we will not need utility and intermediate files generated by compilers, interpreters and IDEs. We are also unlikely to be interested in entries in blogs and forums, project correspondence and other communication products. Of course, the CM project document will describe the means of communication within the team - but no more than that.
Objects falling under the action of CM include any objects supplied outside (installers, marketing materials, etc.). Although they can be obtained from the above work products, but the final product, issued to the user, also needs identification.
How are these configuration elements, atomic units of account, organized within the project?
They are added together according to the architecture of the application itself. After all, developers tend to reduce the complexity of the systems produced. To this end, they decompose what is created into interrelated parts - classes, components, libraries, subsystems, etc. Simplify the terminology and in the future any component parts of the created systems will be called components . CM, on the other hand, takes this organization as a basis and structures its work products accordingly using its tools and policies.
Components are becoming new configuration items. They become independent work units, also subject to unified control. In addition, they can even install their own development process. In this case, CM practices are necessary in order to control these separate blocks independently, to obtain intermediate versions, to stabilize and release them for integration into a higher level product.
So, we create a system, build it from building blocks. And there is often a situation where one system comes in several versions at once. There is no need to go far for examples, take a look at the Vista delivery options. And often all the difference between different versions / versions / revisions of products - all in one or several components, or even in the settings. How to be? For this purpose, we create what will be called product lines for simplicity. A product line is a branch in the history of product development, making it possible to change a part of components independently of other similar branches. (Here the concept of "product" is used from a marketing point of view.)
Everything according to the theory of evolution - unicellular remains unicellular, but as a result of mutations and a chain of accidents (or by malicious intent) gives life to multicellular ones. There was a line of great apes - the line of homo sapience was separated from it, but the initial monkey breed continued to live its own life. The “components” of each “line” are almost 99% identical. And only a few percent (brains and one more thing on trifles) are developed by evolution independently of the parent line and distinguish one species from another.
Scheme 1. The ratio of components, supercomponent and product.
Figure 1 figuratively shows the component composition of the product. 1-8 are components, 4 is a “super component”, which includes components 5 and 6. As part of product integration, work with it is carried out as with a regular component.
Scheme 2. The ratio of the component and products when using product lines.
Figure 2 shows how the same components can be used when working with product lines. For example, there is Product 1, consisting of several components and a super component. Based on it, products 2 and 3 are produced.
Product 2 takes all the same components, with the exception of 1 and 6 — they are excluded from work (either by ignoring the relevant directories or by turning off compilation directives). In addition, component 3 changes - it becomes 3 '(do not overlook the stroke). Also in a single supercomponent is added a new component number 9.
Product 3 also takes as its basis the code base of Product 1, but also takes changes from Product 2 - components 9 and 3 '. Also changes are the components 7 and 8, which are now called 7 'and 8', respectively (yes, also with strokes).
What is the result? As a result, we have several components that are integrated simultaneously into two or three different products. Take, for example, number 2 - it is unchanged in all three products. The conclusion suggests itself - release it once and simply “insert” wherever it is required. This is done - the component team in the face of the CM-engineer stabilizes the work and passes on to further integration to the three "grocery" teams. The CM command of component 3 'arrives in the same way - after making changes over the “ancestor” 3, the resulting release of component 3' is given to two products.
Moreover, the use of one component in different products is not copying source codes from directories of one product to another. No, the point is precisely in the fact that the released configuration of the component is in the version control system and all those interested simply contact it as it is included in its code.
And what about SM?
In the technical plane, CM is the link between the components and the rulers. In the management plane, where architectural decisions are made, they are managed by managers, team leads, architects, and all technical support for this division is imposed on CM-engineers. They give the final developers instructions (“policies”) on which control systems to add their code, how to add it there, how to register changes in bug tracking systems, what is the order of component merging, what kind to give to testers and how to release a product to the customer. The products themselves are becoming new configuration items .
The main conclusion: CM helps to determine from which bricks we will fold the product and gives a cement mortar for their bonding. What methods defines and fastens - we will consider further.
So, we determined the working products, components, rulers - it's time to get down to business. The development cycle begins. Work is underway, work products appear, change, new components are created, rulers are separated - life is in full swing. As always, at a certain point you want to stop, look back and understand - at what point is the product, what has been done, what are the plans. In order 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 - for example, you can see the progress of work, get a cut of metrics, etc. - continue to make some decision regarding the distribution of tasks.
From the point of view of CM, this means that it is necessary to stabilize the configuration of the working products. For example, having a team of 20 people, you need to take all the pieces of functionality developed by different people - documents, code and other results - and bring them together.
Configuration stabilization is the process of obtaining a new configuration from existing intermediate configurations. The terms “release”, “release” or “release” are also used for this process. The result of stabilization can also be called, in turn, release or release.
For example, there is a basic configuration - product version 1.0. There is an intermediate configuration - a new feature developed by the developer. There are also 2 other configurations - corrected errors from two other developers. In this case, stabilization will be the consolidation of the results of the work of all three developers and the creation of a new configuration from them, i.e. set of CI, which form the finished product.
The resulting configuration is checked for compliance with the requirements for its component work products. Requirements can be varied, as a rule, these are quantitative criteria of quality. For example, in the example with 3 developers, a similar requirement to the code is the successful completion 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 release . This term is translated into Russian as “release notes” or “additional information” - this is how the term sounds in the Microsoft glossary. A “release description” can also be used.
The release notes detail:
If the configuration meets the requirements for stable releases, then the configuration is considered stable. For example, if the percentage of regression tests passed is 98%. Optionally, a management or CM engineer, it becomes what is called a “baseline.”
Baseline is a configuration selected and fixed at any stage of the development life cycle as a basis for further work . The term can be translated as “basic configuration” , “basic level”, “basic version” or “stable base” . In the following, the term “basic configuration” will be used predominantly.
If we go back to our example about three developers, then the stabilized configuration passed the quality assessment there. The same is necessary with the release of the basic configuration. Management (team lead or SQA) looks at quality indicators, as well as other factors - for example, the results of code inspections or something else that might raise doubts. Then it decides that the release should be taken as a basis for the work of all other developers, to be the basis for development. Further, the CM engineer performs various kinds of actions (for example, sticking a label and rebuilding the product code) and the selected configuration becomes the base one. At the same time, it (at least in the form of sources) is laid out in the open for the whole team access.
It is possible that the configuration does not meet the criteria of quality and generally can not be used to assemble the final product. For example, the product has just begun to be developed and only the code of individual components is ready, and for those, there is a stub instead of working functions. It is necessary to make the configuration the basis of work for the whole team, but at the same time to avoid the release procedure - simply because so far you can not put anything together. Such a configuration also has the right to be used as a baseline, the main thing is to clearly indicate the existing restrictions on the use of release notes.
Any release of the base configuration is necessarily provided with release notes. A team member taking a similar configuration to work must know what exactly he will build on in work. You also need to know if the new configuration contains new functions or bug fixes on which its operation may depend. It would not be out of place to also know if any special procedures are required to upgrade its copy of the system before using the new development base. All of the information listed is given in the release notes.
In many teams, the results of the integration work (emerging releases and basic configurations) are laid out in a special place - the release area , or release area . Organizing this area and keeping it up to date is the task of CM engineers.
Scheme 3. Communication configurations, releases and basic configurations.
Figure 3 shows a small example of how configurations appear over time. The initial state of the project is configuration 1. It is also the first basis from which further development will proceed. Suppose the project is at an early stage. After some time, the updated configuration 2 appears. Development has just begun and we have released a release to give the team at least some basis for further work. During the inspection, it turned out that this issue cannot serve as a base for work - there are incomprehensible and contradictory points.
To eliminate them, development teams make improvements. As a result, configurations 3 and 4 appear - both are based on 2, but they are not consistent with each other yet, because they do not include changes from each other. CM-engineer creates a final configuration 5, made on the basis of 2, 3 and 4. After checking the management gives the go-ahead - the basic configuration to be! On this signal, the CM team releases this release as the official base configuration and the developers already take it as a basis.
Then the history repeats itself - the development team makes changes - configuration 5 appears. It, in turn, is integrated by the CM engineer and it receives number 7. It also becomes the official development base.
A similar approach is used in component development. Work is underway within each component, changes constantly appear in the work products and their configuration elements, they must be periodically, or at the request of management, stabilized. Each component does it in the general case independently and with the schedule that is required for it. Therefore, for example, for one team, stabilization and release of release is done 5 times a week, for another - 1 time in 2 weeks.
Since the components are integrated into a single whole, there must be separate procedures and resources for such system integration. In this case, the work of the integration team of the superior component or the entire system differs only slightly from the work of the component integrators. Only the scale differs, and also, perhaps, the tools and criteria for assessing the maturity of the resulting releases.
In particular, after the integration of the entire system, you need not just to undergo regression testing of each incoming component. It is also necessary to run system tests that check the interaction of different parts of the system with each other - as a rule, this is not included in the field of testing of each individual subsystem. In addition, additional product metrics may be required from the CM team for the entire product. All this requires large resources and some refinement of the policies of the CM-team of the parent component.
How do CM policies change when we have more than one product, but a whole lot of them, i.e. product line? Everything becomes much more interesting. Of course, the work inside the component commands continues the same way as in other cases. Their interaction with each other changes.
First, the component team 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 change from product to product. Dependency tracking is a separate large topic, so for now let's not touch it.
Secondly, the order of integration of each component in the final products changes. Now each basic configuration should be given for integration only into 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 another and cause breakdowns.
Third, the developer must constantly think about how his changes will work on different products. After all, completely different sets of functionality can be involved in them - therefore, appropriate checks should be made in the code.
From here follow two possible lines of behavior for component commands:
1. The release of so many lines of components, how many products are currently in operation and maintenance. Overhead option in terms of tracking changes and configurations, as well as difficult in terms of the integration of the same changes in different component lines.
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 settings during system “tweaking” or during its installation and commissioning. There are also overheads for developers who, waiting for each change made, have to consider how this change will affect the operation of each of the features affected by the modified code.
This also follows the behavior of the CM command. It is necessary to take into account how the work in teams goes and to 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 life examples. For now, just take for granted the following circumstance - products and components have the properties of branching and politics, and the design documentation on CM should take this into account.
So, of all the tasks of CM, mentioned in the first note, were considered in detail:
Many things were considered declaratively - they say, this is how we should do. A little later, in other notes, I will talk about the practical meaning of the terms introduced, which could seem purely theoretical.
For self-reference, I still recommend links from the last note, plus this wiki article:
The following notes will focus on more practical things - version control and tracking change requests.
To be continued.
Below we will discuss the following things:
- Work products and configurations;
- Component development;
- Product line;
- Stabilization of work results;
- Baselines AKA basic configurations;
- Configurations in component development;
- Configurations in the presence of product lines.
Work products and configurations
What will be the working products within the project? It is clear that for marketing and management the product will be exactly one - the one for which the company will receive money. Well, or several, according to the number of types of boxes issued to the market. We are also interested in the “lower level” - what the task designers, developers, testers, and in general each project participant will operate with. The task of the CM is to determine the set of those elements that will be created and changed by the team. At this stage, the concept of a “configuration item” appears. This is an atomic element that is most convenient to manage within the framework of development. In the following, we will simply call it “CI” .
')
This includes such objects as:
- work documents;
- source files;
- resource files;
- files created as a result of the assembly (executable files, dll'ki);
- tools used for development (we must also consider them to standardize and simplify teamwork);
It turns out that CI is any file within the project? No, we are only interested in those files that are necessary and sufficient to create the final product for the customer. Therefore, we will not need utility and intermediate files generated by compilers, interpreters and IDEs. We are also unlikely to be interested in entries in blogs and forums, project correspondence and other communication products. Of course, the CM project document will describe the means of communication within the team - but no more than that.
Objects falling under the action of CM include any objects supplied outside (installers, marketing materials, etc.). Although they can be obtained from the above work products, but the final product, issued to the user, also needs identification.
Component development and product lines
How are these configuration elements, atomic units of account, organized within the project?
They are added together according to the architecture of the application itself. After all, developers tend to reduce the complexity of the systems produced. To this end, they decompose what is created into interrelated parts - classes, components, libraries, subsystems, etc. Simplify the terminology and in the future any component parts of the created systems will be called components . CM, on the other hand, takes this organization as a basis and structures its work products accordingly using its tools and policies.
Components are becoming new configuration items. They become independent work units, also subject to unified control. In addition, they can even install their own development process. In this case, CM practices are necessary in order to control these separate blocks independently, to obtain intermediate versions, to stabilize and release them for integration into a higher level product.
So, we create a system, build it from building blocks. And there is often a situation where one system comes in several versions at once. There is no need to go far for examples, take a look at the Vista delivery options. And often all the difference between different versions / versions / revisions of products - all in one or several components, or even in the settings. How to be? For this purpose, we create what will be called product lines for simplicity. A product line is a branch in the history of product development, making it possible to change a part of components independently of other similar branches. (Here the concept of "product" is used from a marketing point of view.)
Everything according to the theory of evolution - unicellular remains unicellular, but as a result of mutations and a chain of accidents (or by malicious intent) gives life to multicellular ones. There was a line of great apes - the line of homo sapience was separated from it, but the initial monkey breed continued to live its own life. The “components” of each “line” are almost 99% identical. And only a few percent (brains and one more thing on trifles) are developed by evolution independently of the parent line and distinguish one species from another.
Scheme 1. The ratio of components, supercomponent and product.
Figure 1 figuratively shows the component composition of the product. 1-8 are components, 4 is a “super component”, which includes components 5 and 6. As part of product integration, work with it is carried out as with a regular component.
Scheme 2. The ratio of the component and products when using product lines.
Figure 2 shows how the same components can be used when working with product lines. For example, there is Product 1, consisting of several components and a super component. Based on it, products 2 and 3 are produced.
Product 2 takes all the same components, with the exception of 1 and 6 — they are excluded from work (either by ignoring the relevant directories or by turning off compilation directives). In addition, component 3 changes - it becomes 3 '(do not overlook the stroke). Also in a single supercomponent is added a new component number 9.
Product 3 also takes as its basis the code base of Product 1, but also takes changes from Product 2 - components 9 and 3 '. Also changes are the components 7 and 8, which are now called 7 'and 8', respectively (yes, also with strokes).
What is the result? As a result, we have several components that are integrated simultaneously into two or three different products. Take, for example, number 2 - it is unchanged in all three products. The conclusion suggests itself - release it once and simply “insert” wherever it is required. This is done - the component team in the face of the CM-engineer stabilizes the work and passes on to further integration to the three "grocery" teams. The CM command of component 3 'arrives in the same way - after making changes over the “ancestor” 3, the resulting release of component 3' is given to two products.
Moreover, the use of one component in different products is not copying source codes from directories of one product to another. No, the point is precisely in the fact that the released configuration of the component is in the version control system and all those interested simply contact it as it is included in its code.
And what about SM?
In the technical plane, CM is the link between the components and the rulers. In the management plane, where architectural decisions are made, they are managed by managers, team leads, architects, and all technical support for this division is imposed on CM-engineers. They give the final developers instructions (“policies”) on which control systems to add their code, how to add it there, how to register changes in bug tracking systems, what is the order of component merging, what kind to give to testers and how to release a product to the customer. The products themselves are becoming new configuration items .
The main conclusion: CM helps to determine from which bricks we will fold the product and gives a cement mortar for their bonding. What methods defines and fastens - we will consider further.
Stabilization of work results
So, we determined the working products, components, rulers - it's time to get down to business. The development cycle begins. Work is underway, work products appear, change, new components are created, rulers are separated - life is in full swing. As always, at a certain point you want to stop, look back and understand - at what point is the product, what has been done, what are the plans. In order 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 - for example, you can see the progress of work, get a cut of metrics, etc. - continue to make some decision regarding the distribution of tasks.
From the point of view of CM, this means that it is necessary to stabilize the configuration of the working products. For example, having a team of 20 people, you need to take all the pieces of functionality developed by different people - documents, code and other results - and bring them together.
Configuration stabilization is the process of obtaining a new configuration from existing intermediate configurations. The terms “release”, “release” or “release” are also used for this process. The result of stabilization can also be called, in turn, release or release.
For example, there is a basic configuration - product version 1.0. There is an intermediate configuration - a new feature developed by the developer. There are also 2 other configurations - corrected errors from two other developers. In this case, stabilization will be the consolidation of the results of the work of all three developers and the creation of a new configuration from them, i.e. set of CI, which form the finished product.
The resulting configuration is checked for compliance with the requirements for its component work products. Requirements can be varied, as a rule, these are quantitative criteria of quality. For example, in the example with 3 developers, a similar requirement to the code is the successful completion 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 release . This term is translated into Russian as “release notes” or “additional information” - this is how the term sounds in the Microsoft glossary. A “release description” can also be used.
The release notes detail:
- the name of the new release;
- the basis on which it is based (see “the basic configuration”);
- the changes included in the release;
- description of the procedure for upgrading the working copy of the system, if necessary ,;
- Also, if necessary, a description of the procedure for self-preparation of executable files is included.
If the configuration meets the requirements for stable releases, then the configuration is considered stable. For example, if the percentage of regression tests passed is 98%. Optionally, a management or CM engineer, it becomes what is called a “baseline.”
Basic configuration
Baseline is a configuration selected and fixed at any stage of the development life cycle as a basis for further work . The term can be translated as “basic configuration” , “basic level”, “basic version” or “stable base” . In the following, the term “basic configuration” will be used predominantly.
If we go back to our example about three developers, then the stabilized configuration passed the quality assessment there. The same is necessary with the release of the basic configuration. Management (team lead or SQA) looks at quality indicators, as well as other factors - for example, the results of code inspections or something else that might raise doubts. Then it decides that the release should be taken as a basis for the work of all other developers, to be the basis for development. Further, the CM engineer performs various kinds of actions (for example, sticking a label and rebuilding the product code) and the selected configuration becomes the base one. At the same time, it (at least in the form of sources) is laid out in the open for the whole team access.
It is possible that the configuration does not meet the criteria of quality and generally can not be used to assemble the final product. For example, the product has just begun to be developed and only the code of individual components is ready, and for those, there is a stub instead of working functions. It is necessary to make the configuration the basis of work for the whole team, but at the same time to avoid the release procedure - simply because so far you can not put anything together. Such a configuration also has the right to be used as a baseline, the main thing is to clearly indicate the existing restrictions on the use of release notes.
Any release of the base configuration is necessarily provided with release notes. A team member taking a similar configuration to work must know what exactly he will build on in work. You also need to know if the new configuration contains new functions or bug fixes on which its operation may depend. It would not be out of place to also know if any special procedures are required to upgrade its copy of the system before using the new development base. All of the information listed is given in the release notes.
In many teams, the results of the integration work (emerging releases and basic configurations) are laid out in a special place - the release area , or release area . Organizing this area and keeping it up to date is the task of CM engineers.
Scheme 3. Communication configurations, releases and basic configurations.
Figure 3 shows a small example of how configurations appear over time. The initial state of the project is configuration 1. It is also the first basis from which further development will proceed. Suppose the project is at an early stage. After some time, the updated configuration 2 appears. Development has just begun and we have released a release to give the team at least some basis for further work. During the inspection, it turned out that this issue cannot serve as a base for work - there are incomprehensible and contradictory points.
To eliminate them, development teams make improvements. As a result, configurations 3 and 4 appear - both are based on 2, but they are not consistent with each other yet, because they do not include changes from each other. CM-engineer creates a final configuration 5, made on the basis of 2, 3 and 4. After checking the management gives the go-ahead - the basic configuration to be! On this signal, the CM team releases this release as the official base configuration and the developers already take it as a basis.
Then the history repeats itself - the development team makes changes - configuration 5 appears. It, in turn, is integrated by the CM engineer and it receives number 7. It also becomes the official development base.
Component Development Configurations
A similar approach is used in component development. Work is underway within each component, changes constantly appear in the work products and their configuration elements, they must be periodically, or at the request of management, stabilized. Each component does it in the general case independently and with the schedule that is required for it. Therefore, for example, for one team, stabilization and release of release is done 5 times a week, for another - 1 time in 2 weeks.
Since the components are integrated into a single whole, there must be separate procedures and resources for such system integration. In this case, the work of the integration team of the superior component or the entire system differs only slightly from the work of the component integrators. Only the scale differs, and also, perhaps, the tools and criteria for assessing the maturity of the resulting releases.
In particular, after the integration of the entire system, you need not just to undergo regression testing of each incoming component. It is also necessary to run system tests that check the interaction of different parts of the system with each other - as a rule, this is not included in the field of testing of each individual subsystem. In addition, additional product metrics may be required from the CM team for the entire product. All this requires large resources and some refinement of the policies of the CM-team of the parent component.
Product Line Configurations
How do CM policies change when we have more than one product, but a whole lot of them, i.e. product line? Everything becomes much more interesting. Of course, the work inside the component commands continues the same way as in other cases. Their interaction with each other changes.
First, the component team 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 change from product to product. Dependency tracking is a separate large topic, so for now let's not touch it.
Secondly, the order of integration of each component in the final products changes. Now each basic configuration should be given for integration only into 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 another and cause breakdowns.
Third, the developer must constantly think about how his changes will work on different products. After all, completely different sets of functionality can be involved in them - therefore, appropriate checks should be made in the code.
From here follow two possible lines of behavior for component commands:
1. The release of so many lines of components, how many products are currently in operation and maintenance. Overhead option in terms of tracking changes and configurations, as well as difficult in terms of the integration of the same changes in different component lines.
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 settings during system “tweaking” or during its installation and commissioning. There are also overheads for developers who, waiting for each change made, have to consider how this change will affect the operation of each of the features affected by the modified code.
This also follows the behavior of the CM command. It is necessary to take into account how the work in teams goes and to 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 life examples. For now, just take for granted the following circumstance - products and components have the properties of branching and politics, and the design documentation on CM should take this into account.
Instead of conclusion
So, of all the tasks of CM, mentioned in the first note, were considered in detail:
- identification of work products;
- stabilization of work results and determination of the base for further work;
Many things were considered declaratively - they say, this is how we should do. A little later, in other notes, I will talk about the practical meaning of the terms introduced, which could seem purely theoretical.
For self-reference, I still recommend links from the last note, plus this wiki article:
- Baseline (configuration management). en.wikipedia.org/wiki/Baseline_%28configuration_management%29
The following notes will focus on more practical things - version control and tracking change requests.
To be continued.
Source: https://habr.com/ru/post/67839/
All Articles