"Yes!" In practice, it is "Hardly ever!" provided that your team is very disciplined about doing aggressive refactoring and dependency management in even the smallest possible increments of change:
- If refactoring and integration and testing are rigorously and ruthlessly performed at the fine-grained levels of minimal mergeable tasks, and minimal testable modifications, then you should be able to realize the benefits of emergent design .
- If you slack off and/or don’t have enough discipline to do it so thoroughly and frequently, you may need to make a trade-off by doing a little bit more up-front requirements and design (which FDD does, for example).
Merging and Building: Continuous "Push" Integration vs. Discrete "Pull" Assembly
In the agile world, developing a fully executing system is a holistic gestalt approach in which the whole is greater than the sum of its parts . In the traditional SCM world, many of us have grown accustomed to a more separationist assembly view in which we believe that the whole is exactly the sum of its parts!
- We like being able to separately isolate the changes for each feature, fix, and enhancement so that we can "back it out" if it breaks, or propagate (merge or reintroduce) it to one or more other projects or project variants, or to a remote geographical development site.
- We may prefer to be the ones doing the building/merging rather than having developers attempt it themselves (particularly for a remote site). This is sometimes called an Integrator-Pull model of integration (as opposed to a Developer-Push model of integration).
- We may prefer that each development task be based off the latest stable (and "blessed") development baseline instead of the off the "latest and greatest" state of the codeline (which might not be baselined).
Fortunately there are ways to accomplish the same objectives without requiring the same old methods - but some compromising and trade-offs will be necessary. Few people like having to do multi-project, multi-variant, or multi-sited development and to have to support them concurrently. If you really and truly can get away with having only 1-3 codelines, then challenge yourself to do so, and then do whatever it takes to stay that way.
If you cannot avoid multi-project, multi-variant, or multi-site development, then:
- Use the Mainline pattern and maintain a codeline for each concurrent release that must be actively supported.
- When possible, prefer an architectural solution to provide variant functionality (e.g., conditional compilation, run-time configuration, and principles and patterns of component-based, service-oriented, product-line architecture) instead of a branching solution.
- If time-zones aren’t too far apart and WAN/LAN performance isn’t an issue, have remote sites use the same central repository rather than a replicated/mirrored repository. If they are too far apart or if network performance is a problem, then use a site-specific integration branch and have it merged to (and updated from) the "master" integration branch as frequently as feasible.
- You can still use daily or nghtly (or more frequently) automated builds to verify the stability, consistency, and reproducibility of the development codeline. (This also works for site-specific codelines.)
- Use Continuous Update with Private-Branches or Task-Branches to group together multiple tasks for the same overall feature/fix so that they can still be easily propagated to other codelines while at the same time staying reasonably up-to-date. Don’t forget to propagate fixes from the older (least evolved) codelines that need them to the more recently (and more evolved) codelines.
- Use Continuous Staging to sync-up from multiple sites and/or multiple component teams.
- Use Task-level Commit and Task-based Development (TLC and TBD and appropriate pre-commit entry criteria to ensure that the tip of the codeline always corresponds