Branches in svn
A feature of modern web development is the complete lack of planning for creating, supporting and rolling out projects. This leads to a situation that quite often several different tasks are performed in parallel and the terms of their rollout in production do not correlate in any way. So the traditional approach with the creation of releases is not good.
We are assisted by the mechanism for creating branches in version control systems, VCS (in our case it is Subversion). Branches are different versions of a single document or project, with a general history of changes to the branch point and with different ones after it.
')
A branch is created very simply:
Now, in order for the developer’s changes to be saved not in the main trunk (development), but in the selected branch, he should switch to this branch.
Now you can develop in a branch without worrying that unapproved or untested solutions will fall into production. In this case, the developer works with his host LOGIN_RAZRABOTCHIKA.PROEKT.KLIENT.devserver.ru
To show the finished or intermediate solution, a test host is created for this branch. It is necessary to automate this process so that developers do not waste time on it. Managers and testers always check the solution only on a test host TITLE_WINCH.PROJECT.Client.devserver.ru. You can not check anything on the developer’s host. Because:
Therefore, the only correct practice would be:
The latter must be done, even if this link was encountered several times in the task. Because, because of haste or inattention, 4 of the 5 described actions can be omitted.
After the manager checked the solution and did not find any errors, you need to insert the branch into the trunk.
Suppose we have a branch A (trunk), which is the main development. In revision 100, we branch off branch B from it (branches / BRANCH NAME) (A @ 100, B @ 101) Then both branches actively develop for a long time (A @ 167, B @ 189) and we need to merge them. If you merge "in the forehead" (sw A, merge AB) then there will be a lot of conflicts that are very difficult to resolve. The correct approach is as follows:
I draw your attention: if the branches have already merged in the past, then it is necessary to take as the initial revision not the budding revision, but the last revision, in which the branches were “identical”. At what it may not necessarily be an infusion of changes from A to B, there may be an infusion of B into A.
In some cases, conflicts still happen, as a rule, if the same section of code was changed in different branches. There is an instruction for their resolution. We must not forget that it is not necessary that your decision be correct in every conflict, therefore it is desirable that a merge be made by a person who is familiar with changes in both merged branches and is able to adequately solve the conflict.
After the merge, you need to create a test host for the trunk (trunk. PROJECT. CLIENT. Devserver.ru) or update the existing folder. After that we throw into the task a link to the problem place on the test host in the task. Why do this, because we just checked the changes on the branch host? Changes that were made to the trunk or other changes that were infused into the trunk may affect the edits we need. Most often, problems can be caused by CSS, because there are just general rules affect a lot of sections, but there are other situations. Therefore, another check on the trunk before rolling out is very necessary.
Sometimes the manager is completely unaware of the project and most of all he is concerned about his own mental balance. Therefore, with a light heart, he skips steps that seem to him unimportant and writes in the task “Do this and immediately roll out.”
And therefore, he will soon get stuck from the client. “Now, most subscribers on the web cannot ... using IE browser. We said last time that more than half of the users use it, so please test all the improvements in the first place on IE. Please correct this error as soon as possible! ”
The manager sets the task “URGENT !!! ERROR !!! ”and forgets about checks until the next time.
Violation of the algorithm “done → checked → (corrected → checked) * n → rolled out” leads to the emergence of urgent tasks, edits from the developers who beat out the rhythm and distract from the planned tasks, spoils our overall reputation for customers and users and does not speed up the process.
We are assisted by the mechanism for creating branches in version control systems, VCS (in our case it is Subversion). Branches are different versions of a single document or project, with a general history of changes to the branch point and with different ones after it.
Creature
')
A branch is created very simply:
svn copy svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ -m ' ' Now, in order for the developer’s changes to be saved not in the main trunk (development), but in the selected branch, he should switch to this branch.
cd ~/web// # svn sw svn://svnserver.ru///branches/_ svn update # , svn:externals Now you can develop in a branch without worrying that unapproved or untested solutions will fall into production. In this case, the developer works with his host LOGIN_RAZRABOTCHIKA.PROEKT.KLIENT.devserver.ru
To show the finished or intermediate solution, a test host is created for this branch. It is necessary to automate this process so that developers do not waste time on it. Managers and testers always check the solution only on a test host TITLE_WINCH.PROJECT.Client.devserver.ru. You can not check anything on the developer’s host. Because:
- developers strive to forget to commit something. Because of this, another developer working with the same task or rolling out a solution may not understand for a long time where everything is.
- sometimes developers leave bindings to their host in the code. Because of this, the solution works only for them, and when rolling out, everything breaks down.
- many, especially experienced developers, are new to make some corrections "blindly" and not checking them to commit. This leads to a drop in the service on production and a series of commit-hotfixes with the comment “Oh, fuck”
Therefore, the only correct practice would be:
- to perform the task
- commit changes
- roll them out to a test server
- himself with his eyes at least once to see that everything rolled out there correctly
- publish a link to the problem location on the test host in the task (in megaplane or another tasktracker)
The latter must be done, even if this link was encountered several times in the task. Because, because of haste or inattention, 4 of the 5 described actions can be omitted.
Merger
After the manager checked the solution and did not find any errors, you need to insert the branch into the trunk.
Suppose we have a branch A (trunk), which is the main development. In revision 100, we branch off branch B from it (branches / BRANCH NAME) (A @ 100, B @ 101) Then both branches actively develop for a long time (A @ 167, B @ 189) and we need to merge them. If you merge "in the forehead" (sw A, merge AB) then there will be a lot of conflicts that are very difficult to resolve. The correct approach is as follows:
svn switch svn://svnserver.ru///branches/_ # B svn merge -r 101:167 svn://svnserver.ru///trunk . # A ( ** **) svn ci -m 'merge with -r 101:167 trunk' # ( , ) . svn switch svn://svnserver.ru///trunk # A svn merge svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ . # B svn ci -m 'merge with _@190' # , .. A I draw your attention: if the branches have already merged in the past, then it is necessary to take as the initial revision not the budding revision, but the last revision, in which the branches were “identical”. At what it may not necessarily be an infusion of changes from A to B, there may be an infusion of B into A.
In some cases, conflicts still happen, as a rule, if the same section of code was changed in different branches. There is an instruction for their resolution. We must not forget that it is not necessary that your decision be correct in every conflict, therefore it is desirable that a merge be made by a person who is familiar with changes in both merged branches and is able to adequately solve the conflict.
After the merge, you need to create a test host for the trunk (trunk. PROJECT. CLIENT. Devserver.ru) or update the existing folder. After that we throw into the task a link to the problem place on the test host in the task. Why do this, because we just checked the changes on the branch host? Changes that were made to the trunk or other changes that were infused into the trunk may affect the edits we need. Most often, problems can be caused by CSS, because there are just general rules affect a lot of sections, but there are other situations. Therefore, another check on the trunk before rolling out is very necessary.
Careless manager
Sometimes the manager is completely unaware of the project and most of all he is concerned about his own mental balance. Therefore, with a light heart, he skips steps that seem to him unimportant and writes in the task “Do this and immediately roll out.”
And therefore, he will soon get stuck from the client. “Now, most subscribers on the web cannot ... using IE browser. We said last time that more than half of the users use it, so please test all the improvements in the first place on IE. Please correct this error as soon as possible! ”
The manager sets the task “URGENT !!! ERROR !!! ”and forgets about checks until the next time.
Violation of the algorithm “done → checked → (corrected → checked) * n → rolled out” leads to the emergence of urgent tasks, edits from the developers who beat out the rhythm and distract from the planned tasks, spoils our overall reputation for customers and users and does not speed up the process.
Source: https://habr.com/ru/post/120063/
All Articles