http://www.infoq.com/cn/articles/agile-version-control/
Version control between multiple agile teamsIf we have multiple Agile teams working on the same code base, how can we minimize the risk of conflicting code with each other? How do you ensure that each iteration ends with a clean, published version of the software? This article describes an example of how to work with multiple teams in an Agile environment for versioning, which is what we have adopted in the company described in Scrum and XP from the trenches.
This article is not written specifically for version control experts, and in fact such experts cannot find anything new in this article. This article is intended for those of us who want to collaborate in a simple and effective way. Anyone who is directly involved in agile software development, no matter what role he assumes, is likely to be interested in it--everyone will use branching and merging, not just the configuration Manager.
After reading this article, if you need a document, please download the full text at the end of the catalogue.
Related Vendor Content
Drip Travel iOS Client architecture Evolution Path! How clients respond to weak networks! function programming in swift and SWIFT in functional programming! AWS Webinar May 24 Online Classroom | Create an app with AWS Lambda the most advanced container technology event in the worldRelated Sponsors
GMTC Global Mobile Technology Conference June 24, 2016-25th, Beijing, click to learn more!
Directory
This article describes an example of how to work with multiple teams in an Agile environment for version control. I assume that you are familiar with the basic elements of Scrum, XP methods, and taskpad. These methods are not invented by me, they are based on the "mainline (mainline) model" or "stable trunk (Stable trunk) mode". For more information, see the References section.
I wrote this article because I've been meeting teams that need something like that. Many teams seem to like these models very much after they have understood the model. It is also the way we have adopted the company described in Scrum and XP from the trenches. It can really help us develop and distribute software in a more agile way. By describing the model in an easy-to-read way, perhaps I no longer have to explain it repeatedly before the whiteboard. : o)
Note that this is just one of many patterns, not "silver bullets". If you decide to adopt this model, you may need to make some changes to fit your own specific context.
GoalIn an agile environment in which multiple teams are composed, the version control model must achieve the following objectives:
If the diagram makes you feel confused, don't worry, read this article. If the idea is obvious to you, it doesn't hurt to read this article.
This summary is also included in the downloadable PDF file
Version control mode branch owner & PolicyHere's a simple rule to follow.
rule: Each branch (even the trunk branch) has an owner and a guideline.
We can only get a mess if we don't obey the above rules. Policy description In accordance with these rules, what content can be checked into the current branch. The owner is the person responsible for defining and checking the execution of the rule.
"Complete" conceptHow does a user story count as "done"? More specifically, when will the team be able to move a user story into the "Finish" column on the task? What does that really mean?
I will give the following assumptions.
assume: The definition of "done" = "can be published."
So when a team member says that a user story has been "done" and moves the story card into the "Done" column, the customer can immediately go to the room and say, "Great!" Let's go online now! , and no one on the team would say, "No, wait." ”
You can use any definition of "done" that you like. But remember-if the definition does not fully contain the meaning of "can be published", you should think about it: what is not included in the "complete" definition? Who will come up with these things? What time is it? What happens if there is a problem after "done"?
The Finish branchWhen a story is "done," it needs to have a place to settle down. Using my definition of "done" ("Can be published") means that a branch of the system can be published so that the functionality of the user story can be entered into the production system. This is the "done" branch.
Any branch can be a "complete" branch. I'll use the trunk as a "done" branch (this is a good start). Sometimes this becomes the "Main Line".
Backbone Policy:assume that the trunk is a "complete" branch.
"Can be released at any time", which means: at any time, the product owner can release a new version of the product based on the latest version of the trunk.
The following is an example.
The Blue line represents the trunk. Each green spherical pattern represents a code check-in activity. You can see that 5 times the content was checked in the sprint. Although we usually publish at the end of each sprint, we can release products from the trunk at any time. If half of the team members get sick at the end of the sprint, so there is no time to finish the story # # #, we can still make a release. Of course, we can also choose not to publish first, waiting for the team to complete the story in another sprint, # #.
"Want to release early" means that if we don't want a story-related feature to go online (or don't care if it's online), don't check in the story-related code. If I don't want to publish the story in # #, this branch is destroyed by me. Since this branch is no longer available for publication, I violate the branch policy.
When do I create an extra branch?rule: Do not merge different release cycles on a single branch.
The less the new branch is created, the better. The following is a rule based on experience.
Work BranchRecommendation: Create a new branch only in the following situation: when new content needs to be checked in, and no existing branch can complete this check-in without violating its own guidelines.
Well, let's say we've got a good, clean trunk, and we're in a "ready to publish" state at any moment.
Wait a minute. "Can be published" means that the integration test has been completed. This means that we have to run the integration test. This means that we want to run the integration test before checking in the code to the trunk.
Where should I check in the code that I think has been completed, but need to be validated before checking in the trunk? Of course, I can complete the test on this machine and check the code that passes the test directly into the trunk. But it's a little scary, and I'm sure everyone has met "Hey, but it's no problem running on my machine".
The other question is, "Well, I've done my coding today and I'm going home now." Where do I check in the code? It hasn't been tested yet, so it can't be checked into the trunk. I want to check it somewhere else so that other team members can work on it. "(Agile teams take collective ownership of code, right?) ）。
You see, we have what we want to check in, but there's no place to check in without violating the branch policy. This is a reasonable reason to establish a new branch.
We can call this a work branch, and all members of the team can share the branch. Some call it a development branch.
Team A's work branch policy:
Well, now we have two branches. A stable branch (trunk) and a slightly less stable branch (Team branch). The team branch is red, indicating that it is not stable, for example: This branch passed the unit test, but it may not have completed the integration test, so it is not stable enough to be published. OK, now the team has a place to check in the work in progress!
Well, what do you do if you need to synchronize different branches? Look down.
Public release from work Branch (publish) to trunkIn the end (we hope) a story can go into the "done" state. Or, more specifically, the final work branch will reach a published state. At this point we can (and should) publish this branch publicly to the trunk, such as copying all the new code on the work branch to the trunk. When you're done, the trunk is exactly the same as the work branch.
We can call this process "public release" because we have done some work and are now ready to "publicly publish" it back to the backbone for publishing. It is only a useful metaphor to say so.
The following is an example. Let's say we've achieved two stories: "Account Opening (Register)" and "Deposit (Deposit)". They are all "completed", that is, unit tests, integration tests, and in a "ready to publish" state. We've started to deal with the "withdraw" story, but it's not "done" yet. The taskpad will look like this one:
Each yellow instant sticker represents a task, that is, a job to be done to complete the story. For example, edit Class x, update build scripts, and so on. Each task usually contains a man-day job, and each story usually contains 3 to 8 man-day jobs.
The branching process will look like this:
Our first team realized the "account opening" story, checked the code into the work branch, ran the integration test, fixed some issues, checked in again, ran the test again, and passed! The "account opening" story is "done"! It is then publicly released into the trunk.
Next, "Deposit" is realized. Only one check-in will be required. The integration test passes, and we publish the code again into the trunk.
Now the team is implementing the "withdrawals" story. They have checked in two times, but the story is still unfinished.
Note that "publishing to the trunk" does not mean that we only copy the code of a story directly into the trunk, but that it means all the work is copied into the trunk for a complete synchronization.
This brings up two very interesting questions:
We are still looking at these issues one by one.
What if the team is implementing multiple stories at the same time?If the team implements a story every time, it's not a big deal to publish the code to the trunk. As long as the story-related code is implemented on the work branch and passed the test, we can copy all the relevant content from the work branch to the trunk. Get!
Just a moment. What if a team develops multiple stories at the same time? If the "account opening" story is completed, and the "deposit" is still in progress?
If we sync to the trunk at this point, we'll sync the unfinished "deposit" story, and it can't be released yet! and violates the backbone of the version control policy!
Of course, we can wait until the "deposit" story is complete.
(Waiting for ...) ）
Well, now the "deposit" story is done! That's great! Wait a minute...... Now someone has started to develop the "withdrawals" user story! That's right! The same problem has happened again!
If a test of the "deposit" story fails, it is difficult to know whether it is the result of the "deposit" story-related code, or the reason for checking in the same branch and partially completing the "withdrawal" story-related code.
Waiting doesn't help. This is actually a snowball, expecting all the stories to be done at some hypothetical point in the future (if that happens), and a large-scale release is possible.
The above is a very common problem. What should we do?
Here are some of the strategies:
The following is an appropriate rule set:
You can even get some crown jewelry for the team. : o)
Overall, many teams overestimate the effectiveness of multiple user stories at the same time. It feels like a good thing to do in terms of development speed, but it's just an illusion because it pushes the coding of risk and consumption practices to the end-including consolidation, integration, and testing.
That's why the scrum team should remain small (fewer than 9 people)-so they can work closely together and focus on what they're doing. If anyone is developing their own responsible user stories independently, there's probably not much of a collaborative situation happening. Of course, someone can plan for the future, prepare for the next story, and do some work for it. But at any time, the team's main work effort should be placed on the highest priority story.
Multiple teams are a different situation. If you want to implement multiple stories in parallel, you might as well create multiple teams. We'll see how to do it soon. First I want to discuss the topic of regression testing and branching code.
Complete work including regression testingWhen a story is "done," we move it into the "done" column and copy the relevant content from the work branch to the trunk. The trunk must remain in a published state. Here is an important hint.
rule: Anyone who touches the trunk must ensure that the entire backbone remains in a published state-including all previous functions!
In fact, this rule implies that the test of story A also includes all relevant regression tests of the story that was previously implemented. If the code is uploaded, story A doesn't have a problem, but the test of the previous story doesn't work.
Forked code (merge conflict)wait a minute. Isn't that a little unreasonable? Run all regression tests for every story you complete?
Well, first I didn't say run all the retrospective tests. I mean all the relevant regression tests. We've got a clean and ready-to-release backbone, and now we're just adding a story! This is a small incremental change. If the regression test can be automated, we can run it all. If there is a regression test that needs to be done manually, then we will have to be selective.
Finally, it comes down to the tradeoff between risk vs cost. For each manual regression test, we should evaluate the cost of running it (for example, how much work is required to complete the test), and evaluate the likelihood of discovering any significant defects and weigh the two. And, of course, adding the cost of automating the test. : o)
Assuming I'm happily writing code calling the Widget class, I don't know that team member Jim removed the Widget class from refactoring one hours ago. Now we have the < b> Fork code. Before I spend more time writing other code that calls the widget class, I want to find a similar problem as early as possible.
rule: Keep your code synchronized to the work branch continuously (as early as possible).
This synchronization is bidirectional. Get and merge the latest code from the work branch and check in your code. The first step can be called "Keep up" (the equivalent of what I want to know what other people have checked in). The second step can be called "public" (the same as what I want the update to be made available to everyone on the team).
It's a good habit to sync every hour, basically when you're on a task switch or not in a job. It's not just about "I want to know if someone else's code is in conflict with me as soon as possible," but also "I want others to know as soon as possible whether my code is in conflict with them". Remember not to violate the policy of the Work branch (through unit testing, etc.).
The rule sounds obvious, but let me reiterate. I want everyone to be clear about it, because when it comes to multiple teamwork, we'll use a similar mindset again.
Multiple teams-What if other teams publish code to the trunk at the same time?Suppose there is team A and Team B. They are all cross-functional teams and develop a flight booking system together. Team A is focused on developing the booking process, while Team B is primarily responsible for developing background-related functionality.
Assuming they're starting a sprint now, each team has two user stories to develop (usually more stories in a sprint).
Because each team has to test before releasing the code to the trunk, they have their own branch of work.
Now we are having an interesting question. Suppose I am in team A and have our own branch of work. Changes may occur in the trunk first, not in my work branch first! Why? Well, because there's another team, they publish it to the trunk every story they complete!
So at any given moment, there may be new code on the trunk that I don't know about. and the code might (hopefully not) conflict with my Code! Maybe someone in Team B will rename the Widget class, but I've called it in the code and ... Uh...... Wait a minute, didn't we just discuss the subject?
Yes, that's the same question. The solution is the same. But the range is a little bit different.
rule: Merge code from the trunk to your work branch every day.
When I start working every day, someone in my team is responsible for merging the code from the backbone into our team work branch (which is equivalent to the changes that take place in the "Keep up" trunk).
If my team (Team a) finds a code conflict, we'll fix it right away-it's the highest priority! If we need Team B's help (or the person responsible for developing the code that conflicts with us), find them, work together, and solve the problem. The important thing is that my team is responsible for solving the problem, and we're going to do it on our own branch of work, not on the trunk.
rule: Resolve conflicts on the most unstable branch.
Of course, merging code from the trunk is a waste of time if people don't often release code to the backbone. Any disagreement between team A and Team B will be invisible unless someone posts a job to the trunk. So the following rules are:
rules: Often merge code from a work branch to the trunk, for example, after each story is completed. Don't wait until the sprint is over to do the job!
Note Here is an interesting side effect:
Side effects: First check-in code is king!
If the code that the two teams are developing conflicts with each other, the next checked-in team must be responsible for resolving the conflict. This is a good side effect because it encourages the team to check in code as early as possible. : o)
Here is an example diagram of a complete sprint:
Two teams made a 6-day sprint. Team A is ready to make bookings and cancellations. Regimental B is ready to implement "Invoice" and "blacklist". Let's see what's going on.
| Number of days | Team A Perspective | Team B Perspective | Main view |
| 1 | Merge the code from the trunk. No new content. Start developing a booking to check your work into your work branch. | Merge the code from the trunk. No new content. Start developing an invoice to check your work into your work branch. | Nothing has happened today. |
| 2 | Merge the code from the trunk. No new content. Complete the "booking" implementation. Through integration testing. It's done! Copy to trunk. Start to develop "Cancel". | Same as yesterday. | "Booking" is now complete! |
| 3 | Merge the code from the trunk. No new content. "Cancel" is still being developed. | Merge the code from the trunk. Ah ha! There's been a change! Added content related to "booking". Merge Our Code in the Team B branch to resolve any conflicts that occur. Then continue developing the invoice. | Nothing has happened today. |
| 4 | Same as yesterday. | merge the code from the trunk. No new content. Complete the implementation of the invoice. Through integration tests (including "bookings"),< font color= "#008080" > copied to the trunk. Started to develop "blacklist". </td> | the "Invoice" is now complete! . |
| 5 | Merge the code from the trunk. Ah ha! There's been a change! Added "Invoice" related content. Merge Our Code in the team a branch to resolve any conflicts that occur. Then continue to develop "cancel". </small> | Merge the code from the trunk. No new content. "Blacklist" is still under development. | Nothing has happened today. |
| 6 | Merge the code from the trunk. No new content. Complete the "Cancel" implementation and copy it to the trunk . | Same as yesterday. | "Cancel" is now complete! |
Sprint's done! All the stories were finished except the blacklist. But it doesn't matter, we can still publish! Because we are doing the merge and integration work in an incremental way. If we wait until the end of the sprint, any forked code will be found at the wrong time-the least we can do to fix the problem at this point.
Publishing BranchAssume that we have completed Sprint 1 and released the 1.0.0 version of the system. Now, when we were working on Sprint 2, someone reported that a serious flaw was found in the previously released version! No! What are we going to do?
The simplest way is to fix the problem on the trunk and release the 1.1.0 version. This means that any newly implemented story in Sprint 2 will be included in the new release version. Theoretically, this is not a problem, because the trunk is a "complete" branch, and "done" is defined as "published." So the content on the trunk is something we're going to publish whenever we want.
But there are some reasons why we don't want to release a new story right away. For example:
How exactly should we do it?
Note that we do not need to create a "release 1.0" branch when we release the 1.0.0 version, but wait until the problem occurs. In this way, we don't have to create additional branches unless we really need to build a branch to let us do something about it.
Big pictureOK, now I've given you a detailed example of how to use this pattern. Let's stand back and see what the whole picture looks like.
In the mainline model, a branch is called a code line (in fact, a branch can be implemented as a code line by a person). Sometimes these are turned into streams.
The ancestor of a code line (that is, the code line's origin code) is called its baseline. The mainline is a code line without a baseline.
So in the example above, we can summarize:
The following is a more complex example:
This diagram tells us:
Each code line has a solid level relative to its baseline, which means that each code line is either stronger than its baseline, or not as strong (softer) as its baseline.
When you draw a code line, the strong code lines branch up, while the soft code lines branch down. Observation, we can summarize:
Drawing a chart using the above description is useful for showing branching history, but it can be confusing if there are many branches at the same time. The following is a clearer format that shows only the code lines that are currently present and their derivation.
I recommend that you draw your branch chart in this format, and you can hang it on the wall of the room where the team is located. It's really helpful to refer to this diagram when discussing integration issues.
All the changes should be along the path of development, this is a very important rule! So you can't merge code directly from team A's work branch to Team B's work branch, which can lead to a lot of confusion. In fact, the changes that occur in the team a work branch should flow back into the main line and then down into Team B's work branch.
Any code line that is on top of the main line can be called a release code line, meaning a code line that is more robust than the main line.
Any code line under the main line can be called a code line (or work code line) in development, meaning a code line that is softer than the main line.
Collaboration Gold Rules:
-Always accept a steady change.
-Never enforce a change that will cause instability.
So what does this mean for different types of code lines?
It is illustrated in color:
No matter when the change is applied to the code line and its baseline, some merges are necessary. Because code merging is an easy way to make mistakes, we want to do it on a slightly softer piece of two code lines. Once the merge is complete and verified, we can copy the merged code back to a more robust code line.
By drawing a strong code line higher than the soft code line, using this Convention, we can introduce a simple rule:
rule: Merge down, copy up
Example: Team A noticed that the mainline has been updated. They merge the changes down into their own development code lines, and fix any conflicts. As long as team A's development code line reaches a stable point, they can copy the code back to the mainline. Of course, they have to check that no changes have taken place on the main line.
Variants of the ModelThe version control Mode section describes an example of how to implement a mainline model.
The "Big Picture" section describes the mainline model in a more general way.
In this section, I will present some typical variants of how to implement this pattern.
The definition of "done" does not have to be "published".First determine any definition of the word "done", and then make sure that a branch can hold a story that has been "done" based on that definition. But be careful not to miss out on what's important. If the integration test is not included in the "Finish", when is the integration test?
Trunk does not have to be mainlineThis pattern requires a mainline to go on, but it doesn't have to be the backbone (although in most cases, using the trunk is a natural choice).
Teams do not necessarily have to have their own branchesOf course, you can have multiple teams sharing the same branch or even working directly on the main line. Just be sure to follow the directions of the branch.
Typically, the team wants to have its own branch to avoid the disruption of unfinished stories across multiple teams.
You don't have to create a new publishing branch every timeYou can use the same publishing branch instead of creating a new branch at the end of each sprint. That branch can be called the "latest production system" or other similar name. This is certainly a good model if only one version is always maintained in the production system.
No need to publish at the end of each sprintIt can be published after each story has been completed. Or once every three sprints have been completed. Determine your own pace.
No need to run regression tests for every storyIf regression testing or integration is really hard to do in your environment, it can be done when the sprint is nearing the end. This makes it possible to test and integrate a batch of stories. You are responsible for the risks involved. If regression testing and integration are defined as "done," this may mean that you may encounter problems at the end of the sprint, resulting in no risk of any story completion.
How does the FAQ continuous integration (CI) work in this mode?Which branch should the CI server run on? This depends on the situation, but the following narrative is a good starting point.
Assuming that the backbone's approach is "complete and can be published," The policy for each work branch is "through unit testing":
Not sure. I know perforce is okay, and I don't think subversion should be a problem, but I'm afraid I can't pack a ticket for CVS. Any new suggestions are welcome.
But remember one important thing-the cost of switching tools is much lower than the cost of not collaborating effectively! So figure out what you want to do, and then find the right tools to support it.
What about check-in that is not related to user stories?Not all code changes have to be related to a user story, in the example, I just do it for clarity. The same model is available regardless of what type of code (or documents, etc.) is checked in.
Merging code is a hassle, so I want to do as little as possible!Congratulations, you've got the fear of merging--irrational fear of merging code! Merging makes you feel trouble because you are doing too little. The more you merge, the less pain you have. : o)
I have more questions!Look at the reference resources in the back! I believe they can solve most of your problems.
View English Original: Version Control for multiple Agile Teams
Reference ResourcesIf you want to know more, I highly recommend the following resources.
"Practical Perforce"
Author Laura Wingerd. This is a one-of-a-kind chapter that covers much of the mainline model.
This is a book about perforce, but the mainline model is not limited to perforce.
Practices in software Configuration ManagementA summary of common best practices for versioning, written by Laura Wingerd and Chirstopher Seiwald, is useful.
"Branching and Merging–an Agile perspective"An interesting article written by Robert Cowham on the subject of this article.
The Flow of ChangeAlso made by Laura Wingerd, for a good summary of the mainline model. Most of the content in the "Big Picture" section is based on these slides.
Downloadable PDFThis is the PDF format for this article and is available for download.
About the authorHenrik Kniberg is a consultant at crisp company in Stockholm, specialising in Java and Agile software development. He has built several Swedish software companies and is passionate about the art of learning, lecturing and applying software development. Henrik is engaged in a variety of jobs and likes to play many different roles such as managers, developers, Scrum Masters, teachers, and coaches. Henrik is the author of the popular Infoq mini book "Scrum and XP from the trenches:how We do Scrum".
Version control between multiple agile teams
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
