Version Control Audit, Part I
You should regularly check the device of your version control system with
the reality of the design process and implementation. In this document we will try
Outline a brief outline of the questions that need to be answered in order to
Highlight flaws and potential problems in your system.
For the analysis, we will need a description of the structure of branches, a list of participants
process and area of ​​responsibility; description of change flows. For
visibility, you can try to draw a couple of diagrams: the graph of change flows
the branches and the tree structure of the stream, developed in time. We believe
more important (and simpler) first schedule, whereas traditionally in many
texts on version control systems use the second, not so clearly
flashing structure.
This document describes only system analysis. Ways to solve problems
identified in the analysis will be discussed separately.
')
I. List of branches
We write in a column list of branches.
At this stage it is not necessary to invent new branches, “as we would like”.
We just write a list of the existing ones, even if it is only one.
As it generally can be: examples. For trivial (or poorly organized)
projects this list consists of one item: "trunk". For a little over
controlled projects appears branch "production". Often used
branches for a large task (feature branches): “new design of the project”,
"Refactoring of the class system", "experiment B". Some control systems
versions contribute to the fact that the branches under the task can be tiny and
short-lived (task branches) - up to one or two commits. Sometimes
Developer branches are used: everyone works in his own branch and regularly
merges changes on the trunk, making sure of their quality. Sometimes used
temporary branches for QA, with its own unique process.
Long-lived branches are written as is. Temporary short-lived branches,
such as branches for a task or qa-branches, occupy one line in
plural.
Example list of branches:
trunk
production
branches for the task
Ii. Checklist on branches
For each line of the list from the previous answer, you must answer the row
questions. Answers to them need to write, and the resulting document out loud
discuss with all participants mentioned in it. This is necessary in order to
to be confident in the completeness of the document and that everyone agrees with it.
All questions to which there is no answer, either the answer is inadequate, or if there are
disagreements are flagged. Again, no corrections should be made at this stage.
- only analysis.
II.1. When, who, where and for how long does it create a branch?
Four questions: Who creates this thread? Under what conditions does he create it?
What is the initial content of the thread? What is the life of a branch?
Example 1:
Example 2:
Here, in principle, it may already be understood that some of the aspects
ill-conceived. We mark the question as problematic and move on.
II.2. Where do changes on a branch come from?
For our further discussion, let's distinguish between changesets and
commits. We will call “commits” only those changes that
are made by the developer with hands (roughly speaking, written code). “Changes” is a more general concept that also includes automatic mergers from other branches.
So, two questions: Who makes changes to the branch? What is the nature of these
changes?
The main classes of changes that need to be distinguished are:
It is necessary to list all the sources of changes to the branch, and at the end of the list
write a ritual spell "no more changes to this thread by anyone
is made. " When casting a spell, make sure that this wording is not
causes protests from all involved in the discussion.
Example 1:
This example means that even quick fixes are required to go through a trunk.
Example 2:
Example 3:
II.3. Where do the changes made to the branch go? Who does this?
Three options are possible here:
Example 1:
Example 2:
II.4. Who is responsible for the state of the branch?
Almost always, of course, these are the same people who make changes. However due to
the presence of mergers can happen so that the branch sooner or later come
commits made by other people.
It is important to make sure that the person making the change understands that
work is not a mechanical pouring on a branch of a fresh tarball, but some
intellectual work. The easiest example is open-source tracking.
project. Does it compile? Are there any known bugs in it? Generally, exactly
This question requires the maximum amount of communication.
Example 1:
Example 2:
II.5. The meaning of the branch.
Now that we have accurately studied the real structure of the branch, we can write
a brief description of its meaning. If the description is too long and complicated
perhaps the branch is overloaded and needs to be split, or rebuild the worker
process. No new information in this description should be - everything
set out in previous questions.
Example 1:
Trunk is intended for the current semi-structured development of the next
version.
Example 2:
Feature branches are designed to work on major structure modifications.
code with a large expected instability time.
Iii. Characters and performers.
To control the integrity of the compiled analysis, you must list all
the employees (or groups of employees) mentioned in it and for each briefly
transfer:
Formally, this item is redundant (all information has already been collected), but
required, for example, to ascertain whether an employee is overloaded.
Iv. An example of a document taken from a real project.
List of branches:
Trunk
Trunk was created at the start of the project by the lead developer from scratch and will be
live forever.
The developers S. and M. freely commit to the trunk; typesetters S. and N. fluently
commit to the trunk; changes from the feature-branch are automatically merged into the trunk;
no other changes are made to the trunk by anyone.
Changes from the trunk are merged into the “production” branch by one of the developers (by
KPTIP principle); changes from the trunk are merged into the feature branch by the owner of this
branches.
For the quality of the code on the trunk there is joint and several liability. Each
The developer is responsible for their commits. For commits made by designers, not
no one feels responsible. (PROBLEM!)
Trunk is intended for the current weakly formalized development of the project.
Branch "production"
Branch "production" was created in the process of implementing the project in operation
lead developer based on the current state of the trunk and will live
forever.
The developers S. and M. (depending on whose feature is removed), merge
changes from trunk to production; no more changes to production by anyone
not paid.
Changes from production using the deploy-script are made to staging, and then
on the battle server and become available to the general public. Delivers one of two
developers (depending on whose feature is imposed).
For the quality of the code on the "production" there is joint and several liability.
The upstream developer is responsible for the quality of the rendered functionality.
(his). According to the survey, for commits from the web designers who have chosen to
production, nobody feels responsible. (PROBLEM!)
Production is intended for posting stabilized changes.
Feature branches
Feature branches are created during major site revisions (with an expected time
instability more than two or three days). The branches are created by the developer who
entrusted with the task. Branches are created based on the current version of trunk. Branches
will live while working on the task and some time after the first
reintegration (with repeated reintegration).
The branch owner commits freely to the feature-branch; branch master can update
state of feature-branch, uploading to it changes occurring in the trunk;
no one else changes the feature branch.
The quality of the code on the feature branch is answered by its owner.
Feature branches are intended for temporary storage of unstable sets.
changes.
Conclusion
This scheme shows several problems with the development process.
Generally speaking, jointly and severally liable for bringing changes to production.
has limited use and quickly becomes inadequate with growth
site reliability requirements.
In addition, the problem of commits from
layout makers regularly get out of control regularly until production is unacceptable and
must be resolved.
We will devote our next article to methods of solving this and other problems.
PS: we have a number of vacancies: http://undev.ru/ .
the reality of the design process and implementation. In this document we will try
Outline a brief outline of the questions that need to be answered in order to
Highlight flaws and potential problems in your system.
For the analysis, we will need a description of the structure of branches, a list of participants
process and area of ​​responsibility; description of change flows. For
visibility, you can try to draw a couple of diagrams: the graph of change flows
the branches and the tree structure of the stream, developed in time. We believe
more important (and simpler) first schedule, whereas traditionally in many
texts on version control systems use the second, not so clearly
flashing structure.
This document describes only system analysis. Ways to solve problems
identified in the analysis will be discussed separately.
')
I. List of branches
We write in a column list of branches.
At this stage it is not necessary to invent new branches, “as we would like”.
We just write a list of the existing ones, even if it is only one.
As it generally can be: examples. For trivial (or poorly organized)
projects this list consists of one item: "trunk". For a little over
controlled projects appears branch "production". Often used
branches for a large task (feature branches): “new design of the project”,
"Refactoring of the class system", "experiment B". Some control systems
versions contribute to the fact that the branches under the task can be tiny and
short-lived (task branches) - up to one or two commits. Sometimes
Developer branches are used: everyone works in his own branch and regularly
merges changes on the trunk, making sure of their quality. Sometimes used
temporary branches for QA, with its own unique process.
Long-lived branches are written as is. Temporary short-lived branches,
such as branches for a task or qa-branches, occupy one line in
plural.
Example list of branches:
trunk
production
branches for the task
Ii. Checklist on branches
For each line of the list from the previous answer, you must answer the row
questions. Answers to them need to write, and the resulting document out loud
discuss with all participants mentioned in it. This is necessary in order to
to be confident in the completeness of the document and that everyone agrees with it.
All questions to which there is no answer, either the answer is inadequate, or if there are
disagreements are flagged. Again, no corrections should be made at this stage.
- only analysis.
II.1. When, who, where and for how long does it create a branch?
Four questions: Who creates this thread? Under what conditions does he create it?
What is the initial content of the thread? What is the life of a branch?
Example 1:
- The “production” branch is created at the moment when it is generally accepted that the project
ready for implementation and development is stabilizing; - the branch is created by the leading developer;
- The branch is created based on the current state of the trunk;
- branch lives "forever."
Example 2:
- a branch for a task is created when it appears relatively large and complex
a task that is impractical to develop directly in
trunk; - the branch is created by the developer who is assigned the task;
- The branch is created based on the current state of the trunk;
- the branch lives until the task is generally done (after reintegration into
trunk revision of the task occur directly in the trunk).
Here, in principle, it may already be understood that some of the aspects
ill-conceived. We mark the question as problematic and move on.
II.2. Where do changes on a branch come from?
For our further discussion, let's distinguish between changesets and
commits. We will call “commits” only those changes that
are made by the developer with hands (roughly speaking, written code). “Changes” is a more general concept that also includes automatic mergers from other branches.
So, two questions: Who makes changes to the branch? What is the nature of these
changes?
The main classes of changes that need to be distinguished are:
- commits (code written by the developer);
- automatic merging of other branches (specify which ones);
- manual merging of individual commits from other branches (from which?) (usually
occurs when the old versions of bugfixes on maintenance-branches); - update external code versions (how often?) (found on vendor
branches, tracking branches).
It is necessary to list all the sources of changes to the branch, and at the end of the list
write a ritual spell "no more changes to this thread by anyone
is made. " When casting a spell, make sure that this wording is not
causes protests from all involved in the discussion.
Example 1:
- developer Vasya, in charge of production, automatically merges into
branch of production changes from trunk; - No other changes are made to the production branch.
This example means that even quick fixes are required to go through a trunk.
Example 2:
- developer Petya, when a new version of nginx is released, floods into the vendor branch
"Nginx-orig" is its source; - No other changes are made to the “nginx-orig” branch.
Example 3:
- all project developers freely commit to the trunk;
- developers involved in large tasks automatically merge
changes from feature branches to trunk; - no other changes are made to the trunk by anyone.
II.3. Where do the changes made to the branch go? Who does this?
Three options are possible here:
- "Out" (removal of the site version to the public, generation of the installer for
laid out on download.com, etc.); - merge to another branch (specify which one);
- are thrown away (for experimental branches).
Example 1:
- developer Dima regularly puts out the current
version of "production" to the public.
Example 2:
- changes in feature-branches at completion of work on a task merge
in trunk task owner.
II.4. Who is responsible for the state of the branch?
Almost always, of course, these are the same people who make changes. However due to
the presence of mergers can happen so that the branch sooner or later come
commits made by other people.
It is important to make sure that the person making the change understands that
work is not a mechanical pouring on a branch of a fresh tarball, but some
intellectual work. The easiest example is open-source tracking.
project. Does it compile? Are there any known bugs in it? Generally, exactly
This question requires the maximum amount of communication.
Example 1:
- for the quality of the code on the trunk - joint and several non-rigid responsibility.
Breaking the assembly is prohibited. Commit the code without tests or even less
passing tests - condemned. The number of bugs is desirable to reduce, and
the number of features - to increase.
Example 2:
- for the quality of the golden branch, which
10 thousand copies will be recorded on CDs and
will go to the shops, personally meets Release Avdoti Valerievich. Errors
on this thread is punished by the deprivation of the premium, and the errors leading to the release
batches of disks - transfer to a junior position. Place to sign:
_______.
II.5. The meaning of the branch.
Now that we have accurately studied the real structure of the branch, we can write
a brief description of its meaning. If the description is too long and complicated
perhaps the branch is overloaded and needs to be split, or rebuild the worker
process. No new information in this description should be - everything
set out in previous questions.
Example 1:
Trunk is intended for the current semi-structured development of the next
version.
Example 2:
Feature branches are designed to work on major structure modifications.
code with a large expected instability time.
Iii. Characters and performers.
To control the integrity of the compiled analysis, you must list all
the employees (or groups of employees) mentioned in it and for each briefly
transfer:
- what changes in which branches he has the right to make;
- for which branches he is responsible;
- from which branches it brings the code out.
Formally, this item is redundant (all information has already been collected), but
required, for example, to ascertain whether an employee is overloaded.
Iv. An example of a document taken from a real project.
List of branches:
- trunk;
- production;
- feature-branches.
Trunk
Trunk was created at the start of the project by the lead developer from scratch and will be
live forever.
The developers S. and M. freely commit to the trunk; typesetters S. and N. fluently
commit to the trunk; changes from the feature-branch are automatically merged into the trunk;
no other changes are made to the trunk by anyone.
Changes from the trunk are merged into the “production” branch by one of the developers (by
KPTIP principle); changes from the trunk are merged into the feature branch by the owner of this
branches.
For the quality of the code on the trunk there is joint and several liability. Each
The developer is responsible for their commits. For commits made by designers, not
no one feels responsible. (PROBLEM!)
Trunk is intended for the current weakly formalized development of the project.
Branch "production"
Branch "production" was created in the process of implementing the project in operation
lead developer based on the current state of the trunk and will live
forever.
The developers S. and M. (depending on whose feature is removed), merge
changes from trunk to production; no more changes to production by anyone
not paid.
Changes from production using the deploy-script are made to staging, and then
on the battle server and become available to the general public. Delivers one of two
developers (depending on whose feature is imposed).
For the quality of the code on the "production" there is joint and several liability.
The upstream developer is responsible for the quality of the rendered functionality.
(his). According to the survey, for commits from the web designers who have chosen to
production, nobody feels responsible. (PROBLEM!)
Production is intended for posting stabilized changes.
Feature branches
Feature branches are created during major site revisions (with an expected time
instability more than two or three days). The branches are created by the developer who
entrusted with the task. Branches are created based on the current version of trunk. Branches
will live while working on the task and some time after the first
reintegration (with repeated reintegration).
The branch owner commits freely to the feature-branch; branch master can update
state of feature-branch, uploading to it changes occurring in the trunk;
no one else changes the feature branch.
The quality of the code on the feature branch is answered by its owner.
Feature branches are intended for temporary storage of unstable sets.
changes.
Conclusion
This scheme shows several problems with the development process.
Generally speaking, jointly and severally liable for bringing changes to production.
has limited use and quickly becomes inadequate with growth
site reliability requirements.
In addition, the problem of commits from
layout makers regularly get out of control regularly until production is unacceptable and
must be resolved.
We will devote our next article to methods of solving this and other problems.
PS: we have a number of vacancies: http://undev.ru/ .
Source: https://habr.com/ru/post/40462/
All Articles