1.5 Team Server, Branching & Version Control

1.5 Team Server, Branching & Version Control

Exam Focus: Version control in Mendix requires mastering how Studio Pro interacts with Team Server Git repositories. You will be evaluated on branching paradigms (Main line vs. branch lines), commit and update mechanics, tagged versions, merging strategies, and the exact steps required to resolve document-level and project-level conflicts using Studio Pro's visual Conflict Resolution Editor.

Enterprise low-code development is inherently collaborative. Multiple Business Engineers frequently work simultaneously on domain models, security settings, and complex microflows. Mendix Team Server is a cloud-hosted version control service built on standard Git, engineered specifically to manage both the binary SQLite .mpr project file and associated filesystem assets (theme/, javasource/, userlib/).

---

Team Server Git Architecture & Studio Pro Workflows

Every Mendix application created with Team Server enabled is backed by a remote Git repository. Studio Pro embeds Git operations directly into its UI, providing a seamless workflow:

Core Operations

1. Commit: Captures local changes from your working directory and records them into a new revision. A commit in Studio Pro bundles changes to the .mpr model along with any new or modified disk files (.java, .js, .scss, .jar). Every commit requires a descriptive message and can be directly linked to a User Story ID from the Developer Portal.
2. Update: Fetches revisions from the remote Team Server branch and integrates them into your local working copy. During an update, Studio Pro applies remote changes to your .mpr and disk files. If changes overlap, Studio Pro launches its conflict resolution workflow.
3. Revisions & Hashes: Every commit generates a unique Git revision hash. The History dialog in Studio Pro (Version Control > History) allows developers to inspect all historical revisions, commit messages, author details, and associated user stories.
4. Revert: Discards uncommitted local modifications in your working copy, restoring documents and files to the state of the last committed revision.

---

Branching Paradigms: Main Line, Branch Lines & Tagging

To prevent developers from overwriting each other's work and to protect production stability, enterprise Mendix projects structure development across branches:

1. Main Line (Trunk)

• The central spine of the repository.
• In continuous delivery models, the Main line represents the current stable development state or candidate for the upcoming release.
• For small teams or straightforward sprints, developers commit directly to the Main line with high frequency (multiple times per day).

2. Branch Lines

A branch line is an independent development line created off the Main line (or another branch line). Branch lines are used for:

• Feature Branches: Created to isolate complex, high-risk, or long-running feature development (e.g., "Feature-SSO-SAML-Integration") that spans multiple sprints. Keeps incomplete code from destabilizing the Main line.
• Release Branches: Created when preparing a milestone release for formal Quality Assurance (QA) and User Acceptance Testing (UAT). While QA tests and stabilizes the release branch, feature development continues unimpeded on the Main line.
• Maintenance / Hotfix Branches: Created from a tagged production version to address critical production defects without pulling in incomplete sprint features.

3. Tagged Versions (Tags)

A Tagged Version is an immutable, read-only marker pointing to a specific revision.

• Why Tags are Critical: When deploying to Acceptance or Production in the Mendix Cloud, the platform builds a Mendix Deployment Archive (MDA) directly from a Tagged Version—never from an arbitrary, unversioned local commit.
• Tags ensure complete reproducibility: you can return to the exact codebase of version v2.4.0 years later to audit security or branch off an emergency hotfix.

Merge Workflows & The Studio Pro Conflict Resolution Editor

When multiple branches exist, changes must eventually be combined. Studio Pro provides a visual merge utility accessed via Version Control > Merge Changes Here.

Merge Modes

• Merge feature branch into Main line: Merges all commits from an entire branch line into your active branch.
• Port specific revisions (Cherry-picking): Merges a specific revision range from another branch into your active branch (e.g., backporting a single bugfix commit from a hotfix branch into the Main line).

How Conflicts Arise

A conflict occurs when two developers modify the exact same element between updates or across merged branches. Conflicts are classified into three types:

1. Document-Level Conflicts: The most common conflict type in Mendix. Occurs when two developers edit the same model document (e.g., both modified ACT_CalculateInvoiceDiscount or the Customer_Edit page).
2. Project-Level Conflicts: Occurs when project-wide settings conflict (e.g., modifying security user roles, adding modules with conflicting IDs, or altering language translations).
3. File-Level Conflicts: Occurs in non-model filesystem files, such as Java actions in javasource/, stylesheets in theme/, or duplicate JAR libraries in userlib/.

The Studio Pro Conflict Resolution Editor

When an update or merge encounters a conflict, Studio Pro blocks compilation and highlights conflicting items in red within the Changes on Disk / Conflict Editor pane.

For every conflicting document, the developer must explicitly choose an action:

• Resolve Using Mine: Keeps your local working copy version of the document and discards all modifications made in the incoming revision.
• Resolve Using Theirs: Discards your local modifications and completely overwrites the document with the version from the incoming revision.
• Interactive Visual Merge / Side-by-Side Comparison: For complex microflows or pages, Studio Pro opens both versions side by side. The developer visually reviews the divergent logic paths or widgets, reconciles the design, and manually adjusts the chosen document.
• Mark as Resolved: Once the conflict is reconciled, the developer right-clicks the document and selects Mark as Resolved. Studio Pro clears the conflict flag.

Critical Exam Rule: You cannot commit to Team Server while any document remains in an unresolved conflict state. Studio Pro strictly enforces consistency checks; all conflicts must be resolved, marked as resolved, and pass consistency checks before the Commit button becomes active.

---

Team Collaboration Best Practices & Exam Scenarios

1. The "Update Before Starting, Update Before Committing" Rule

To minimize painful conflicts, follow the golden operational cadence:

• Morning / Task Start: Execute Update to incorporate all colleagues' overnight commits before beginning a new user story.
• Task Completion: Execute Update immediately before committing. If an update introduces a conflict, you resolve it locally against fresh code. Once verified with zero consistency errors, execute Commit immediately.

2. Granular, Story-Linked Commits

Avoid "giant end-of-week commits" containing 50 modified microflows across 6 modules. Instead, commit in small, cohesive batches linked directly to the specific User Story ID. This allows easy rollbacks, clear audit logs, and clean cherry-picking.

3. Production Hotfix Architecture Scenario

A high-severity defect is identified in production running release v3.2.0. Meanwhile, the development team is halfway through a 3-week sprint on the Main line, with extensive, unverified schema changes for version 4.0.0.

Exam-Tested Resolution Procedure:

1. Do not commit the fix to the Main line and attempt to deploy the Main line, as that would prematurely release incomplete, unstable 4.0.0 features.
2. In Studio Pro, navigate to Version Control > Manage Branch Lines and create a new branch line originating from the Tagged Version v3.2.0 (e.g., Branch_v3.2.1_Hotfix).
3. Check out the hotfix branch, implement and test the targeted bug fix.
4. Create a new Tagged Version (e.g., v3.2.1) from the hotfix branch line.
5. Build the deployment package (MDA) from v3.2.1 and deploy it to Production.
6. Finally, check out the Main line and use Merge Changes Here to merge the hotfix revision into the Main line. This guarantees the bug is resolved in production immediately without disrupting active sprint work, and prevents regression in future releases.