Central Bank or code management version control
The development of any modern software product is not complete without the use of a version control system of program code (for example, Subversion). This post is that in some cases, for a successful product release, a version control system alone is not enough, and you need to use some tool to expand its functionality.
The developers had different experience in our Intel® Media SDK project, and, as a result, different understanding of the risks and consequences that their commits carried. The commits were not tested at all by the developers, or the amount of testing was insufficient.
Some incorrect / untimely commits (for example, oriented not to the current but to the next version of the product) led to the appearance of significant (show stopper) errors at the stage immediately preceding the release of the product. In the conditions of a limited time resource, developers experienced considerable difficulties in establishing the reasons for their appearance. Since errors could not be fixed immediately, this led to a shift in the release date of the product.
All this was complicated by the fact that commits in the version control system were not always well commented on. Any attempts to change this state of affairs in our project were unsuccessful.
As a solution to the above problems, our project developed the CCB - Change Control Board tool using Apache, MySQL, PHP based on the open source Emergenices Personnel Information System (EMPRIS) (distributed under the Artistic License ).
CCB is “included” usually 2-3 weeks before the planned release of the Beta version of the product. A special script tracks the appearance of new commits in Subversion and puts them into the CCB database. The author of the commit receives an e-mail invitation with a link to the web form. After filling it in, the commit is transferred to the “SUBMITTED” state in the tool. In the tool, all commits are described quite well by the author of the commit, including information about why the commit was made, what was changed, how it was tested, what risk the commit for the product carries.
All commits are inspected by ordinary developers - peers and the project leader. The names of the reviewers are automatically assigned by the tool or can be selected by the author of the commit. The reviewer receives an email invitation, follows the link from the letter, accepts or rejects the commit. If the commit is accepted, it is placed in the “ACCEPTED” state.
Only the promoter (project leader) is authorized to transfer the commit to a special tag, from which, at the latest revision, the source code of the product is taken. The promoter receives an email invitation to inspect the commit. If the commit is accepted by the promoter, then it is transferred to the “PROMOTED” state, and changes to the source code of the commit are added to the tag.
Although CCB does not fix errors in the product, the tool greatly simplifies the process of localizing the commit that led to the occurrence of detected errors. Using CCB, it’s convenient to get more information about commits. The tool has a convenient search engine in order to select commits made on request:
CCB became a good example of an effective “administrative resource” when other methods to enhance the culture of code commit in a project did not work. In fact, even when the developer corrects any detected error, to complete this task it is not enough for him to simply commit his changes to Subversion, the commit must go through all the inspection steps in CCB. If the commit does not go through the entire inspection procedure in the tool, then it will not get into the product. Only the commits needed by the project leader fall into the tag.
Thus, CCB significantly increases the responsibility of authors for commits. CCB also functions as a peer code review and serves as a tool for creating logs and indicators.
CCB has been used for 4 years in our project and during this time received a lot of feedback from users and, accordingly, functionality improvements. I bring some of them from among the most remembered.
1. commit according to the CCB template (printed in a comment in Subversion). It is an alternative to entering the tool and filling in the fields in the web form.
CCB template:
2. Extraordinary commit commit. Upon promotion, a list of commit dependencies is built. A commit cannot be transferred to the tag (locked) if other commits with an early revision have not yet been inspected. When two or more dependent commits are inspected at the same time, the tool does not allow you to catch the later commit first so as not to cause a revision conflict. However, in the case when a selective promotion of commits is made, and the promoter is completely sure of the correctness of such a promotion, he can catch a later one, without waiting for earlier commits.
3. simplified inspection for individual commits. If the author for some valid reason did not provide a description of his commit to the CCB, therefore, he did not send a commit for inspection (for example, he was absent). The reminder does not help, and the commit needs to be urgently secured. That project leader can change the state of any commit.
4. several promoters with equal rights. If the project leader for some reason cannot get the commit, then other designated promoters can do it.
5. Promote in several selected tags. Two projects can use the same branch of program code and differ in some limited set of commits. For such projects, it is convenient to use different tags. Then, by default, the code will be promoted both tags at once, and for individual commits, at the choice of the promoter, only one tag.
Simplify inspecting commits for individual components. If the component is not particularly important, then to save time it would be better to transfer the commits in this component directly to the tag without inspecting them.
What tools do you use?
It was smooth on paper
The developers had different experience in our Intel® Media SDK project, and, as a result, different understanding of the risks and consequences that their commits carried. The commits were not tested at all by the developers, or the amount of testing was insufficient.
Some incorrect / untimely commits (for example, oriented not to the current but to the next version of the product) led to the appearance of significant (show stopper) errors at the stage immediately preceding the release of the product. In the conditions of a limited time resource, developers experienced considerable difficulties in establishing the reasons for their appearance. Since errors could not be fixed immediately, this led to a shift in the release date of the product.
All this was complicated by the fact that commits in the version control system were not always well commented on. Any attempts to change this state of affairs in our project were unsuccessful.
As a solution to the above problems, our project developed the CCB - Change Control Board tool using Apache, MySQL, PHP based on the open source Emergenices Personnel Information System (EMPRIS) (distributed under the Artistic License ).
How does the tool work?
CCB is “included” usually 2-3 weeks before the planned release of the Beta version of the product. A special script tracks the appearance of new commits in Subversion and puts them into the CCB database. The author of the commit receives an e-mail invitation with a link to the web form. After filling it in, the commit is transferred to the “SUBMITTED” state in the tool. In the tool, all commits are described quite well by the author of the commit, including information about why the commit was made, what was changed, how it was tested, what risk the commit for the product carries.
All commits are inspected by ordinary developers - peers and the project leader. The names of the reviewers are automatically assigned by the tool or can be selected by the author of the commit. The reviewer receives an email invitation, follows the link from the letter, accepts or rejects the commit. If the commit is accepted, it is placed in the “ACCEPTED” state.
Only the promoter (project leader) is authorized to transfer the commit to a special tag, from which, at the latest revision, the source code of the product is taken. The promoter receives an email invitation to inspect the commit. If the commit is accepted by the promoter, then it is transferred to the “PROMOTED” state, and changes to the source code of the commit are added to the tag.
The process justified the result
Although CCB does not fix errors in the product, the tool greatly simplifies the process of localizing the commit that led to the occurrence of detected errors. Using CCB, it’s convenient to get more information about commits. The tool has a convenient search engine in order to select commits made on request:
- in a certain period of time;
- in a specific component;
- specific developer;
- for a specific error;
- for a specific component;
- for a specific platform.
CCB became a good example of an effective “administrative resource” when other methods to enhance the culture of code commit in a project did not work. In fact, even when the developer corrects any detected error, to complete this task it is not enough for him to simply commit his changes to Subversion, the commit must go through all the inspection steps in CCB. If the commit does not go through the entire inspection procedure in the tool, then it will not get into the product. Only the commits needed by the project leader fall into the tag.
Thus, CCB significantly increases the responsibility of authors for commits. CCB also functions as a peer code review and serves as a tool for creating logs and indicators.
Complicating is simple, simplifying is difficult
CCB has been used for 4 years in our project and during this time received a lot of feedback from users and, accordingly, functionality improvements. I bring some of them from among the most remembered.
Added functions after receiving feedback from users (in the order they were received):
1. commit according to the CCB template (printed in a comment in Subversion). It is an alternative to entering the tool and filling in the fields in the web form.
CCB template:
summary: краткое описание коммита в том числе зачем сделан коммит [необязательное поле]
bug: номер бага [обязательное поле]
what changed: краткое описание изменений в исходнм коде [обязательное поле]
how tested: краткое описание действий по тестированию коммита [обязательное поле]
reviewer: email ревьюера [необязательное поле]
comments: другие комментарии [необязательное поле]
2. Extraordinary commit commit. Upon promotion, a list of commit dependencies is built. A commit cannot be transferred to the tag (locked) if other commits with an early revision have not yet been inspected. When two or more dependent commits are inspected at the same time, the tool does not allow you to catch the later commit first so as not to cause a revision conflict. However, in the case when a selective promotion of commits is made, and the promoter is completely sure of the correctness of such a promotion, he can catch a later one, without waiting for earlier commits.
3. simplified inspection for individual commits. If the author for some valid reason did not provide a description of his commit to the CCB, therefore, he did not send a commit for inspection (for example, he was absent). The reminder does not help, and the commit needs to be urgently secured. That project leader can change the state of any commit.
4. several promoters with equal rights. If the project leader for some reason cannot get the commit, then other designated promoters can do it.
5. Promote in several selected tags. Two projects can use the same branch of program code and differ in some limited set of commits. For such projects, it is convenient to use different tags. Then, by default, the code will be promoted both tags at once, and for individual commits, at the choice of the promoter, only one tag.
Not yet added function:
Simplify inspecting commits for individual components. If the component is not particularly important, then to save time it would be better to transfer the commits in this component directly to the tag without inspecting them.
What tools do you use?