Tfs versioning strategy. When you use Semantic Versioning with Continuous Deployment, version numbers must be checked into source control systems by programmers. If you aren't already using Semantic Versioning, you should. It makes it much easier to figure out how to version your releases. Even if you're 'just' building.

Tfs versioning strategy

Semantic Versioning

Tfs versioning strategy. (A terrible idea in TFS or any non DVCS while at the same time incredibly trivial to implement if using a DVCS like git or mercurial). In the past I implemented the below for a previous employers maintenance team which worked with a legacy code base that could not easily be ported over to mercurial from.

Tfs versioning strategy


Starting with a new dev team on a new project and we have to define our Branching strategy for our source repository e. Microsoft Team Foundation Server We've run into a sticky discussion over whether or not to Have one Release branch from which we do production builds and then Label when something is actually released. Have a new Release branch for each new Release into production Ex.

Version 1, 2, 3, etc Option A seems pretty straight-forward but we're not sure if this will lead to problems in the long run. Option B seems like it just creates lots of one-time long-lived branches that just pile up over time.

Does anyone have any experience either way that could help us decide? Specifically, I'm looking to hear where the pain-points are for any one choice. Personally I prefer this approach. Code coverage and unit tests should identify code that isn't ready to go out the door and people should not be working on code that will not be released during the current iteration. Branching by abstraction or other mechanisms can be used to deal with long term changes and works in progress.

Generally I would recommend just trying to stick to the mainline. If your developers are having trouble with not writing WIP that can be easily yanked when it fails the cut or that is checked in early for the next release then you can start talking about tagging the code at the point where it should be code complete and branching from there if necessary to address overlooked defects and bugs that your developers unit tests failed to catch.

In the past I implemented the below for a previous employers maintenance team which worked with a legacy code base that could not easily be ported over to mercurial from svn. A lot of unnecessary work was involved to meet a business requirement of a always releasable mainline rather than just coordinating releases better but.

We have separate branches for each release we put out appr. It is very convenient when you need to pull a specific release. If you need to maintain a couple of older releases, I don't think that labelling would do. With specific release branches, you can apply hot-fixes to each branch separately or to a selection of them without worrying about any of the other releases. It also makes comparing releases that much easier when you are hunting for when a bug or a feature was introduced.

Don't worry about the number of branches or about the time they go without changes. Your versioning system is to give you control and to provide a history of your project's development. History has a tendency not to change And don't worry about your cvs not being able to cope. Perforce is not even breathing any harder. Any self-respecting cvs will cope. We don't suffer any confusion at all with regard to the number of branches we have. Our naming scheme for the release branches and our 1 issue 1 branch policy for the development or work branches may have something to do with that.

Release branches are named for the release they hold, ie: Our work branches have less intelligent names: The "sub" comes from the fact that all work branches are sub branch of the acceptance branch. The acceptance branch being the one where all issues are collected that are ready to be released.

Our 1 issue 1 work branch policy, combined with the fact that our issue tracking system has been customized with a "branch" field ensures that we always know what issue is developed in which branch.

When an issue is integrated into the acceptance branch this field is updated. This means we always know which issues are ready for release once the acceptance testing is done. Similarly we update this field when a release branch is created and this way we can always track down in which release an issue released.

Here's a bit of a case study that I had with my old work, using the B method we called it branch by purpose. Main development was made into the trunk until we reached a feature-complete state for a certain release. At that point, we would create a branch, say projectname-january and do our quality testing and bug fixes in that very branch. Once we were ready for a public release, we would tag the code in that branch, and release.

However, development on the release did not end at that tag. Inevitably, we had clients that found bugs or small issues with the release. So in that case, all we need to do is to go back to that branch, patch the code and create a new tagged version of the january branch to be released, and merge the fixes back to the trunk.

In our case, this approach was favorable because some users preferred to stay with older releases with a limited set of features, or simply because the cost of deploying on their infrastructure a whole new version rather than a hotfix caused some issues.

If you release often, then maybe it's not worth it to have branches for each of them. However, if your release cycle is fairly long like my old use case, and that deployment, backwards compatibility and clients clinging to old releases might be risks, option B will certainly save you a lot of pain, will make things a lot easier to support your clients at the minimal cost of dealing with branch clutter.

I prefer option A. Develop on the trunk and branch releases when they are stable. This significantly limits the work in integrating hot fixes applied to production release. I've worked for some number of years on a system that uses something somewhat between the two schemes you describe.

The key is that there is a multi-level numbering scheme in use. The outer level is basically the API version, and that's managed on branches with appropriate cross-merges when something needs to be fixed on multiple branches and the inner level is the exact releases done, which is managed with tags. In particular, if we know what exact version a customer has, we know exactly what source the code was built from and can make an exact duplicate so that we can see exactly what is going on. This is very important for support!

Yet the outer level of branches, the API versions that we currently release, they do evolve over time with the main trunk of development getting the majority of new features.

Also, when we do a new major release of the API, we do a new branch for supporting that from so the trunk can always be hard-core development oriented and we consider whether we should end-of-life the current oldest support branch.

Thus I recommend something that's really a mixture of both A and B ; both have good aspects, but neither is complete in itself. Use the best of both worlds. The difficulty doesn't lie in making a branch that's stupid easy , nor pushing a week's worth of work back up the tree that's usually easy too Because branching is moot if the system isn't automatically building and running tests for your branch.

We had customized TFS' default build workflow to recognize changesets' relative paths, and established a convention by which the customization could recognize a new branch as opposed to simply a new subfolder under some development root.

It was smooth, easy to branch, easy to kill a branch, and we got continuous feedback from our system for compiles and tests. I see a lot of people declaring how impossible these strategies are under TFS, and I believe it's due to a lack of familiarity with the possibilities of a XAML-based build engine. TFS isn't just source control, it's a whole solution, and should be used as such. By posting your answer, you agree to the privacy policy and terms of service.

Questions Tags Users Badges Unanswered. Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. Join them; it only takes a minute: Here's how it works: Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top.

Choosing the right branching strategy for releases. Have one Release branch from which we do production builds and then Label when something is actually released OR B. JoeGeeky 3 6 Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with managing works in progress that may; or may not; need to be disabled now or in the future in order to release or to avoid a full rollback.

Dealing with works in progress becomes an issue and adds to potential surface attack area when it comes time to release. Branch by release Pros: You can begin working on the next iteration while the current iteration finishes its round of acceptance testing. Other stuff im sure. Still need to tag branches at release points.

Ideally though I think you want that to be the exception process, not the rule. Features were developed by devs in their teams dev branch. I wrote a little terminal application that listed the user stories present in the various acceptance stages and allowed the operator to promote or demote it inbetween those acceptance stages QA runs automation and manual usability tests. If the feature is good its pushed into the release branch mainline.

If code was reverted from the QA branch and a fix is applied the terminal tool will re-apply the necessary changes to bring the feature back onto the QA branch from the CR branch so that QA may re-review the code and either promote it or demote it again.

At any point in time the release branch should be in a stable releasable state. Keith Brings 2 5. I don't see how option A can work. At my company, we have different releases for different customers. Perhaps you have the luxury of enjoying Option A because of your release model. But that's not everyone's release model, and for those of us stuck with feature creep or multiple parallel releases, we have to use Option B.

Marjan Venema 7, 3 26 So you should be okay for hot fixes on current product versions as long as you didn't forget the label. KeithBrings Thats correct, I just tested that and you can indeed branch from a label. MarjanVenema I'm not so much concerned about the load on the system as the confusion a large number of branches may cause. Have you run into these kinds of problems?


More...

104 105 106 107 108