I'm a contractor that has recently started with a firm.
Team is 3 developers consisting of 2 junior to mid level devs, with another at the same level starting soon, and myself (6 Years xp). For both the existing developers it is their first job out of university/college, and they've never had a senior developer overseeing their work before.
There is no explicit Version control policy. Developers do all the development on the trunk and then deploy to production direct from their development machines. The existing team are not familiar with branching.
I'm changing all this and introducing CI, TDD test/staging/production servers etc, along with a version control policy to compliment this.
Source control system is TFS, which i've never used before. It's configured as one giant repository.
I've written down a few pointers for them, but is there anything else i should be adding/ amending, bearing in mind the experience of the team?
Version Control Policy
Development is done on the trunk
If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.
Release branches created for production code. That branch should only contain stable code. We can either have one release branch that gets updated from the trunk once per sprint, or we can make a separate release branch for each week.
If a urgent bug fix affecting production code needs to be made, then it gets made on the release branch, and merged back into the trunk.
If we adopt the one release branch strategy then the trunk gets merged into the release branch once per sprint towards the end of the sprint.
If we adopt the seperate branch per release strategy, then the trunk NEVER gets merged into the Release branch
In some scenarios it may be necessary to make the bug fix twice on different branches, if branches have diverged too much. If we are doing short sprints then this shouldn’t happen too often.
I plan to have three servers. Test environment that is always running the latest code in the repo. A staging environment which is running the newest release candidate for staging/testing Release Candidate code and UAT purposes, and the production environment.
The reason why i plan to do this is that so far the client has only done internal software. The newest project is for a high profile media client, and my feeling is that the team need to adopt a more professional development model than what they do at the moment.
For example at the moment, a user may phone up the team with a bug report. The devs locate and fix the bug, do a quick test eyeball test on their own machines and then deploy straight into production. No automated testing or anything.
In hindsight i think the feature branch is a step too far and i'll remove that.
So essentially it comes down to a) no branching at all) b) a release branch and the trunk, and c) a release branch per release and the trunk.
I was leaning towards the latter. My initial thought would be that i would have both a release candidate and a release to be live on separate servers(UAT/Production) at the same time, but effectively the trunk is the release candidate at any point in time, so a branch per release is leaning towards insane. My only thought would be if we didn't want our stakeholders to see development code then we might need a separate release candidate branch, but YAGNI and all that.....