Deployment, Environments and Cloud Operations
Deployment, Environments and Cloud Operations
This domain tests the operational side: what a deployment package actually contains, how environments differ, and how to run production without surprises.
Core rules
- A deployment package holds the compiled model, not the data. Build it once in Studio Pro or with the
mxcommand line, and promote the same artifact through acceptance to production. - Environment differences belong in constants, not in the model. Configure them per environment in the cloud portal or the private-cloud operator.
- Mendix Cloud gives you environments (development, acceptance, production), backups, restore, maintenance mode, log levels and metrics. Private Cloud runs the same runtime on Kubernetes via the Mendix operator; on-premises runs the runtime on a servlet container you operate.
- Size the JVM heap and instance count deliberately; adding instances scales request handling but not the database.
- Log levels are per node. Set debug temporarily, then return to info - debug logs in production fill disks fast.
- Data transport between environments moves a database copy; it is not a code deployment and must never run backwards into production.
Worked example
Promotion: build the .mda on the pipeline agent, deploy it to acceptance with acceptance constants, run smoke and integration tests, then deploy the identical artifact to production after changing only the constant set. Rollback means redeploying the previous artifact - which only works if artifacts were never rebuilt per environment.
Traps
- Building a fresh package for production, so what was tested is not what runs.
- Storing credentials in model constants committed to the repository.
- Leaving debug logging on a production node.
- Restoring a production backup over acceptance and assuming it is harmless.