Version Control & Multi-User Development

How Does Mendix Support Multi-User Development?

Mendix Studio Pro combines multi-user development across different skill levels. More information can be found in App Development.

At the start of a project, all team members can work together on the main line of the version control repository. Mendix Studio Pro users can share app updates with the rest of the team using the update and commit pattern via the version control repository.

How Does Version Control Work in Mendix?

Mendix supports the use of a centralized version control repository based on Git, which is the Mendix Team Server. Every project built using the Mendix Platform comes with the Team Server version control system. The Team Server uses Git technology and enables multiple developers to work on the same project, continuously merging model changes into revisions held inside the version control repository. For apps based on Mendix 9 and below, Mendix also supports Subversion (SVN)-based repositories.

This diagram presents the Mendix version control architecture:

Developers can manage revisions and conflicts as well as create branch lines, which can be merged back to a mainline branch as required. Every change in the platform is recorded and compared against other revisions to detect conflicts and manage updates. Users are invited to app projects via the Mendix Portal and assigned security roles, which allow them appropriate access rights to the models held in Team Server.

How Do I Cross-Reference User Stories and Application Change Commits?

Mendix provides an integrated development experience between the Team Server versioning repository, the application Project Dashboard, and Mendix Studio Pro. The integration of the Mendix Team Server version repository with both the app Project Dashboard and Mendix Studio Pro has the following significant advantages:

It provides team members with an integrated way to track requirements throughout the whole development and delivery cycle. When you start working on your application, you just open Mendix Studio Pro to see the user stories planned for the current Sprint and start working on them.
When team members commit app model changes to the Team Server from within Mendix Studio Pro, they can select the user stories they have been working on. The Team Server will automatically create links between user stories and the model changes made, providing a way to navigate from commits to the associated requirements.
End-users can provide feedback straight from the user interface of the app, and this feedback can be transferred into a user story. As a developer, you can directly go to the form mentioned in the metadata of the feedback and implement the requested change.
Team members can start discussions in the app Buzz on implemented features (for example, on a dashboard page or business logic in a microflow). From these discussions, new user stories can be created and implemented in Mendix Studio Pro. When linking the model commits to the user story, the full feedback cycle is ready and also cross-referenced.

How Do I Use My Own Repository Instead of Mendix Team Server?

Next to the default central Mendix Team Server versioning repository, you can choose to configure your own on-premises Git repository instead as a versioning repository for your apps. For Mendix 8 and 9, we also support on-premises SVN repositories.

For details on setup, see Working with Git On-Premises Version Control Server in the Mendix Studio Pro Guide.

How Does Mendix Support Branching and Merging?

A development project always starts with a single development line, which is called the main line. This is the development line that will lead within the development process.

A deployment from the main line must contain all the (released) functions of the application. In addition to the main line, a project can have multiple branch lines. Branches are made from a specific commit (revision) to the main line or a branch line. Creating a branch means that a copy is made of the selected revision that will be used as the starting revision for the new development line. This enables the developer to change the model in an isolated line. In most cases, a branch line is used for solving issues in a released version of the application at the same time as ongoing development continues in the main line. This allows for new development in the main line without the release of functionality that has not been finalized or tested. After you create a branch and solve the issue (or create a new large feature), it is possible to merge these changes with the main line.

Thanks to Mendix’s model-driven development approach, merging models takes place with a higher level of accuracy than merging code. This is because Mendix understands the semantics of the models. This results in fewer conflicts, and if conflicts do arise, they can be resolved in Mendix Studio Pro through the consistency checking mechanisms described above.

Mendix supports creating and merging branches in the Mendix Team Server versioning repository. Next to this, it is possible to tag specific revisions with a release label. This allows teams to use industry patterns, like release branches and feature branches. By default, the Mendix deployment pipelines also use revision tagging to label version revisions with specific deployment pipeline moments. This can be used for auditing and version rollback purposes.

Which Version Repository APIs Are Available for Custom Versioning Integrations?

The Mendix versioning functionality is exposed through an API in the Team Server repository so that it can be called by other platform services or external applications. For example, a get latest commit call to the Team Server versioning repository API for an app project will return the latest revision of the artifacts for the project.

How Can I Review Changes Made by Other Developers After Performing an Update?

When retrieving new updates from the Mendix Team Server in Mendix Studio Pro, the developer has full control over which changes to accept or revert. After the update, all the changes are merged into the local model. When there is a merge conflict between the changes made by the developer and the update from the Mendix Team Server, the developer receives an overview of all the merge conflicts. This information can be used to determine whether the local change should be used or the change from the Team Server.

At all times, the developer is in control of which changes and merge conflicts are accepted. Changes can be reverted to the original version before committing the final version to the Team Server again.

How Does Mendix Support Version Diffing and Conflict Resolution?

Mendix Studio Pro has built-in diffing support on the application model. This means that when the developer retrieves changes from the versioning repository for all the app documents (like pages, microflows, and integrations), both versions are compared. Mendix Studio Pro checks that there are no conflicting changes and then automatically merges the two versions. The resulting changes can always be reviewed before committing the latest version to the versioning repository again. The developer has full control of the process.

What Are the Conflict Resolution Capabilities in Mendix Studio Pro?

When the changes result in a conflict (for example, you change a page which had been deleted by another developer), Mendix Studio Pro will provide feedback that this conflict has to be resolved first.

Mendix Studio Pro provides conflict resolution by showing detailed information about what the differences between two versions of a document are (for example, when you edit a list on a page, then someone else from the team deletes the list from that page). When a document is marked as conflicted, you can see the detailed reason(s) for the conflict and use a fine-grained version-resolution mechanism. You do not have to choose between whole documents. Instead, you can resolve conflicts at the level of individual elements inside the documents (such as widgets, entities, attributes, or microflow actions). All non-conflicting changes from both sides are accepted automatically. For more information about how to use the conflict resolution, see New Merge Algorithm with Fine-Grained Conflict Resolution in the Studio Pro Guide.

Mendix Studio Pro can also handle conflicts at the level of an app. You can resolve an app conflict by choosing “my version” or by deleting the documents or folders involved.

Here are two examples:

One developer deletes a document and another makes a change inside that document
Both developers move a document, but they move it to different places in the tree

If a whole folder (or module) was deleted and another developer changes a document inside that folder, the folder is restored locally and also marked as conflicted. This way, you know that the intention was to delete that folder, but it was restored to show the context of the changed document.

How Can I Resolve Conflicts in External Files like Java Classes, Widgets, and Images?

By default, Mendix Studio Pro performs a diff comparison on external files like Java classes. When there are new versions or files have been deleted, this is directly handled by Mendix Studio Pro itself.

For additional diffing or conflict resolution on external files, external visual and command-line tools for Git and SVN can be used.