Code Management for a large Agile team

Many of the projects we work on involve a small number of developers and don't require us to put much thought into how to manage the source code.  We may simply set up a new repository for the solution and begin our process of initial file check-in and subsequent updates.  Often, the work is delegated in a way that each developer is working independently on separate files or even separate projects and solutions entirely.  In these simple but common scenarios, there is likely not even a need to perform a branch or a merge throughout the life of the project.  Developers may commit directly to the master/root/trunk.  In a pre-production scenario, this approach can be perfectly valid as long as developer productivity is maintained and the integrity of the code base isn't compromised.

Once the size of a project development team grows beyond a handful, the need for a more structured process becomes obvious.  The goal is to allow developers to work independently on their assigned features against a stable code base without hindering each others progress by locking files and creating complicated merge conflicts (though this is sometimes unavoidable).  Additionally, if the project is being managed using an Agile approach (of which many are these days, or at least claim to be), then the need for structure and formality to source code management becomes even greater.  In an Agile environment, your application is likely being iteratively promoted beyond development, to either a production or pre-production environment.  What this means is that it becomes imperative to be able to retrieve and build multiple versions of your code base so that a feature set (sprint) can be deployed, updated, and redeployed while development continues on future features.

The figure above depicts a branching and merging model that we used on a Scrum managed project with a large, global development team of 30+ developers committing code.  Some important highlights:

  • The Master and Development branches are permanent

  • Sprint branches are always created off Master (typically by a DevOps or Build engineer, not a developer)

  • Feature branches are created by developers and always branch as well as merge back into a Sprint branch

In the example shown in the diagram, Sprint X begins by creating a branch off Master.  Features A and B are allocated to Sprint X and are therefore branched off, committed, then merged back into Sprint X.  Immediately after these features are merged into the Sprint branch, the Sprint branch itself is then merged into Development, which triggers a build and deployment to any centralized development environment that is shared across the team.  Also in this scenario, the next Sprint (X+1) actually starts before Sprint X is deployed to the test environment.  We create a separate branch (off Master) for this Sprint X+1 so that productivity can continue on feature C (and any other features allocated to Sprint X+1) without impacting the expected feature set that will be deployed as part of Sprint X.  In fact, we see that a bug fix for Sprint X was necessary during UAT and our model allows for this to take place, again maintaining the integrity of the scope of both Sprints.  When the bug fix is completed and passed code review, it is merged into both Sprint X and Sprint X+1 so that we guarantee no functional regression when X+1 is deployed.

One final item to note is that under this model, our master branch is a representation of the code in the test environment.  A drawback that we were willing to accept is that it becomes slightly more difficult to perform a production hotfix after a test deployment has been done, because we have no true production representation in our code base.  Overcoming this could be achieved by branch labeling or creating snapshot branches as part of the deployment process.

As an Agile development team grows, the need for structured and well communicated approaches to the development lifecycle becomes vital.  This example of how to manage source code is just one example that worked for my team.  It may not be appropriate for your team or project, but I hope this information can help you tailor your own model.

86 views0 comments