Deployment, Version Control, and Environment Management
This domain tests the path from model to running app, plus how model changes are versioned and promoted between environments.
From Studio Pro to an environment
You create a deployment package in Studio Pro, which builds the model into a deployable artifact. In the Portal you deploy that package to an environment - typically Development, Acceptance, then Production. Mendix Cloud runs on PostgreSQL, with file storage, backups, logs and metrics available per environment. Configuration that differs per environment is handled with constant values in the Portal, not by editing the model.
Environment management
- Start, stop and restart an environment; put it into maintenance mode.
- Set the administrative (MxAdmin) password at deploy time.
- Manage scheduled events, custom domains/certificates, and restore database backups.
- Client certificates and access restrictions belong to the environment, not the model.
Version control
Team Server stores the project in Git. Daily operations: Update to pull others' commits, Commit with a meaningful message, Revert to discard local changes, and resolve conflicts when they arise. Branch lines let parallel work proceed without blocking the main line, then merge back.
Worked example
Requirement: a second developer must test your change on Acceptance. Reasoning: commit your changes (an uncommitted model lives only on your machine), update to confirm no conflicts, create a deployment package, then deploy it to Acceptance through the Portal. Deploying a package built before your commit simply ships the old model - a frequent cause of 'my fix isn't there'.
Traps
- New attributes change the database structure; your local database synchronizes when you run, after which older revisions may not run locally.
- Conflicts are resolved before committing, not after.
- Constant values set in the Portal override the model defaults per environment.