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.
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.