PCB or version control software
The development of any modern software product is not complete without the use of a version-control software code (for example, Subversion). This post is that in some cases, for the successful release of a product, the version control system alone is not enough, and you need to use some tool to extend its functionality.
The developers had a different experience in our Intel® Media SDK project, and, as a result, a different understanding of the risks and consequences that their commits carried. The commits were not tested by developers at all, or the amount of their testing was insufficient.
Some incorrect / not-timely 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 product release. In conditions of a limited time resource, developers experienced considerable difficulties in establishing the reasons for their appearance. Since errors could not be corrected immediately, this led to a shift in the product release date.
All this was complicated by the fact that commits in the version control system were not always commented well enough. Any attempts to change this state of affairs in our project were unsuccessful.
As a solution to the above problems in our project was developed CCB - Change Control Board tool using Apache, MySQL, PHP based on open source Emergenices Personnel Information System (EMPRIS) (distributed under the Artistic License ).
CCB “turns on” 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 logs them into the CCB database. The commit author receives an e-mail invitation with a link to the web form. After it is filled, the commit is translated into the “SUBMITTED” state in the instrument. In the tool, all commits are described quite well by the author of the commit, including information on why the commit was made, what was changed, how it was tested, what risk the commit carries for the product.
All commits are inspected by common developers - reviewers (peers) and the project leader. The names of the reviewers are assigned by the tool automatically or can be selected by the author of the commit. The reviewer receives an e-mail invitation, follows the link from the letter, accepts or rejects the commit. If the commit is accepted, it is transferred to the “ACCEPTED” state.
Only the promoter (project leader) is authorized to transfer the commit to a special tag, from which, in the end, according to the latest revision, the source code of the product is taken. The promoter receives an e-mail invitation to inspect the commit. If the commit is accepted by the promoter, 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 correct errors in the product, the tool greatly simplifies the process of localizing the commit that led to the occurrence of detected errors. With CCB, it is convenient to get additional information about commits. The tool has a convenient search engine to select commits made on request:
CCB was a good example of an effective “administrative resource” when other methods to increase the “culture” of a program code commit in a project did not work. In fact, even when a developer fixes any detected error, in order to complete this task, it is not enough for him to just commit his changes to Subversion, the commit must go through all the inspection steps in CCB. If the commit does not pass the entire inspection procedure in the instrument, then it will not get into the product. Only the leader of the commit project gets into the tag.
Thus, CCB significantly increases the authors' responsibility for commits. CCB also performs the functions of peer code review and serves as a tool for creating logs and indicators.
CCB is used for 4 years in our project and during this time received a lot of feedback from users and, accordingly, improvements in functionality. I bring some of them from among the most remembered.
1. commit by CCB pattern (printed in comments in Subversion). It is an alternative to entering the tool and filling in the fields in the web form.
CCB Template:
2. extraordinary commit commits. During the promotion, a list of commit dependencies is built. A commit cannot be transferred to a tag (locked up) 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 zapromut commit, made later, first, so as not to cause a conflict of revisions. However, in the case when a selective promotion of commits is made, and the promoter is fully confident of the correctness of such promotion, he can fill up the later one without waiting for the earlier commits.
3. simplified inspections for individual commits. If the author for some valid reason did not provide a description of his commit to the CCB, therefore, did not send the commit for inspection (for example, was absent). A reminder does not help, but a commit needs to be filled urgently. That project leader can change the status of any commit.
4. Several promoters with equal rights. If the project leader for some reason cannot commit a commit, then other designated promoters can do it.
5. promoted in several selected tags. Two projects may use the same program code branch 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 at once by both tags, and for individual commits of the promoter’s choice, only one tag.
Simplify inspection of 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 a different experience in our Intel® Media SDK project, and, as a result, a different understanding of the risks and consequences that their commits carried. The commits were not tested by developers at all, or the amount of their testing was insufficient.
Some incorrect / not-timely 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 product release. In conditions of a limited time resource, developers experienced considerable difficulties in establishing the reasons for their appearance. Since errors could not be corrected immediately, this led to a shift in the product release date.
All this was complicated by the fact that commits in the version control system were not always commented well enough. Any attempts to change this state of affairs in our project were unsuccessful.
As a solution to the above problems in our project was developed CCB - Change Control Board tool using Apache, MySQL, PHP based on open source Emergenices Personnel Information System (EMPRIS) (distributed under the Artistic License ).
How does the tool work?
CCB “turns on” 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 logs them into the CCB database. The commit author receives an e-mail invitation with a link to the web form. After it is filled, the commit is translated into the “SUBMITTED” state in the instrument. In the tool, all commits are described quite well by the author of the commit, including information on why the commit was made, what was changed, how it was tested, what risk the commit carries for the product.
All commits are inspected by common developers - reviewers (peers) and the project leader. The names of the reviewers are assigned by the tool automatically or can be selected by the author of the commit. The reviewer receives an e-mail invitation, follows the link from the letter, accepts or rejects the commit. If the commit is accepted, it is transferred to the “ACCEPTED” state.
Only the promoter (project leader) is authorized to transfer the commit to a special tag, from which, in the end, according to the latest revision, the source code of the product is taken. The promoter receives an e-mail invitation to inspect the commit. If the commit is accepted by the promoter, 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 correct errors in the product, the tool greatly simplifies the process of localizing the commit that led to the occurrence of detected errors. With CCB, it is convenient to get additional information about commits. The tool has a convenient search engine to select commits made on request:
- in a certain period of time;
- in a specific component;
- a specific developer;
- for a specific error;
- for a specific component;
- for a specific platform.
CCB was a good example of an effective “administrative resource” when other methods to increase the “culture” of a program code commit in a project did not work. In fact, even when a developer fixes any detected error, in order to complete this task, it is not enough for him to just commit his changes to Subversion, the commit must go through all the inspection steps in CCB. If the commit does not pass the entire inspection procedure in the instrument, then it will not get into the product. Only the leader of the commit project gets into the tag.
Thus, CCB significantly increases the authors' responsibility for commits. CCB also performs the functions of peer code review and serves as a tool for creating logs and indicators.
Complicate is simple, difficult to simplify
CCB is used for 4 years in our project and during this time received a lot of feedback from users and, accordingly, improvements in functionality. I bring some of them from among the most remembered.
Added features after receiving feedback from users (in the order they are received):
1. commit by CCB pattern (printed in comments 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 commits. During the promotion, a list of commit dependencies is built. A commit cannot be transferred to a tag (locked up) 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 zapromut commit, made later, first, so as not to cause a conflict of revisions. However, in the case when a selective promotion of commits is made, and the promoter is fully confident of the correctness of such promotion, he can fill up the later one without waiting for the earlier commits.
3. simplified inspections for individual commits. If the author for some valid reason did not provide a description of his commit to the CCB, therefore, did not send the commit for inspection (for example, was absent). A reminder does not help, but a commit needs to be filled urgently. That project leader can change the status of any commit.
4. Several promoters with equal rights. If the project leader for some reason cannot commit a commit, then other designated promoters can do it.
5. promoted in several selected tags. Two projects may use the same program code branch 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 at once by both tags, and for individual commits of the promoter’s choice, only one tag.
Not yet added function:
Simplify inspection of 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?
Source: https://habr.com/ru/post/199034/
All Articles