Deployment Discipline

By Optimizely Education
Published: Mar 12, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Index-first delivery: CMS 13 treats Optimizely Graph as the primary delivery tier, requiring synchronized deployment of code and schema.
Zero-downtime updates: Smooth Rebuilds utilize a Blue-Green pattern to validate new content models in a "Green" slot before promotion.
Sync protocols: Real-time parity relies on event-driven synchronization, while major refactors require manual full syncs.
Registration order: Service initialization in Startup.cs must prioritize Graph registration to ensure platform tool dependency health.

In the architectural model of CMS 13, successful deployment extends beyond the traditional delivery of application binaries and database migrations. Because the platform relies on Optimizely Graph as the primary delivery tier, deployment discipline must include the management of the external content index. Coordinated synchronization between application code (content types) and the platform index (available GraphQL schema) is paramount to preventing runtime failures in decoupled frontends.

Effective deployment strategies in this environment center on zero-downtime schema updates and rigorous synchronization protocols.

1. The Blue-Green Strategy: Smooth Rebuild

The primary mechanism for maintaining service availability during significant data model or infrastructure changes is the Smooth Rebuild. This follows a Blue-Green deployment pattern where a "Green" slot is populated and validated in isolation while the "Blue" slot continues to serve live traffic.

Application Lifecycle During Rebuilds

When developers introduce new content types or modify existing properties, the corresponding GraphQL schema must reflect these changes.

Parallel Environments: The Smooth Rebuild feature allows for the creation of a new deployment slot. Optimizely populates this parallel slot with the latest content transformed through the updated C# models.
Validation Phase: The Green slot provides a safe territory for comparative testing. Technical teams can execute GraphQL queries against the new schema to ensure that data transformations and property mappings are correct before promotion.
The Switch: Once validated, the Green slot is promoted to live. This promotion is handled at the platform layer, resulting in an instantaneous update to the delivery tier with minimal impact on the end-user experience.

2. Content Synchronization Disciplines

CMS 13 utilizes two distinct synchronization methods to keep the Optimizely Graph in parity with the CMS authoring source. Deployment workflows must account for these methods based on the scale of the release.

Event-Driven Synchronization

Event-driven sync is the preferred method for maintaining real-time parity. It ensures that the platform index is updated automatically whenever a content item or content type is published, updated, or deleted.

Developer Requirement: The Optimizely.ContentGraph.Cms package must be registered in the service container.
Operational Trigger: During minor code updates or regular editorial activity, the system handles the delta updates without manual intervention.

Scheduled and Manual Full Synchronization

For major deployments—such as initial site launches, massive content migrations, or significant C# class refactoring—manual full synchronization is required.

Post-Deployment Protocol: Immediately following a code deployment that alters content structures, a full synchronization job should be triggered from the CMS Admin view.
Optimization: Optimizely utilizes document hash values to prevent redundant data transfer, ensuring that full synchronizations are as performant as possible.

3. Technical Implementation and Coordination

The coordination of these platform tools is achieved through the initialization of the Content Graph services. The order of registration in Startup.cs is critical for ensuring that all dependent platform modules, such as Content Manager, can utilize the index immediately after deployment.

public void ConfigureServices(IServiceCollection services)
{
    // Register CMS core services
    services.AddCms();

    // Register Graph integration BEFORE Content Manager
    // This ensures that the indexing events are correctly hooked into the pipeline
    services.AddContentGraph();

    // Enable other platform tools that depend on indexed content
    services.AddContentManager();
}

Infrastructure Reset Protocols

In scenarios where the platform index reaches an inconsistent state or legacy defects need to be purged, CMS 13 provides a Graph Source Reset functionality. This allows for a clean state rebuild without disrupting live traffic, providing a technical safety net during complex troubleshooting or infrastructure upgrades.

4. Release Discipline Checklist

Technical leads should adhere to the following operational standards for every CMS 13 release:

Trigger	Deployment Action	Expected Outcome
Property/Class Update	Trigger event-driven delta sync	Real-time update of the GraphQL schema
Major Refactor	Execute Smooth Rebuild (Green Slot)	Zero-downtime promotion of a new indexed state
CI/CD Build	Run `dotnet publish` and deploy binaries	Update application logic and content type definitions
Post-Release Audit	Validate endpoint health via Graph API	Confirm delivery tier parity with the CMS source

Conclusion

Transitioning content delivery to a platform-managed index requires a shift in deployment perspective. By treating the Optimizely Graph index as a first-class citizen in the release pipeline—utilizing Smooth Rebuilds for schema transitions and rigorous synchronization for data parity—technical teams ensure that digital experiences remain resilient, high-performing, and decoupled from backend maintenance cycles.