to perform bug fixes or patches to an existing release. Any changes in this branch should not only be merged ‘in' to the trunk (presumably for production), but they should be merged out to any new project development (via the project branch, integration branch, site branch, or private branch) so that the fix is included in the new release so regression in functionality and stability does not occur.
Below is an example of a branching and merging model which uses some of the branch types listed above.
Establishing a Branching and Merging Strategy
When considering a branching and merging strategy, you must first understand that the application branching requirements will evolve and what is adequate today, will not necessarily meet the branching needs in the future. Therefore, it is important to think about the application's short-term and long-term branching needs when defining a branching strategy. This involves considering three aspects: complexity over time, effort, and risk to stability. Once these aspects are considered, a branching and merging model may be created that can support the application.
Complexity Over Time
How complex is the application development and how complex might it become in the future? Some key components to complexity are (and not limited to):
· The number of users involved.
· The type of users that may be involved (developers, testers, build/release engineers, etc.).
· The amount of parallel development that may occur (number of releases occurring in parallel, bug fixes occurring on past releases, whether other sites are involved, and how much prototyping is occurring).
· With the complexity in mind, consider how the complexity will change over time. For example: Within the first 6 months, project release 1 may include only 5 developers, no parallel development, and only 1 site involved in development. After 1 year, project release 2 may include 15 developers with parallel development to manage release 2, bug fixes for release 1, and a prototype for release 3, and includes 2 sites involved in development.
Clearly, there will be a need for a more advanced strategy needed for the second scenario. This is why capturing complexity over time is important. The complexity will drive the branching needed and thinking ahead will ensure what is in place today can be easily extended to support the application needs tomorrow.
As parallel development is introduced, the level of branching complexity increases. As complexity increases, the amount of effort to manage change within a more complex branching environment increases. This should be an expectation that project management understands and plans. If they do not, ensure you advise them of this fact.
This is the trade-off of going to a parallel development model. While it may enable faster-time-to market, it may also increase the amount of effort and coordination in certain stages of the project and in particular adds merging and testing tasks to the project plan. Keep in mind that merging typically requires retesting to ensure that the code merged is tested appropriately, particularly where logical lines of conflict have to be reconciled.
Another aspect to considering effort is the project management strategy as it relates to the delegation of development work. If specific chunks of work are allocated to specific groups, then less merging and testing is likely to occur. However if the project manager is indiscriminate in the way the work is being doled out then a significant amount of merging may occur increasing the amount of effort and quite possibly