This link has been bookmarked by 135 people . It was first bookmarked on 09 Apr 2008, by Fyun Li.
-
02 Feb 16
-
30 Sep 15
-
20 Feb 15
-
When a story is Done, it needs a home. With my definition of Done ("releasable") that means there must be some branch in the system that you could release from in order to get that story into production. That's the Done branch.
-
- Can release at any time
- Want to release ASAP
-
"Want to release ASAP" means that we shouldn't check in a story unless we want it to go live (or at least wouldn't mind if it goes live). If story #3 above is something that I don't want to release, I've essentially killed the branch. Since the branch is no longer releasable, I've violated the branch policy.
-
Wait a sec. Releasable means integration tested. And that means we need to run integration tests. So we need to run integration tests before checking in to the trunk.
-
Wait a sec. Releasable means integration tested. And that means we need to run integration tests. So we need to run integration tests before checking in to the trunk.
So where do I check in code that I believe is done, but need to verify before checking in to the trunk? Of course, I could test it locally on my machine, and then check it directly into trunk. But that's a bit scary, I'm sure you've all run into the "hey but it works on my machine" issue.
Another issue is "OK, I'm finished coding for today, I'm going home now. Where do I check in my code? It's not tested yet, so I can't check in to the trunk. I want to check it in somewhere so that other team members can continue working on it" (agile team = collective code ownership right?)
There we go. We have stuff we'd like to check in, and there's no place we can check in without violating a branch policy. That's a valid reason to create a new branch.
Let's call this a work branch, shared by all members of the team. Some people call it a development branch.
-
Code compiles & builds, all unit tests pass.
-
- What if our team implements multiple stories in parallell?
- What if other teams are publishing to the trunk as well?
-
f we synchronize to trunk at this point, we will be including the partially complete Deposit story, which isn't releasable!
Violation of trunk policy! . -
On the whole, many teams seem to over-rate the benefits of implementing many stories concurrently. It gives a nice feeling of speed but can be an illusion since it pushes the risky and time consuming bits to the end - merging and integrating and testing.
-
That's why Scrum teams are supposed to be small (< 9 people) - so that they can collaborate closely and focus their efforts. If everyone does their own story concurrently there probably isn't much collaboration going on. Sure you can have people looking ahead, preparing the next story and doing some of the implementation. But at any given moment the bulk of the team's efforts should be focused on the top priority story.
-
This rule means, in effect, that testing story A also includes running all relevant regression tests for previously implemented stories. It is not enough that story A works if that code has broken previous stories.
-
Rule: Synchronize your code with the work branch continuously (= as often as possible)
-
Synchronize in this case means both directions. Merge down the latest from the work branch, and check in your code. The first part can be called "catching up" (= I want to find out what other people have checked in). The second part can be called "publishing" (= I want my changes to be made available to the rest of the team).
-
Once per hour or so is a good habit, basically whenever you move from one task to another and aren't in the middle of a flow. This is not just about "I want to find out ASAP when someone else writes code that conflicts with mine", it's also about "I want the other guys to find ASAP if I write code that conflicts with theirs". Just remember to not break the policy of the work branch (unit tests pass and whatnot).
This rule may sound rather obvious but bear with me. I want to make this crystal clear since we will be reusing this mindset further down when dealing with multiple teams.
-
Every day when I get to work, someone in my team is responsible for merging the latest version from trunk to our team work branch (= "catching up" with changes made to the trunk).
If my team (team A) discovers a code conflict we resolve it immediately - that's top priority! If we need help from team B (or whoever wrote the code that conflicts with ours) go fetch them and work together to sort it out. The important thing is that my team is responsible for getting the problem sorted out, and that we need to sort it out on our own work branch (not on the trunk).
-
Rule: Resolve conflicts on the branch that is least stable
-
Rule: Merge from your work branch to the trunk on a regular basis, for example whenever a story is done. Don't wait until the end of the sprint!
-
Sprint is done! All stories except Blacklist got done. But that's OK, we can still release! This is because we merged & integrated incrementally. If we wait until the end of the sprint to do this, any diverging code will be discovered at precisely the wrong moment - when we have the least time to fix it.
-
Note that we don't have to create the release 1.0 branch when we do release 1.0.0. We can wait until the defect comes up. So we don't need to create a branch until there is something that actually needs to be done on that branch.
-
An important rule is that all change flows along the lines! So no code should be merged directly from team A work to team B work, this will cause all kinds of confusion. Instead, changes in team A work should flow to the mainline and then down to team B work.
-
Whenever changes have been made to a codeline and its baseline, some kind of merge might be needed. Since code merging is a potentially error prone operation we want to do it on the softer of the two codelines. Once the merge is complete and verified, we can copy the merged code back to the firmer codeline.
-
Example: Team A notices that the mainline has been updated. They merge the changes down to their development branch and fix any conflicts. As soon as Team A development branch reaches a stable point they copy back up to the mainline. They do of course have to check that nothing else has been changed on the mainline in the meantime
-
-
04 Jan 15
-
23 Jul 14
-
29 Jun 14
-
25 Mar 14
-
11 Jul 13
-
26 Apr 13
-
25 Apr 13
-
15 Jan 13
-
Version Control for Multiple Agile Teams
-
Definition of Done = "releasable".
-
going to use the trunk as the Done branch (a good starting point). Sometimes this is called the "mainline".
-
"Want to release ASAP" means that we shouldn't check in a story unless we want it to go live (or at least wouldn't mind if it goes live).
-
We have stuff we'd like to check in, and there's no place we can check in without violating a branch policy. That's a valid reason to create a new branch.
Let's call this a work branch, shared by all members of the team. Some people call it a development branch.
-
- Code compiles & builds, all unit tests pass.
Team A work branch policy:
-
Great, so now we have two branches! One stable branch (the trunk) and one slightly less stable branch (the team branch). The team branch is red to highlight that it is less stable, i.e. the stuff on that branch passes the unit tests but it might not be integration tested and might not be stable enough for release. OK, so the now team has a place to check in work in progress!
-
-
12 Nov 12
-
20 Aug 12
-
11 Apr 12
-
21 Jan 12
-
13 Jan 12
-
Here's a convenient rule set:
-
if people don't publish to the trunk on a regular basis
-
-
24 Sep 11
-
13 Sep 11
-
Assumption: Definition of Done = "releasable".
So when a team member says that a story is Done and moves the story card into the Done column, a customer could run into the room at that moment and say "Great! Let's go live now!", and nobody in the team will say "no, but wait".
You can use whatever definition of Done you like. But remember - if the definition is anything less than "releasable" you need to consider: what is not included in Done? And who will do that other stuff? When? And what happens if something goes wrong after Done?
-
-
05 Aug 11
-
19 May 11
-
03 May 11
-
25 Mar 11
-
15 Mar 11
-
11 Feb 11
-
Code conflicts and integration problems should be discovered as soon as possible
-
Definition of Done = "releasable".
-
releasable
-
"mainline"
-
Trunk is the Done branch
-
Can release at any time
-
Want to release ASAP
-
the product owner can decide that we should make a new production release directly from the tip of the trunk
-
We could release from the trunk at any time
-
If half the team gets sick near the end of the sprint and they don't have time to finish story #5, we could still make a release
-
"Want to release ASAP" means that we shouldn't check in a story unless we want it to go live
-
nice and clean trunk, releasable at any moment
-
we need to run integration tests
-
So we need to run integration tests before checking in to the trunk
-
Releasable means integration tested
-
So where do I check in code that I believe is done, but need to verify before checking in to the trunk? Of course, I could test it locally on my machine, and then check it directly into trunk. But that's a bit scary, I'm sure you've all run into the "hey but it works on my machine" issue.
-
Distributed versioning systems would probably differ a lot in the way of working, but not the very basics. So you might not have a "trunk", and instead have your local repo, and you just send the patch to the stable repository, but the ideas still apply
-
If you stick to this rule, then merges and bug trackings will come much more easily
-
One change, one check in
-
-
05 Feb 11
-
09 Dec 10
-
16 Nov 10
-
22 Oct 10
-
19 Oct 10
-
03 Oct 10
-
26 Sep 10
-
20 Sep 10
Yeray DariasIf we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration? This paper describes an exam
-
24 Aug 10
-
10 Aug 10
-
15 Jul 10
-
14 Jun 10
-
11 Jun 10
-
04 Jun 10
-
25 May 10
-
20 May 10
-
13 May 10
-
03 Dec 09
-
06 Sep 09
-
26 Aug 09
Vladimir ShulyakWhen several agile development teams work on the same codebase, how do we minimize chaos, and ensure there's a clean, releasable version at the end of every iteration? Here Henrik Kniberg outlines the scheme used in "Scrum and XP from the Trenches". This
agile versioncontrol scrum svn development scm programming software management
-
17 Jul 09
-
12 May 09
-
01 Apr 09
-
15 Mar 09
-
24 Feb 09
-
05 Feb 09
-
23 Jan 09
-
09 Jan 09
-
29 Dec 08
-
12 Dec 08
-
08 Dec 08
If we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration? This paper describes an exam
release gestion_de_projet scm gestion_de_configuration agile sprint scrum
-
02 Dec 08
If we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration?
svn scrum agile branche release méthode organisation trunk branch version développement
-
13 Oct 08
-
01 Oct 08
-
20 Sep 08
-
15 Sep 08
-
22 Aug 08
-
05 Aug 08
koei kimIf we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, relea
vcs versioncontrol version toread version-control xp svn subversion
-
01 Jul 08
Mairon CroesFrom site: "This paper describes an example of how to handle version control in an agile environment with multiple teams - it is the scheme that we migrated to at the company described in "Scrum and XP from the Trenches"."
agile scrum programming articles guide project management carreer work development
-
02 Jun 08
-
29 May 08
-
25 May 08
-
10 May 08
-
01 May 08
-
23 Apr 08
-
22 Apr 08
-
18 Apr 08
-
17 Apr 08
-
-
16 Apr 08
-
11 Apr 08
-
09 Apr 08
-
08 Apr 08
ddpruittVersion Control for Multiple Agile Teams
agile versioncontrol scrum svn scm collaboration subversion development cm delicious
-
07 Apr 08
-
03 Apr 08
-
02 Apr 08
-
01 Apr 08
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.