Background
This blog is created to
use a reference when you use SVN as the source control versioning system during
development. In this blog, I have documented the best practices
on when to use trunk and when to create SVN branches during
development to streamline the branching process.
Different folders under
SVN repository
Sub version repository
will always have below three different folders under the “project root”.
A repository can have one or more “project root”.
/trunk
/branches
/tags
Build and release from
Trunk
In general
circumstances, all the day-2-day development should happen under the trunk and
the releases to Integration, QA, Staging and Production environments should
happen from trunk.
Trunk should compile and
pass all the unit test cases at any point of the time.
Developer should add the
user story #’s or defect #’s into the comments section while check-in the code.
Every story/defect fix
should have a separate commit, instead of having multiple fixes checked in
under a single commit. This will ease the process for the peer who does
the code review.
It’s the responsibility
of the developer who check-in the code to make sure the code compiles all the
time and all the automated unit test cases pass with the current code available
in the trunk.
Creating branches
Ideally, SVN branches have to be created in any
of the below three situations:
1. Hot fixes release to production
If there are any production hot fixes needs to be released, then a new branch has to be created using production build tag first.
The hot fixes have to be applied to that new branch and released to QA, Staging and Production environment.
Finally, the changes have to be merged back into trunk.
2. Projects running across multiple sprints
For the project(s) which runs in parallel and where development spans across multiple sprints, then a new branch has to be created for each project.
It’s a good practice to setup multiple isolation environments in QA to verify only the project related changes which can be deployed from that branch.
Whenever any production release(s) happen from trunk, then the changes have to be merged from trunk back into the individual project branches created.
3. Additional fix on working trunk after build is finalized
Assume, trunk changes are finalized for a release (let’s say – build with tag-44) and next sprint changes are being checked into trunk (let’s say – build with tag-45, tag-46).
Now, assume QA team identifies an issue which needs to be fixed in the current build which is finalized for the release.
In this case, we can’t have the fix checked into trunk since we don’t need the changes which are tagged with tag-45 and tag-46 to be released to production.
Hence, a new branch would be created from tag-44 and the additional fix would be applied on the branch, release to QA, Staging and Production from that branch.
Later the changes have to be merged back into trunk.
