Hotfix vs Sprint Branch on a Shared Mendix Model

Tag the exact production commit and create a hotfix branch from that tag, not from main. Apply the smallest possible calculation fix, build from the hotfix branch, and deploy it through an expedited but still tested path. Do not include the non-null Invoice column in the hotfix if production code does not need it. The migration belongs to the sprint release and must be made backward compatible before it ships: add the column as nullable or with a default, backfill it, then add the non-null constraint in a later release. If the hotfix must touch Invoice, use a two-phase migration and verify both old and new code paths. After production verification, merge the hotfix branch back into main immediately, not after the sprint. Expect a conflict in the .mpr file; resolve it with the model comparison and merge tools, and run a full regression on the merged main. To prevent recurrence, shorten feature branch lifetime, merge to main at least twice a week, and cut a release branch two days before release so main can keep moving. Use a versioned release tag for every production deployment so a future hotfix has a clean base. The five-day window is enough to do the hotfix properly if the team resists the shortcut of deploying main.

Automate the build first. Use the Mendix build capability available in your environment to produce an .mda from a Git commit, record the commit hash in the artifact name, and deploy that artifact to acceptance. Remove the manual Studio Pro build and the .mda copy, because they make the tested artifact different from the deployed artifact. Add a smoke suite that covers login, the calculation path and one read and write per critical entity; run it against acceptance before production approval. For the hotfix, allow a reduced but non-empty gate: build, deploy to acceptance, run the calculation regression and the smoke suite, then require one named approver. For normal releases, require the full regression plus a database migration check. Add a static check that fails the pipeline if a non-null column without a default is introduced without an approved migration ticket. Store test results and deployment logs with the commit hash. Keep production approval manual, but make it approve an immutable artifact rather than a rebuild. After the hotfix, add a regression test for the exact calculation bug so the next pipeline run proves it stays fixed. The goal is not a heavier process; it is one path with a documented emergency variant.

The root cause is long-lived branches and a shared development line with rare merges. Make trunk-based development the default: small user stories, feature branches that live days rather than a sprint, and a merge to main at least twice a week. Require developers to update from main before starting work and before committing, and to commit small, coherent model changes rather than a week of work in one commit. Assign ownership of high-traffic documents such as the Invoice entity, the main order microflow and the navigation, and announce when someone is about to restructure them. Avoid parallel edits to the same microflow; split large microflows into smaller callable sub-microflows so changes land in different documents. Use the model comparison tool before merging and review the merged model in Studio Pro, not just the Git diff. Never resolve a .mpr conflict by choosing one side blindly. For hotfixes, merge back within one working day while the change is still small. Add a release checklist that includes a merge from main into the release branch, a smoke test and a tag. Finally, measure merge conflict frequency and branch age; if they do not fall, the team is still batching work and the process change is not real.