Page History
Version management or version control is a general term for keeping control of changes made to software, but also to documents and this page you are viewing right now on my.blueriq.com and so on.
In general implementing or using version management will bring several benefits. For example:
- Multiple developers will be able to make changes to the same application or even the same files
Blueriq version management helps you keep track of and provide control over changes to your models.
The concepts in version management are depicted in the following visualization:
...
Repository structure
...
- without interfering with each others work
...
- .
- Previous versions can be restored and changed if necessary, e.g. to fix a bug in a previous version or to undo a change or feature.
- There can always be a releasable version of the
...
- application, even if not all features have been implemented
...
- or finished.
Version management can be controlled by stand-alone software like Subversion (SVN) or Git, which are two popular open source version control systems. Version management can also be embedded in the software, for instance within web applications to keep track of changes to documents or spreadsheets or blogging software.
Although there are differences between the numerous stand-alone solutions for version management and the built-in functionalities they do share many general concepts. Searching the web will teach you more about these general concepts and the available software solutions. For this current design guide a basic vocabulary will suffice (thanks to Wikipedia for an extensive common vocabulary on version control).
| General term | Description |
|---|---|
Branch | A version or a copy of a certain state of your application. In this copy changes can be made independently of the version it was branched from. |
Change | A change is a modification to a specific branch or file. |
| Commit | Committing is the action of finalizing a (set of) change(s) by committing or merging the working revision to the repository. |
| Conflict | When merging two branches (considering the trunk as a special branch) and one element has been modified in both branches a conflict occurs. Depending on the version control system you can solve a conflict by choosing one of the changes over the other or combining the two changes. |
| Merging | Synchronizing one branch with another (considering the trunk as a special branch), e.g. when a feature is developed in a copy of the trunk and after it is finished the branch is synchronized with the trunk to update the trunk with the newly created feature. Another example is when the trunk is modified after the copy or branch is made and the changes in the trunk are required in the branch. In this case the branch is updated/synchronized with a newer version of the trunk. |
| Repository | The repository can be viewed upon as a file folder where all the application data is stored. This includes the history of application. |
| Revision | A specific state of your application in the entire history of the application. |
| Tag | A milestone or important historical state or snapshot of the application, e.g. to mark a release. |
| Trunk | The basis of your development and application of which branches can be made. (Finished) features or changes in separate branches sink back into the trunk. The trunk can also be referred to as mainline, baseline or masterbranch. |
| Working revision/copy | The current state of your development in a (local) copy of the application. Hence all changes made to the application which are not yet committed to the repository. |
In Blueriq, Version Management is embedded in the software as opposed to a stand-alone version management system. As you will find later on in this design guide most general concepts above can be found within Blueriq Version Management. In the Documentation you can also find the basics of Version Management in Blueriq and the implementation of the mentioned concepts. In this design guide the focus will be on the ways you can implement version control with Blueriq using these concepts as there is not one right way and a strategy must be chosen that fits your application and organization best. In the next part different strategies are discussed.
| Panel | ||||||
|---|---|---|---|---|---|---|
|
When you start developing a new application, the first thing you need is a repository. This repository can be viewed upon as a sort of file folder where all your future application development will be stored.
Development in the repository starts with a single branch. Branches are formed over time when you develop your application and register (or commit) the changes you made in the version management system. Every time you register your changes, version management creates a so called revision. Each revision contains the state that your application was in at the time that the revision was made. A sequence of revisions is called a branch. So after creating your repository, your first branch will contain just one special revision called the working revision. The working revision contains the current state of your development.
Branching strategies
A branching strategy is a plan on how to use branches. There is no right branching strategy. However, there will be a branching strategy that fits your Blueriq development and the technical environment best. It is advised to give it some good thought and choose a strategy together and stick to it. Evaluate the branching strategy and adjust if necessary.
One 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 always is a releasable version of the project. When changes are going to be made, 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) 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 you depends on your team, project, DTAP street and/or technical environment. There are some elements that might help choosing the right strategy for your project:
- Do you need a stable trunk or branch?
- Does the DTAP street support the branching strategy?
- 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 unclear when or if a certain feature will be implemented? It might be useful to use a feature branch.
- How many people/teams have to work in the same models?
Tips & tricks for branching in Blueriq:
- Keep feature branches short-lived. This will prevent conflicts when merging back to the trunk.
- Use tags (when registering your changes) 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 repository's and teams. Evaluate and adjust if necessary.
- Keep the amount of active branches small to prevent conflicts and to remain overview.
- Don't keep a lot of old branches; rather tag your trunk consequently to be able to create a branch when necessary.
...
Overview
Content Tools