Version control

Mendix Team Server provides a version control service for Mendix projects (apps) using Subversion (SVN). This system is integrated into Mendix Studio and Mendix Cloud Platform to provide an easy to manage system for app development.

Github is an alternative version control service based on GIT. It is used for many Mendix widgets, as well as for Mendix’ own documentation system. ShelterBox has its own Github organisational account donated for no charge by Github.

SVN and GIT do have some differences, but many concepts are common such as committing changes, branching and merging.

Branches for application feature development (SVN)

Branch creation

A branch should represent a story (or group of interrelated stories) in the project tracker. Branches should be named in the form: IssueIdentifier_DescriptiveName, where IssueIdentifier is the project trackers’ unique issue identifier and DescriptiveName is a name that is easily relatable to the issue, for example: “VP-123_PassportBugfix”.

Branch merging

We aim to ensure that trunk is ready for release at any time. In order to do this, any development work takes place in a branch, which is merged with trunk only when we are certain that no errors are introduced. The following rules, therefore, apply:

  • Changes of any kind (bugfix or feature) must be made in a branch.
  • The last revision of a branch can only be considered final if all intermediate revisions in trunk have been merged into the branch.
  • The final revision of a branch must be tested and approved before the branch is merged with trunk.

An example of this workflow is as follows:

  1. The project starts with revisions 1 and 2 in trunk.
  2. A feature branch is created (3) from revision 2. This is a big feature, so takes a while to develop.
  3. Meanwhile another feature branch is started (4), changes are committed (5) and are approved before being merged with trunk (6).
  4. Perhaps a bug was found, because we have another branch, commit, approve and merge (7, 8 & 9) before we produce a release (10). Note that this release does not contain any of the work done in the first branch.
  5. A commit of work has finally been done in our open feature branch (11). At this stage we cannot merge the branch with trunk, because there have been changes since the branch was started. To fix this we merge trunk with the branch (12).
  6. Another change is committed (13) before the branch is approved and merged with trunk (14).
  7. Another release is made (15) including the new feature.

Deleting a branch

To avoid clutter, a branch should be deleted once they are of no further use. This could be defined as when the code it contains has been released, or the story has been cancelled.

Glossary of terms

Bugfix (branch)

A branch containing work done to the code of the application to fix incorrect behaviour. Changes to data do not quite fit here, as they are not stored in the version control system. Changes to data may fit if they are made by application logic (i.e. by a microflow or nanoflow).

Feature (branch)

A branch containing code for a single new feature or group of closely related features.

Final revision

The end revision of a branch that is complete (i.e. the feature or bug has been finished) and is ready to be tested. A final revision must have any “workings” (experiments, half finished and abandoned code etc.) removed. All added documents, entities etc. should comply with coding and testing standards. Any changes committed to trunk since the branch was created must be merged into the branch so that conflicts do not occur when the branch is merged into trunk.

Tested revision

A final revision that has been reviewed by another team member. See Testing for more infomation.

Approved revision

A tested revision that has been approved by the product owner as ready to merge with trunk.

To be added…

Naming and numbering conventions

  • https://www.mendix.com/blog/advanced-branching-merging-strategies-part-1-2/

Good descriptions of different version control concepts:

  • https://betterexplained.com/articles/a-visual-guide-to-version-control/
  • https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
  • https://betterexplained.com/articles/aha-moments-when-learning-git/