Deployment, Environments and Version Control
Deployment, environments and version control
Studio Pro stores the model in a .mpr file plus document files, tracked by version control (Git, typically on Mendix Team Server). Commit pushes your changes as a revision, update pulls others' work, and conflicts must be resolved before committing. Any revision can be deployed or reverted to.
Deploying to a licensed Mendix Cloud node involves several environments - commonly development, acceptance and production. Deployment packages the model into a deployment archive; the cloud portal holds environments, environment variables, constants per environment, custom runtime settings, backups, logs and metrics. Constants can be overridden per environment, which is why endpoints, credentials and feature flags belong in constants or environment variables rather than hard-coded in the model.
Traps
- Synchronize database during a production deploy. Synchronization handles additive changes (new entities, new attributes) but cannot fix changed attribute types, shortened strings, or removed attributes that still hold data. Production normally means deploy without synchronization plus a planned migration.
- Development constant values do not travel to production; check the portal values after deploying.
- Version mismatch between Studio Pro, the runtime and the cloud node causes deploy-time errors.
- Forgetting a backup before a migration makes an irreversible mistake permanent.
Rule of thumb
Ask "does this change the shape of existing tables?" If yes: plan a migration, take a backup, and deploy without synchronization. If the change is purely additive and the environment is development or acceptance, synchronization is acceptable.