3

I have the following coding environment:

  • Three Developers
  • Source code resides in Team Foundation Server (2010)
  • Development Environment
  • Stage Environment
  • Production Environment

As the Senior Developer, I need to review code before its pushed to the Staging Environment. Once I review the code, it is pushed to Stage where it gets tested by our (small) test team. Once changes are tested and accepted, I move to production.

Suppose the following:

Developer A submits a change, I review it and push to stage. Developer B submits a change, I review it and push to stage.

During the testing, a user says the change Developer A made has bugs and needs to be fixed. But the changes Developer B made need to go to production.

This happens more than not. Currently, I need to wait for Developer A to fix the bugs and test again or have Developer A disable their changes.

How to solve this dilemma?

2
  • I think this could be more of a business-level decision by rights - they have to weigh up the costs of either going live with bugs, or delaying while the bugs are fixed, or delaying while the error feature is removed. Commented Sep 11, 2014 at 15:17
  • 5
    But then again, you could go down the route of using branches - which would allow you to test each feature in isolation. If you need to cut it out, you roll back or discard the merge with errors, and then create a new merge which doesn't include the error features. Commented Sep 11, 2014 at 15:20

1 Answer 1

6

One strategy, which can be established with any decent VCS, is to open a parallel maintenance branch in such a situation (based on the latest stable production release) and merge only the immediate bugfixes or other urgent changes for production into it (for example, the changes of your developer B). Typically, you can create a maintenance release from this branch for production much quicker, with only a low risk introducing new bugs and with less testing effort than from your current development branch.

Your "staging branch" will still contain all new features (including the changes from A and B), and you can deploy it later when it is "ready".

This model can be supported by your version numbering scheme: for example, when you release your version 1.2 into production it is actually version 1.2.0. Whenever you deliver a maintenance release, you increase the last digit: 1.2.1, 1.2.2, 1.2.3. These numbers tell anyone that your application contains no real new features within the 1.2 line, only urgent fixes. When you deliver a release with new-features, you increase the first digits: 1.3, 1.4 or 2.0.

In fact, in our team we make sometimes use of this technique for our main product, but only when we cannot easily hide the changes "of dev A" behind a "feature toggle". The latter will typically cause less branching/merging effort than a maintenance branch, so if you can avoid the changes in dev A's code influencing production by simply setting a runtime switch, then this maybe the better alternative.

1
  • feature toggle - we call it switching. We use it only for major updates that can't be easily hidden (as you mentioned). I should have mentioned it in my original post :). Great post and thank you for the in-site.
    – PhillyNJ
    Commented Sep 11, 2014 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.