CODEWITHSUNDEEP
gittfsversion-controlreleaserelease-management
Javee
Javee

Reputation: 71

Release branch strategy

Our application is kind of rule engine based application which uses Drools . It has core framework logic and customer specific business logic will be deployed as a rules.

Particular release would contains multiple features. For example, Feature_Branch_Toyota_1.0, Feature_Branch_Honda_1.0 etc., will be going in same release Rel_1.0 and its passing QA testing. Last minute Business did not find time to do UAT (User Acceptance Testing) for Feature_Branch_Honda_1.0 changes due to time restriction or complexity of the changes.

Now Business would like to postpone Feature_Branch_Honda_1.0 changes to Next month release but still Feature_Branch_Toyota_1.0 changes should go as its scheduled in Rel_1.0.

If we remove the Feature_Branch_Honda_1.0 changes out of Rel_1.0 then QA would ask for the regression testing which will impact the actual release plan. Is there a way to avoid that? or Is there any pattern to make each feature as an isolated component in a same release branch so that if any feature is getting postponed to next release, it would not impact other features in the current release.

Suggestions/advise would be much appreciated.

Upvotes: 0

Views: 152

Answers (1)

Scott Sosna
Scott Sosna

Reputation: 1413

Would seem QA is completely within their right to ask for regression testing.

Original: Honda 1.0 + Toyota 1.0 ==> Rel 1.0 Now: Toyota 1.0 ==> Rel 1.0

QA now needs to ensure that Toyota 1.0 has nothing that inadvertely depends on Honda 1.0, would seem possible that some tighter-than-expected coupling results on some interdependencies. So definitely need to be testing of some sort. And then after Honda 1.0 is out, Toyota 1.1 is released and they'll need to be regression testing there as well.

Managing something like this becomes a nightmare, because basically you need a matrix of supported combinations of all modules within your application, each of which requires some level of regression/QA testing. It's a bear, been there, failed there.

From a version control standpoint, I recommend separated repositories for each module, so that each can branch/tag/etc. at independent points of any other module. It's then your compatibility matrix that brings it all together.

Upvotes: 2

Related Questions