Repository
How to structure the repositories is an architectural matter. Each repository has its own life cycle. Hence, changes in one repository do not affect changes in another repository, unless of course they are connected (e.g. 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 correct 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.
Feature branching
Feature branching is combined 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; 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.
An example of feature branching in Blueriq is shown on the right. Although the screenshot is from version management in Blueriq Encore, the image shows the general concept of feature branching. Namely, there is a Trunk (in yellow). The trunk contains several revisions (the history of registers). A feature branch is created FeatureA (in red). FeatureA is a copy of the trunk at the specific revision Change A. That is, the branch FeatureA does contain Change A, but not Change B and later on Change Y. After FeatureA is finished, the Trunk is updated with the changes from FeatureA, that is New entity and New attribute in the image on the right.
Pluses and minuses of this strategy:
Features can be developed independently of each other and independent of release cycles. Release a stable version at any time.
Long lived feature branches may get (too much) out of sync with the trunk, impeding merging later on. DTAP street must allow the possibility to test the new feature on an appropriate environment.
Release branching
Release branching with early branching: before a development cycle starts (hence the name early branching) a development branch is created. Changes are made, tested and approved in the development branch. At the end of the development cycle the trunk is updated with all or a selection of the changes from the development branch. Note, this strategy also maintains a stable trunk during the development cycle.
A stable trunk is a trunk in which no changes are made directly. Changes will be made in a separate branch and merged back to the trunk after they are tested and approved. A stable trunk can be released at all times.
Pluses and minuses of this strategy:
Release a stable version at any time. Trunk always contains all new features and changes, no conflicts with merging. Modifying the same part of the application or file is not possible or can cause problems. Unfinished features might cause trouble when they are not developed in a separate branch and affect several parts of the application. Parts of the application that were also changed for a feature that is finished, for instance, or a change in a generic function affecting other functionality.
Release branching with late branching: at the end of a development cycle (hence the name late branching) a release branch is created. Changes are made, tested and approved in the trunk. At the end of the development cycles a new branch is created specifically to release a version of the application. Any unfinished changes or features can be left out by not committing them when creating the branch. Note, this strategy involves an unstable trunk as development is done in the trunk and might lead to not being able to release at any time.
Variation: in order to be able to create a release at any time a variation to Release branching with late branching can be considered. In this variation there is still an unstable trunk but a release branch is created and repeatedly updated whenever a change is tested and approved. For instance, two new features and one small change will be delivered during a development cycle. After the first feature is finished a release branch is created being a copy of the trunk plus the first feature. Later on the development cycle the second feature is merged to the release branch. The small change was only partly finished at the end of the development cycle and hence is not merged to be able to release a stable version of the application.
You can either choose to use the same release branch with every release, updating it every development cycle (use tags to mark releases) or create a new release branch based on the trunk after each cycle.
On the left an example of release branching with late branching is shown. It it the wrong screenshot? No. This is exactly how it is supposed to be. All changes are made to the trunk, that is why each register has Trunk as branch in the screenshot. After all changes are finished a new branch is created, in this case Release_2_0 with the sole purpose to release a selection, or all, changes. No changes are made in the actual branch as opposed to the release branch with early branching.
Pluses and minuses of this strategy:
Trunk always contains all new features and changes, no conflicts with merging. A release version can be carefully composed with all the features from the development cycle which you want to include. It will take effort to be able to release at any time (consider the variation if releasing at any time is required). The same concerns as release branching with early branching apply to release branching with late branching. See above.
No branching
No branching at all: development is done directly in the trunk resulting in an unstable trunk. Tags can be used to indicate milestones or releases which will enable creating a branch of a specific (historic) state of your application if necessary. This strategy can be possibility when the application is not yet released at all or possibly for a small application and a small team. Some form of version management though would be advised, consider release branching.
The example on the right shows an example of this strategy. All changes are done in the Trunk. Tags are added to mark Release_1_0 and Release_2_0. If for instance a bugfix has to be made on Release_1_0 at this very moment, you could create a branch at that specific revision.
Pluses and minuses of this strategy:
Simple. The same concerns as release branching because of the unstable trunk. See above.
How to choose a branching strategy?
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 best 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?
Choose a branching strategy and stick to it across repositories and teams. Evaluate and adjust if necessary.
Overview
Content Tools