In answer to the following question:
“Are you advising that we wait until the build on Main is stable and all dependent systems are ready before we attempt to deploy anything? This makes a hard-to-hit-target nearly impossible to hit (we have multiple teams, so it is already complex as it is). We might not ever get anything out the door. Our stakeholders would prefer a pared-down release on regular intervals versus a deferred release. Do you plan to address "advanced web development" in your guide?”
No, I am certainly not advising holding up deploying *anything* until *everything* is ready. That is hardly agile, and I am a strong proponent of agile. I agree with your stakeholders that often regular incremental releases are much better than deferred *big bang* releases. Many lives ago, I worked on mainframe applications in the Energy Utility (Gas and Electric) industry. My primary focus was architecting, designing, and building large-scale mainframe Customer Service Systems to support such old-fashioned concepts as Meter Reading (using humans), Cycle Billing, Estimated Billing, Cancel Re-billing, etc.
These systems, back in those days (pre de-regulation) often took years to envision, design, build, stabilize and deploy. Several problems happened with those old *waterfall* approaches, where all of the requirements needed to be gathered up front (takes six months), the architecture and design must be completed next (takes another six months), the code must be completed (takes a year) and then tested (takes forever). All sequentially in huge chunks of phases before the system could be deployed in one huge *big bang* release. These companies would undertake a new CSS development only once every fifteen years (I am not generalizing, I have seen studies of the Energy utility industry).
Often the business had evolving requirements. But because the software development life cycle was waterfall and drawn out over two or three years, the customer was unable to get their evolving requirements incorporated into the new released system. What do you tell them? Wait for the next release in fifteen years? How do you get a business to prioritize their requirements, when they KNOW that anything that is not top priority gets cut and they have to wait fifteen years for priority two requirements? But I digress.
In theory, I think I could propose a branching structure (and process) - a branching strategy that would support your requirements. It does not NEED to be exclusively for *advanced web* development, but would, I suggest support any agile development/release process that has similar characteristics:
So all of this boils down to a few key questions:
Finally the approach:
Think of the development side of the branching strategy separately from the release side:
Thoughts?