Version Control, DevOps and CI/CD
Version Control, DevOps and CI/CD
This domain tests whether you can run a Mendix team and a Mendix pipeline: branching that fits binary model files, and automation that builds once and deploys the same artifact everywhere.
Core rules
- Team Server is Git-based. Work happens on development lines (feature branches); the main line is what gets released. Merges always flow toward the main line.
- The model is a binary document. Conflicts cannot be merged line by line, so commit small and often, update before you commit, and resolve conflicts in Studio Pro rather than on the command line.
- The
mxcommand line builds a deployment package headlessly, which is what makes CI possible; a self-hosted runner with a matching Studio Pro version is required because the model version is tied to the Studio Pro release. - Pipelines follow build once, deploy many: build the package, run automated tests against acceptance, then promote the identical artifact to production.
- Mendix Cloud API v2 (or the private-cloud operator) drives deployment, start/stop, backups and log retrieval from the pipeline.
- Tag releases in Git so the artifact deployed to production can be traced back to a commit.
Worked example
A pull request triggers a pipeline on a self-hosted agent: mx builds a deployment package, unit tests run, the artifact is published, and the pipeline deploys it to acceptance with acceptance constants. A manual approval gate then promotes the same package to production. Nothing is rebuilt between acceptance and production, so the tested artifact is the released artifact.
Traps
- Building a separate package for each environment.
- Long-lived feature branches that make binary conflicts inevitable.
- Running the pipeline on an agent whose Studio Pro version differs from the team's.
- Shipping without tagging, leaving no way to identify which commit is in production.