Content, Data and Promotion📋

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.

“Merge onto production” must expose the different operations involved. A Git merge updates definitions and code. A release build assembles artifacts. Schema migration adapts persistence. Editorial publication changes visibility. Optional data promotion transfers selected records between instance scopes.

These operations can form one guided workflow, but they must remain individually identifiable.

Default behavior📋

Definitions, authored code and versioned layouts participate in the source merge according to their repository policy. The target release uses the resolved package and configuration selections.

Merge data is disabled by default. In that mode, production content and business records are not replaced by their development copies. Any schema migration required by the candidate is still evaluated separately; it may transform target records as part of an explicit migration.

Front and admin of one instance share its data scope. A branch instance defaults to isolation. A new release of an existing instance does not allocate a new data scope automatically.

The promotion screen📋

The proposed workflow shows:

1. Target instance and expected current release.
2. Source revision, candidate artifacts and configuration changes.
3. Required migrations and their effects.
4. A Merge data toggle.
5. Eligible modules/content sets when the toggle is enabled.
6. Each selected module's proposed changes, conflicts and completion checks.

Code-defined policy controls which choices may be offered. The UI, CLI and automated workflow must produce the same effective plan from equivalent inputs.

Module-specific data merging📋

A module must declare its merge support and provide a planning/apply implementation. An illustrative service boundary is:

public interface IDataPromotionContributor
{
    string ModuleId { get; }
    Task<DataPromotionPlan> PlanAsync(
        DataPromotionRequest request, CancellationToken cancellationToken);
    Task<DataPromotionResult> ApplyAsync(
        ApprovedDataPromotionPlan plan, CancellationToken cancellationToken);
}

The named request/result types represent proposed contracts: source/target scopes, optional common baseline, selected record sets, expected revisions, changes, conflicts and outcomes. This is not an implemented SDK.

A module without a compatible merger is unavailable for data selection. The host must not fall back to copying its tables.

Stable record identity, relationships, insert/update/delete behavior and media dependencies belong to the module's merge policy. Required related records must be included, mapped or reported as missing.

Conflicts and concurrent changes📋

Where a common branch baseline exists, the merger compares source and target changes against it. Without one, it must declare a supported alternative or report that automatic reconciliation is unavailable.

For example, a Product description changed in both development and production requires a resolution; production-only Enquiries remain production records. A selected Category cannot be promoted with unresolved references from selected Products.

Unresolved conflicts prevent applying the affected promotion plan. Expected target versions are checked again at application time so that a reviewed plan does not silently overwrite intervening production edits.

Migration, activation and recovery📋

The plan orders required schema work, selected data operations and release activation according to compatibility. Its validity is tied to the expected target release and data/schema state.

Cross-module promotion cannot assume one transaction across unrelated providers. The plan declares its atomic boundaries, retry behavior and recovery steps. It records completed operations if a later stage fails.

Switching application binaries back to a previous release does not undo migrations or promoted records. Recovery must establish which application version is compatible with the resulting data state.

Acceptance📋

DATA-01: promoting with Merge data disabled retains production editorial/business records while still evaluating schema requirements.

DATA-02: enabling it reveals eligible modules and permits selective promotion only.

DATA-03: conflicting edits, missing relationships and stale target revisions require resolution before application.

DATA-04: partial failure reports completed operations and supported recovery; binary rollback is never reported as data rollback.

Previous: Extension Contracts and Compatibility · Next: Reference Scenario and Acceptance Criteria · Series index · Section index