Skip to main content

Outline

At a glance
  • DXP is artifact-first: build once, then deploy/promote the same package forward.
  • Promotion-based workflow: Integration → Preproduction → Production, no rebuild on promotion.
  • Deployment API + CLI: pipelines authenticate, upload packages, validate, then promote.
  • Config is environment-scoped: differences live in DXP configuration, not conditional code.

Introduction

Continuous Integration and Continuous Deployment are foundational practices for modern cloud-native development. In Optimizely CMS 12 running on Digital Experience Platform PaaS, CI and CD are not optional improvements but integral parts of how solutions are expected to move between environments.

Unlike traditional on-premise deployments where files may be copied manually or deployed through ad hoc scripts, Optimizely DXP enforces a structured deployment model using a Deployment API and managed environment promotion workflows. Understanding this API-driven model is essential for developers who want to build reliable, repeatable, and auditable deployment pipelines.

This article explains how CI/CD pipelines operate in DXP, how code packages are structured, how authentication works, and how operational workflows are designed around the Deployment API.

The deployment model in DXP

Optimizely DXP uses a promotion-based deployment workflow. Code is packaged into a deployment artifact and uploaded to an environment. Once validated, the same artifact is promoted between environments without rebuilding.

The typical flow is:

  1. Build and package the application
  2. Upload the package to Integration
  3. Validate deployment
  4. Promote the same package to Preproduction
  5. Promote to Production

This model ensures that Production receives the exact binary that was validated earlier. It eliminates environment drift and reduces deployment risk.

Creating code packages for DXP

Deployments begin by creating a deployment package. According to Optimizely documentation, the application must first be published using the .NET CLI.

Example:

dotnet publish -c Release -o ./publish

This command generates the compiled output required for deployment.

The published output must then be packaged into the DXP-specific format. The official documentation describes creating a ZIP package containing the published files and the required structure expected by DXP.

The deployment artifact represents a fully self-contained build that can be reused across environments.

Authenticating with the Deployment API

The Deployment API requires authenticated requests. Authentication is handled using API credentials associated with the DXP project.

The official documentation describes authenticating API requests using OAuth-based access tokens. API credentials are generated through the DXP management interface and used by deployment scripts or pipeline tasks.

When using the Optimizely CLI, authentication is typically performed as follows:

epi cloud login

This command establishes a session against the DXP project.

In automated CI/CD pipelines, authentication credentials are stored securely as pipeline secrets and injected at runtime.

Deploying via the Deployment API

Once authenticated and packaged, the deployment artifact can be uploaded to an environment.

Example CLI command:

epi cloud deploy --projectId <project-id> --environment Integration --package <package-path>

This uploads the package to the Integration environment.

The platform validates the package before activating it. Validation includes structural checks and environment compatibility verification.

After successful deployment and validation, the same artifact can be promoted.

Example promotion command:

epi cloud promote --projectId <project-id> --source Integration --target Preproduction

Promotion does not rebuild or repackage the application. It reuses the exact artifact that was previously uploaded.

Integrating with CI/CD systems

The Deployment API is designed to be integrated into CI/CD platforms such as Azure DevOps or GitHub Actions.

A typical CI pipeline includes:

  • Source code checkout
  • Dependency restore
  • Build and publish
  • Artifact packaging
  • Deployment API upload

In Azure DevOps, the Deployment API can be invoked using PowerShell scripts or CLI commands. Community examples demonstrate wrapping API calls inside pipeline tasks, storing credentials as secure variables, and triggering deployments automatically after successful builds.

This automation enables:

  • Consistent deployment processes
  • Reduced manual intervention
  • Traceable release history
  • Environment promotion discipline

Operational workflows in DXP

Operational workflows in DXP are tightly aligned with environment governance.

Developers typically follow these steps:

  1. Develop locally and commit changes
  2. Trigger CI pipeline
  3. Automatically deploy to Integration
  4. Perform QA validation
  5. Promote to Preproduction
  6. Conduct UAT and performance checks
  7. Promote to Production

Because DXP environments are isolated, configuration differences are handled through environment configuration rather than code branching.

This separation ensures that the same binary artifact runs across all environments.

Handling existing CMS sites

When migrating an existing CMS site to DXP, the process includes:

  • Publishing the application
  • Packaging according to DXP format requirements
  • Uploading via Deployment API
  • Verifying environment configuration

The documentation emphasizes validating configuration settings and connection strings before promoting to higher environments.

Best practices for CI/CD in DXP

Effective operational workflows in DXP follow several principles:

  • Treat the deployment artifact as immutable. Never rebuild between environments.
  • Store API credentials securely within pipeline secret storage.
  • Use environment configuration (DXP config management) instead of conditional code.
  • Validate key workflows (publish, indexing, integrations) in Integration before promotion.
  • Separate code and content operations so releases do not overwrite editorial state.

Governance and traceability

Because deployments are API-driven and artifact-based, DXP supports auditable release management.

Each deployment is traceable to a specific artifact and pipeline execution. This supports enterprise governance requirements and simplifies rollback strategies if necessary.


Conclusion

CI/CD pipelines in Optimizely CMS 12 PaaS are built around the Deployment API and structured environment promotion workflows. Code is compiled, packaged, authenticated, uploaded, validated, and promoted across Integration, Preproduction, and Production environments.

By integrating the Deployment API into CI/CD platforms, development teams can achieve reliable, repeatable, and governed deployment processes that align with enterprise cloud standards.

Understanding how artifacts are built, authenticated, uploaded, and promoted is essential for building scalable and operationally sound CMS 12 solutions in DXP.