First of all, I'm brand new here. Secondly, I searched the forum for an answer to my question but failed to locate one. Apologies if this has been answered elsewhere, please let me know if so. Thirdly, my long & complicated question. (Sorry! CM is hard:)
At my company we are revisiting our branch/merge policy due to some production mishaps. I suspect we may be doing things sub-optimally, but would like your input.
Branch policy in a nutshell: branch from Trunk, using the newest code. I.e., start your project with the latest and greatest (untested code.)
Merge policy in a nutshell:
Part A: When fixing Production, or a downsteam branch, always forward integrate your change to all future branches. It is the responsibility of the production patcher to get their fix into all future projects.correctly. We typically have 6+++ active branches of future work.
Part B: Projects should merge and refresh from Trunk as often as possible, but strive to keep Trunk in a buildable state.
Release situation:
-When ready to release, branch and start testing. Fix bugs in the branch and merge fixes to trunk.
-Weekly Hotfixes
-Monthly Services Packs
-Quarterly Minor releases
-Biannual Major releases
Parallel Streams:
5 different teams, each doing multiple projects and each team doing many smaller tactical feature efforts
Number of developers:
40+ distributed globally; multiple sites / timezones
Tool:
Subversion (but evaluating Git; expensive tools not possible)
Project/Feature Flux:
-Projects are often delayed, rescheduled, reordered, scope is added/ejected late; sometimes in QA
-Certain release dates are etched in stone, but scope is morphable
Product/Business Model:
24x7 mission critical SaaS. This is a for-real mission critical application, not just some ecommerce website that will lose a little money if it's down. 11 years old, hundreds of thousands or millions of lines of code.
Specific Problems encountered:
-Production Fixes getting clobbered when projects go to prod; fixes must be reapplied in an emergency fashion.
-Project cancellation resulted in many ancillary features not being delivered to production because they were irrevocably entangled with the killed project. Many features had to be recoded because extracting them was difficult.
Audit situation:
-Need to show traceability from requirements to approval to migrate to code tested to code deployed. Need to show that only the code tested and approved was migrated. [Not sure how we pass audit since extraneous code is in every release; vestiges of future projects go in too]
My assumption of the "correct" solution:
-Branch new projects from Prod. Keep them separate until time to release. When ready to QA, merge, resolve conflicts, test/fix release. Now only the approved changes are going to Prod and we know we have built upon a stable tested baseline = current prod.
Development objections to my proposal:
-Deferring integration will cause merge conflicts that will be terrible to resolve. Better to smash things together early and find out sooner rather than later where merge conflicts exist and get them resolved.
My Objections to Development's objections to my proposal:
-Deferred integration merge conflict fear is overblown. Won't come up nearly as often as needing to pull changes.
-Deferred integration merge conflicts are easier to resolve than having to *unmerge* a bunch of half-baked projects. Furthermore, deferred integration merge conflicts are easier for QA to test properly, because test scripts are created for said projects. On the other hand, QA cannot test actively for unfinished projects. We rely on regression tests to find problems with unmerges, but this is less reliable, in my opinion, than actively testing two or more projects coming together.
-How do we even know what code we are releasing when everything is smashed together...seems to violate Audit controls...
Has anyone else out there fought this battle before? Would love to hear your perspectives :-)
