Version management strategy

A version management strategy is a plan on how to use branches and repositories that fits your organization and team, Blueriq application, release plan and technical environment best. A carefully chosen version management strategy will enable a stable environment in which changes to the application can be made easily without interfering with each others work and without affecting any part of the application that should not be affected by the change.

Repository

How to structure the repositories is an architectural matter. Projects within a repository have their own life cycle. Hence, in theory changes in one repository should not affect changes in another repository, unless of course they are connected (e.g. library projects or a web service connection). To learn more about functional architectures and decoupling applications read A maintainable and agile architecture.

Branching

A branching strategy is a plan on how to use branches within the repositories. There is no right branching strategy, but there will be a branching strategy that fits your Blueriq development and the technical environment best. It is recommended to give it some good thought and choose a strategy together and stick to it. Evaluate the branching strategy and adjust if necessary.

A common branching strategy is: 

• Feature branching in combination with a stable trunk as base. This trunk contains a releasable version of the project in which no changes are made. This way, it is ensured that there will always be a releasable version of the project. To develop a new feature or a small change, a complete copy of the trunk is made. This copy is called a branch. To ensure that developers don’t interfere with each others work, every major change is done in a separate branch. For example, branch 1 is for developing the 2 small new features X and Y, branch 2 is for bug fixing. Policies have to be put in place to make sure that changes are made in the branch intended for that specific change. This way, developers have their own working copy of the project in which they can make their changes.

Other branching strategies are for instance:

• Release branching; a branch is created to develop in (remains a stable trunk like feature branching) or a branch is created áfter development like a kind of releasepackage (results in a unstable trunk)
• No branching at all; development is done directly in the trunk, tags can be used to indicate milestones or releases

Which (Blueriq) branching strategy fits your application depends on your team, projects, DTAP street and/or technical environment. Sometimes a combination of branching strategies might be best, e.g. feature and release branching. There are some elements that might help choosing the right strategy for your project:

• Do you need a stable trunk or branch? Hence, how important is it to be able to release a stable version at any time?
• Does the DTAP street support the branching strategy? For instance, is it easy to deploy and test a feature branch?
• Are there any other systems or applications dependent of the Blueriq project or the other way around? Is it useful to all use the same strategy?
• Is it uncertain when or if a new features will be implemented? It might be useful to use a feature branch to separate the new feature from existing features. 
• How many people/teams have to work in the same projects?

Tips & tricks

Independent of the version management strategy there are some recommendations with regard tot branching (in Blueriq):

 Keep feature branches short-lived. This will prevent conflicts when merging back to the trunk.

 Use tags to mark releases or milestones. This will make it easy to create a new branch, e.g. for creating a hotfix branch or to be able to view an old revision without the need to keep old branches.

 Choose a branching strategy and stick to it across repositories and teams. Evaluate and adjust if necessary.

 Keep the amount of active branches small to prevent conflicts and to remain overview. 

 Do not hold on to (many) old branches; rather tag your trunk consequently to be able to create a branch at a certain revision when necessary.