Question

I have read this article (Link: http://guides.beanstalkapp.com/version-control/branching-best-practices.html) that gives some good “best practice” advice about deploying bug-fixes and feature requests and tend to agree with all that is written there. But I have one major problem that I can’t seem to work around:

How do I deploy only the features that are fully tested, without also deploying files that are currently being tested?

Example: Bug #1 affects file1.php. The bug fix is coded in a bug branch, tested locally by the dev, and merged back into the dev branch. The dev branch is deployed to a Testing environment.

Feature #1 also affects file1.php. It is coded, merged, and deployed to Testing.

I need to deploy the bug fix (and 100 other fixes that may have similar conflicts) to Staging. I DO NOT want to deploy the new features yet, because documentation, training, etc. hasn’t been conducted.

How do I only deploy the bug fixes? How would I deploy just certain bug fixes and certain feature requests, but not all of them?

I’ve thought about tracking every file change and linking that to the bug ticket, compiling the list of files from the bug ticket, and manually choosing each of those files. But that seems like it is mistake prone and more work than should be required.

What am I missing? How do I deploy just the bug-fixes and featuresets that I want deployed?

Answer 1

An usual way, as I understand it, is:

1. You have a tag/branch (same thing in SVN) for every version deployed (say 1.1).
2. If critical bugs appear, you fix the bug in a branch of (1.1), as you said
3. The bug is merged to (1.1) creating (1.1.1) and also merged to dev. (1.1.1) goes to Testing NOT Dev.

In the meantime

1. Features go to Dev.
2. When you want to release features you create a branch for that (say 1.2) that goes to Testing and then the rest.

Note:

• Bugfixes can sometimes be done in Dev and be backported to branchs.