TFS? Run for the hills! Move off as quickly as you can. It does a lot of different things but none of them as good as the available best of breed tools.
But seriously:
Once you have a decent version control system (SVN, GIT, etc.) I'd recommend setting up rules for branch management, e.g. when to create branches, for what, when to merge, who, and a lot more.
Until recently we used a single branch for new development ('trunk'). For a release we would create a branch off trunk. Final QA would be done in that branch and once completed we would release (we are on monthly releases).
We have switched to the concept of 'no junk in the trunk' to reduce the schedule risk. This concept basically contains a rule by which you'd create branches for development work separate from trunk. For example you could have a separate branch for a feature, for a small development team or similar. We use 'epics' to describe a small feature or releasable part of a feature and create a branch for each epic. At least once a day all changes from trunk are merged into the epic branch. Key is good merge support by version control or a separate tool (e.g. three way merge). QA for the epic would be done on the epic branch. Once passed the epic branch would be merged into trunk and an integration test be run. We still have branches for releases.
With the epic branches we have substantially reduced the schedule risk as we are now in a position to release out of trunk and include all epics that were successfully merged into trunk. Epics that are not complete miss the bus and will make the next release (next month).
This of course may work only in our environment. Very likely you will have factors different from ours that will influence what the best choices are for branch management.
For example if you have a team with a lot of people working remotely and not always being connected to the version control server, then you would want to use a version control system that supports a distributed model. GIT and a few others would fall into this category. TFS to the best of my knowledge requires a connection to the server to just make files writable (fixed in version 2010?).
I hope I was able to show that there is not "one size fits all". Start with your processes in particular branch management, determine the requirements and finally select the tool that is the best match for your needs. Maybe it is TFS, maybe not.
Your plan sounds great! I think you are off to a really good start.
My only advice is in regard to you Developer Workflow. I think you're dev
branch may become problematic, because developers will be merging code willy-nilly then they think its ready.
If both branchA and branchB, C, and D are merged into dev
, and it fails, you can't be certain which parts are necessarily failing. Also, if someone pushes up something with a conflict, you dont know who it was. Madness and insanity are bound to ensue.
If a feature turns out not to be ready, and code needs to be backed out of dev
, other developers will have already pulled down their additions. Those developers then will merge back into dev
, unwittingly re-introducing the broken code. Madness and insanity are bound to ensue.
You're going to need a couple steps of separation to keep untested code away from tested code.
This all depends on the skill sets of your team, and how you actually work together. What follows is my solution to problems of a quickly expanding team with differing levels of git knowledge and different levels of developers code dependability.
I always try to tell people to not simply think about developer workflow, but testing procedure, and release process. They all need to be planned as part of a singular process.
- Lead Dev or Release Mngr (whoever) creates a new
release
branch based off master
. This branch will be a container for anything going on it in the next release.
- Lead/ReleaseMngr creates
integration
branch based off release.
- Developer creates new feature branch (or topic branch, whatever you want to call it), based off the current release branch.
- Developer tests locally, is happy.
- The developers feature branch deployed somewhere and tested by QA independently of any untested code.
- QA signs off on feature - it gets merged into an
integration
branch. (ideally, IMHO, only after the feature branch has been rebased off release
, to force the conflict resolutions )
- QA tests the
integration
branch which is just the release
branch + this one feature.
- QA signs off - integration is merged into release (if not signed off, integration is blown away and recreated based on
release
). This is the reason for integration
. No one pulls form this branch, and it can be blown away as needed.
- Now the feature is in release, and can be shared with other developers making features based off
release
branch.
- Release is good, merge to master. Deploy, make a new release branch based off master.
I know it sounds like a lot, but it really will save you from the headaches and, in my experience, are inevitable with large projects with logs of people having differing levels of knowledge.
If you have a small team with a simple release process, or a team that is very experienced - all this may not be necessary - but do be aware of the inherent problem with testing multiple people's code at the same time in your dev
branch.
All that said, its my understanding the GitHub team just lets everyone merge into master directly (after a brief code review) and auto deploys ~30 times a day.
Best Answer
In an ideal world, merge conflicts never happen. There are certain scenarios where merge conflicts are more common... So my advice to you would be avoid these scenarios. And here they are.
Tightly coupled concerns
Let's say you have a front-end engineer and a back-end engineer. And you run into conflicts. This is usually because your code is not architected such that the two parts can evolve without interrupting each other, like mixing database access with templating. You get around this by introducing just enough abstraction to add distance between the two concerns.
API changes and concurrent feature development
Let's say I'm adding a small feature to my product, and it is orthogonal to the innards. It will be a point release. Meanwhile, the lead architect is refactoring the guts of the product to bring it from 1.0 to 2.0. I'm expecting 1.0 to 1.1 for the release of my feature.
Here, the architect will be touching a lot of surface area. And if you don't have another layer of abstraction between your feature and the raw API, you will run into a very messy conflict.
Sometimes in large organizations this cannot be helped.
Overly aggressive refactoring
This is actually the same as API changes. Even though there are no functional changes, there lots of textual changes, and from Git's perspective, that is the same.
Remedies