Be mindful of the amount of structural changes while in the period that will require more code merge effort.This was the message I sent to the programmers on a large agile team I have been working with.
Scaling agile has a few caveats to it. This blog post is an awareness message for programmer, which I believe to be complementary to the Continuous Integration practice for large teams.
Below is the message sent to the large Agile team.
We are a large team (+120 programmers: devs and QAs)
Programmers are coding everyday; despite of release candidates and regression periods. How is it possible?
We branch (prior to a new release), then we merge back (after it has been released); all the time ( release branch strategy )…
Consider the following simplified example of a Release formed by 2 dev iterations and 1 regression iteration.
Sample Project Release and Iteration plan
Dev activity –-It1—It2—It3—It4—It5—It6—It7—It8—It9--ItN--
Regression –------------Reg 1----Reg2-----Reg3—-------------
Release sch –------------------Rel1-----Rel2—---Rel3----------
So let’s look at different moments in time:
It2:
Dev activity –-It1—It2
Regression –----------
Release sch –---------
All programmers are working in the main trunk. Any regression activity is happening in the main trunk. There is no release yet. The release candidate is the main trunk itself.
It3:
Dev activity –-It1—It2—It3
Regression –-----------Reg 1
Release sch –-----------------
The release is formed by two dev iteration and one regression iteration.
In this case, the work done for Rel1 is related to It1 , It2, and Reg1; but should not be impacted by It3 development. Therefore the need to branch out the codebase: main trunk, and R1 branch.
Humm… if there is a branch, there will be a merge later: structural changes will have to be merged back!
It4:
Dev activity –-It1—It2—It3—It4
Regression –------------Reg 1----
Release sch –-----------------Rel1
R1 has been released. The code is merged back to the main trunk. The R1 branch now should have very little activity (production support only), therefore it should not create any difficult merge.
Programmers are mainly working in the main trunk; no merge required (remember, we do Continuous Integration!). Go crazy, do the structural changes that you feel are amazing (btw, if it is not, CI will catch it).
It5:
Dev activity –-It1—It2—It3—It4—It5
Regression –------------Reg 1----Reg2
Release sch –-----------------Rel1-----
The development period for R2 is over (It 3 and It 4). The regression work should not be impacted by the development work from It5. A branch for R2 has been created. If there is a branch, the code will have to be merged later on… Please be mindful of structural changes as you will have to merge them.
Have you noticed the pattern?
In the sample presented above:
It 2, it4, It6 development is happening in the main trunk which won’t require large amount of merges later on.
It 3, it5, It7 development is happening in the main trunk, but there is lots of development happening for a release, and those will have to be merged back in the next Iteration.
So if you have a big restructure to be done; should you do it in It7 or It8? (Remember, there is no free lunch, you will have to merge it back!)
Posts
