What if a feature being tested in your QA Environment is delayed for release?

Question

Our SCM is Subversion. And I don't know how to handle this scenario.

Let's say the I have these branches:

• DEVELOPMENT (trunk)
• QA
• PRODUCTION

In the trunk we have the following features (F):

• F1
• F2
• F3

F1 and F2 are ready to be tested on the QA environment so the changes corresponding to those features get merged into the QA branch. QA:

• F1
• F2

But what if managers want to release F1 because QA already finished the testings for F1 requirement but that's not the case for F2.

That would mean I would have to merge only changes corresponding to F1 into PRODUCTION branch but that will also mean that this new result won't be the same that QA people have already tested, that's because the PRODUCTION branch will only have F1 requirement. I cannot guarantee that it will work and it feels wrong that this new merged code gets into production without being tested at all.

This will lead to different problems for example: - What if there is some kind of dependency between F1 and F2 (they shouldn't be released on their own) - You will never know for sure if the new code will work because there wasn't an environment to test this new merged code.

How would you solve this?

Thank you and sorry for my English.

Answer 1

But what if managers want to release F1 because QA already finished the testings for F1 requirement but that's not the case for F2?

That's the managers' prerogative. They can decide to release just F1.

Your responsibility is to say that F1 has not been tested properly in the quality assurance environment. You gave the reasons in your question.

That would mean I would have to merge only changes corresponding to F1 into PRODUCTION branch but that will also mean that this new result won't be the same that QA people have already tested, that's because the PRODUCTION branch will only have F1 requirement. I cannot guarantee that it will work and it feels wrong that this new merged code gets into production without being tested at all.

You're correct. Again, your responsibility is to say that F1 has not been tested alone in the quality assurance environment.

Answer 2

In general, using separate branches for DEVELOPMENT, QA, and PRODUCTION will not be easy to manage, exactly because of situations like the one you are describing. Basically, since you cannot trust that the QA and PRODUCTION branches are identical, you will have to run your full testing process on the PRODUCTION branch after merging from the QA branch. So what good is it to have separate branches?

The Subversion Book has an article on Common Branching Patterns that suggests using feature branches (which QA can test directly), and merging into the trunk when ready for release; another option it suggests is having a trunk, which is branched off into release branches where bugs can be fixed before or after a release.

One thing you can do to gain better control of what features are ready for release is to use feature flags - this allows QA to test F1 and F2 in parallel, and release whichever one is ready.

Answer 3

You can recommend having a quick build cycle on the QA branch. Roll-back the unwanted changes (either merge back to an earlier version on QA branch, or take a fresh branch for QA and merge only F1 changes into new QA branch) - basically recommend a quick build-and-sanity-test cycle before the code is released into production. Highlight the risks of releasing untested code into LIVE scenario.

In the long run, it may pay off to set up a CI to help with continuous integration and testing - this would help atleast get the code on a given branch - tested for an entire suite of tests for any combination of features that you choose to check into the branch.

Goodluck.