2

Using TFS, we have the following:

  • A main baseline
  • A development branch for each development effort. These get merged back to the baseline.
  • A release branch that is created with each release. Bug fixes are made here, released, and merged back to the baseline.
  • Using shelvesets, we can share code across development branches if needed without contaminating the baseline. Useful for code reviews.
  • When we deliver our development changes to baseline we have an automated build that kicks off and automatically places our changes on the test server.

The problem is that the business analysts can't see our changes until they're on the test server, and currently the only way to get our changes on the test server is to check them into baseline. So if the BA's find something wrong, the code is, unfortunately, already in baseline and we would have to go through the trouble of taking it back out.

Is there a way we can change our branching strategy or process to get the BA's what they want to see without contaminating our baseline?

adam0101
  • 29,096
  • 21
  • 96
  • 174

2 Answers2

4

Your branching strategy sounds exactly what we decided on at my company. I don't think the issue is with your branching strategy, I think the issue is that you have to check changes into the baseline in order to apply them to the test server.

At my company, changes aren't checked into the baseline until they are promoted and running in production. Release branches are what are deployed to the test servers... if bugs are found, or the BAs want to change something, we don't have to go through the pain of removing the changes from the baseline.

However, if you have a lot of concurrent releases, this can become a pain to merge all of the releases together before moving them to production, since you aren't merging into the baseline until later in the process. At my company, we have a very strict release schedule, and try to only have a single release working its way to production at a time. Because of this, waiting to merge the release into the baseline until the release has been promoted into production hasn't created any issues for us, or extra work so far...

How often do you do releases? Would you be able to deploy release branches onto your test servers, and have the baseline represent what is currently deployed in production?

(I'd make this a comment, but I'm still working on earning that privilege...)

Michael Fredrickson
  • 36,839
  • 5
  • 92
  • 109
  • @mfredrickson This would be a little long for the comment box, and I think it's a reasonable answer anyway. – Andrew Mar 22 '11 at 18:29
  • We use SCRUM and release at the end of each sprint which is usually about 3-4 weeks long. So you create a release branch for the next release, then create development branches off of that, then merge the development branches back to release and merge release into baseline after the release? – adam0101 Mar 22 '11 at 22:00
  • Oh, and if you can't comment yet, just edit your answer and add your follow up to the bottom. – adam0101 Mar 22 '11 at 22:07
  • @adam0101 That's how we do it... but it's a constantly evolving process for us at the moment. Right now, the ugliest part for us is starting another release before the previous release has made it to production. In that case, we either start the new release by branching off of the pending release, or by branching off of the baseline and then merging the promoted release into the new release at the same time it is merged into the baseline. For us, it depends on the size of the release... if it's a ton of changes, we branch off of the upcoming release to avoid having a huge merge later on. – Michael Fredrickson Mar 22 '11 at 22:11
  • So using this strategy, I'd have to merge and check my changes into the release branch which would kick off the automated build that puts the changes on the test server. What happens if the BA's don't approve of my changes? Now I have my changes mixed with changes that should go out in the release branch. I'm still struggling to see how others handle this. – adam0101 Mar 23 '11 at 13:26
  • The key is duplicate the baseline builds on whatever branch you do active development on to deploy somewhere that you can verify. Pull from baseline often and right before pushing back up. This will help resolve your beginning the second active dev branch. – Ryan Cromwell Mar 24 '11 at 01:17
1

I would not prefer this approach, I would suggest:

A main baseline which contains stabilized code. The code will be merged into this branch from respective release branch only after successful release.

A Release branch which gets created from Main for each release. This branch will be used to generate Release Builds and will be deployed to test environment.

A Development Branch created from Release Branch, it will be used for Development efforts and will be merged to Release when I'm ready to give my build to test.

Jehan33
  • 3,780
  • 2
  • 21
  • 16
  • If your changes don't pass on test, how do you handle that your broken changes are mixed with others' changes in the release branch? Do you roll your changes back somehow? – adam0101 Mar 23 '11 at 13:27
  • If changes dont pass on test, If fix is required for then it be fixed in development branch and merge them to Release. If we dont require those changes at all then it will be rolled back using labels or tf rollback command. – Jehan33 Mar 23 '11 at 19:40
  • If other developers committed changes to a file AFTER you and your changes had to be rolled back, wouldn't you have to somehow "unmerge" the files to take out your changes then "remerge" the other developers' changes back? How would you handle this? – adam0101 Mar 23 '11 at 21:54
  • Developer will not do any checkin, checkout in Release Branch, code promotion happens here by Dev Lead. In Development if a change has be rolled back for above scenerio, then the developer gets specific version of the files to the version he wants to rollback and does checkin. – Jehan33 Mar 24 '11 at 12:27