CI/CD Pipelines

Introduction

Continuous Integration and Continuous Deployment are foundational practices for modern cloud-native development. In Optimizely CMS 12 running on DXP 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 building reliable, repeatable, and auditable deployment pipelines.

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. This ensures that Production receives the exact binary that was validated earlier, eliminating environment drift and reducing deployment risk.

The typical flow:

• Build and package the application
• Upload the package to Integration
• Validate deployment
• Promote the same package to Preproduction
• Promote to Production

Creating Code Packages for DXP

Deployments begin by creating a deployment package. The application must first be published using the .NET CLI:

The published output must then be packaged into the DXP-specific ZIP format containing the required structure expected by the platform. The resulting deployment artifact is fully self-contained and reused across all environments without modification.

Authenticating with the Deployment API

The Deployment API requires authenticated requests. Authentication uses OAuth-based access tokens generated through the DXP management interface. When using the Optimizely CLI, authentication is performed as follows:

Deploying via the Deployment API

Once authenticated and packaged, upload the deployment artifact to an environment. DXP validates the package before activating it, including structural checks and environment compatibility verification.

After successful deployment and validation, promote the same artifact forward. 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, and Deployment API upload.

API calls can be wrapped inside pipeline tasks using PowerShell scripts or CLI commands, with credentials stored as secure variables. This automation enables:

• Consistent, repeatable deployment processes
• Reduced manual intervention and human error
• Traceable release history tied to specific pipeline executions
• Enforced environment promotion discipline

Operational Workflows in DXP

Operational workflows in DXP are tightly aligned with environment governance. The standard developer workflow:

• Develop locally and commit changes
• Trigger CI pipeline - automatically deploys to Integration
• Perform QA validation in Integration
• Promote to Preproduction
• Conduct UAT and performance checks
• Promote to Production

Because DXP environments are isolated, configuration differences are handled through platform configuration rather than code branching. This separation ensures that the same binary artifact runs across all environments with only injected configuration values differing.

Best Practices for CI/CD in DXP

• Treat the deployment artifact as immutable. Never rebuild between environments - the promotion model only works correctly if the same binary flows through all stages.
• Store API credentials securely within pipeline secret storage. Never commit credentials to source control or echo them in pipeline logs.
• Use environment configuration (DXP config management) instead of conditional code. Environment-specific branches in code are a maintenance liability and undermine the artifact model.
• Validate key workflows - publish, indexing, and integrations - in Integration before promotion. Don't promote forward anything that hasn't been confirmed to work in a cloud context.
• Separate code and content operations so releases do not overwrite editorial state. Content migrations and database changes are separate processes from code deployments.

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 a release needs to be reversed.

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.