The Integrated Lab
Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.
The Lab is the part of Diem that connects an application's description to its running instances and development workspaces. It is a required product capability. Its network exposure, authorized users and security mechanisms are configuration decisions.
A small installation can use a modest set of Bundles. A larger installation can manage several sites and infrastructure targets. “Mandatory” does not mean that every possible service, provider or user interface must be enabled in every deployment.
A branch becomes a place to work
For Acme Catalogue, www.monsite.com serves the main release and admin.monsite.com administers the same instance. A managed branch named mon-essaie can acquire mon-essaie.dev.monsite.com, backed by a separate editable instance on the production hosting environment.
The word dev in that address describes the chosen naming convention. It does not move the workload to a different physical environment. The Lab records hosting, branch, role and execution capabilities explicitly.
A branch created through the Lab, or observed in a configured remote repository, triggers the managed lifecycle. A branch that exists only on an unconnected laptop cannot be discovered until an integration reports it.
Work from source or from artifacts
| Source | Lab responsibility |
|---|---|
| Git checkout | Select the branch and revision, prepare a workspace, expose edit and build capabilities |
| Filesystem workspace without Git | Preserve its files, attach tools and identify the exact snapshot used for a build |
| Compiled extension artifacts | Resolve dependencies and assemble a compatible release |
| Mixed application | Track Git, local and packaged inputs in the same release description |
An IDE can run in the browser or connect from the developer's machine. In both cases it uses the intended workspace. Saving a valid change can trigger generation and hot reload where supported; a more structural change may require rebuilding and restarting.
The Lab should show what is running, including whether a preview contains uncommitted changes. A production release identifies its actual inputs, rather than merely displaying the latest branch name.
Release without mixing every kind of change
“Merge onto production” is a product workflow spanning several operations. The source merge updates definitions and code. A build creates candidate artifacts. Validation determines whether they can be activated.
The workflow also offers Merge data, disabled by default. Enabling it exposes eligible modules and content sets. The user can review differences and resolve conflicts according to each module's merge policy. Production enquiries do not get replaced merely because a developer tested the catalogue on another branch.
Required schema migrations are considered separately. Declining optional data promotion does not imply that a new schema can run without migration.
Existing tools, described through Diem
The Lab integrates GitLab, routing, storage and execution tools through Bundles and typed C# wrappers. A Bundle describes a service or configuration artifact; a wrapper executes the required binary with structured arguments and results.
GitLab already documents review environments associated with branches or merge requests. Diem's proposed contribution is to connect those mechanisms to its instance model, generation, editing and extension capabilities. GitLab review apps (ouvre dans une nouvelle fenêtre).
The Lab specification defines readiness, updates and cleanup. The self-describing Lab explains how the same mechanisms can describe the Lab itself.
Previous: Modeling and Generating the Admin · Next: Module Generation and Derived Products · Series index · Section index