DevOps (Development and Operations) is the practice of coordinating development, release, and runtime operations, for teams that need to evolve an MDriven application while keeping it available to its users.
In an MDriven solution, DevOps connects ongoing changes in MDriven Designer, continuous integration, deployment, and feedback from users in production. Business rules and requirements continue to change, while the technology and operational environment also change. Treat both as ongoing work rather than as a one-time delivery.
For example, a user may report that a combo box has the wrong sort order the day after a release. You can decide whether the correction requires a complete release or whether it is a view-only correction that can be handled as a SoftView override.
Balance complete releases and targeted fixes
A complete redeployment delivers model and view changes together. This is appropriate when a change affects the model, database schema, or other parts that must remain coordinated.
A targeted view update can reduce the scope of an urgent correction. SoftViews let you place an updated ViewModel definition on the server as an override, so the revised view is used before the next full delivery.
| Change type | Recommended delivery approach | Example |
|---|---|---|
| Model or database schema change | Complete release | Add an attribute or change persistence structure. |
| View layout or presentation change | Consider a SoftView override | Move a field, correct a label, or apply a placing container for a narrow screen. |
| Existing view access configuration correction | Consider a SoftView override with review | Correct access to an existing page without introducing new access groups. |
| Server-side automation view correction | Consider a targeted view update when the correction stays within the existing model | Correct criteria or behavior in a server-side ViewModel that runs periodically. |
A complete release is safer when all related changes need to be tested and delivered as one unit. However, an urgent redeployment can include unrelated changes from the next sprint that have not received the same testing or user review. Use targeted fixes to isolate a known problem, but do not use them as a substitute for planned releases.
Use SoftViews for view-only corrections
A SoftView is an overridden ViewModel definition used by MDrivenServer or MDriven Turnkey before the next normal deployment. It is intended for expressing the existing model in a different view, not for changing the model itself.
For example, you can update a ViewModel to change a presentation string from an attribute name to Hello, then place the updated view definition in the server's override location. When the application reloads the view, it detects the changed file and renders the revised definition. No application restart is required for this type of update.
Do not use SoftViews for changes that alter the database schema or otherwise change the model. A SoftView can still disrupt users if you make an incorrect change. Review and test the revised view before you put it into production.
Keep overrides under version control
Never edit a view XML file directly on the production server. Make the change in your Git repository, where it has version history and can be reviewed.
- Open the ViewModel in MDriven Designer and make the required view-only correction.
- Save the separated view definition with the model files.
- Commit the change to your Git repository.
- Review and test the change against the running application.
- Copy the approved view definition to the server override location.
- Verify the corrected page after it reloads.
- Include the same view change in the next complete release so the override and delivered application remain aligned.
The override is a pre-delivery of the view: it addresses the immediate issue and must also be part of the next ordinary delivery.
Operate with runtime visibility
Use runtime information to verify what a deployed ViewModel contains. In Turnkey, open https://<yoursite>/Turnkey/Development to inspect all definitions for a selected ViewModel and the Angular widgets used to build the standard UI. See Documentation:Development info in runtime for the available runtime inspection URLs, ViewMeta, and Serverinfo.
For example, if a page does not show the expected layout after an override, compare the deployed ViewModel definition in /Turnkey/Development with the version committed in Git before making another production change.
Plan for operational continuity
MDrivenServer is designed to be stateless between requests. This design allows an operator to replace a server DLL during a short interruption; subsequent requests use the updated server. Stateless operation has a trade-off: users must be fully authenticated for each call, which has a performance cost.
Use this operational flexibility with controlled delivery practices. Schedule normal releases, test changes, keep a complete version history, and reserve targeted updates for contained problems that cannot wait for the next release.