Skip to content
Optimizely CertificationOptimizely Certification Optimizely Certification

Deployment Pipeline

intermediate
📜Corecms

Why the deployment pipeline matters

Section titled “Why the deployment pipeline matters”

A broken deployment can take your site offline. A slow deployment process can stall your entire development team. Understanding how Optimizely Cloud builds, packages, and deploys your application helps you design a workflow that is both fast and reliable. When something goes wrong, knowing the pipeline stages tells you exactly where to look.

Pipeline stages

Section titled “Pipeline stages”

When you push code to your repository, the platform executes a four-stage pipeline. Each stage must succeed before the next begins.

Push → Build → Package → Deploy → Verify

1. Build

Section titled “1. Build”

The build stage compiles your .NET application and runs any configured build steps.

What happens:

  • Source code is pulled from your Git repository
  • NuGet packages are restored
  • The solution is compiled in Release configuration
  • Build warnings and errors are logged to the deployment log

Common build failures:

  • Missing NuGet package references
  • Compilation errors in C# code
  • Incompatible package versions
  • Exceeding build time limits (default: 30 minutes)

2. Package

Section titled “2. Package”

After a successful build, the platform creates a deployment package containing your compiled application, configuration files, and static assets.

What happens:

  • Compiled output is bundled into a deployment package
  • Configuration transforms are applied based on the target environment
  • Static files (CSS, JavaScript, images) are included
  • The package is versioned and stored for potential rollback

3. Deploy

Section titled “3. Deploy”

The deployment stage pushes the package to the target environment’s web instances using a zero-downtime strategy.

What happens:

  • A new instance slot is provisioned with the updated code
  • The platform runs health checks against the new slot
  • Traffic is gradually shifted from the old slot to the new one
  • The old slot is kept available for immediate rollback

Zero-downtime deployment flow:

1. New slot starts with updated code
2. Warmup requests hit the new slot
3. Health check passes → traffic shifts
4. Old slot remains on standby (rollback safety net)
5. After verification window → old slot is released

4. Verify

Section titled “4. Verify”

After deployment completes, the platform runs automated health checks to confirm the application is responding correctly.

What happens:

  • HTTP health checks verify the application returns 200 OK
  • Application startup logs are checked for critical errors
  • If health checks fail, automatic rollback to the previous version
  • Deployment status is reported to the management portal and any configured notifications

Deployment triggers

Section titled “Deployment triggers”

Automatic (Integration)

Section titled “Automatic (Integration)”

Pushing to the configured branch triggers an automatic deployment to the Integration environment. This is typically wired to your develop or integration branch.

Manual promotion

Section titled “Manual promotion”

Moving code from Integration to Preproduction, or from Preproduction to Production, requires a manual action. You can promote through:

  • Management portal — Click “Deploy to” on the target environment
  • CLI — Use the deployment CLI to trigger promotion
  • API — Call the deployment API for automated pipelines

External CI/CD

Section titled “External CI/CD”

You can bypass the built-in build system by building externally (GitHub Actions, Azure DevOps, Jenkins) and pushing a pre-built package via the deployment API. This gives you full control over build tools, test execution, and quality gates.

Rollback

Section titled “Rollback”

Every deployment creates a rollback point. If a deployment causes issues, you can revert to the previous version.

Automatic rollback — If health checks fail after deployment, the platform automatically reverts to the previous version. No manual intervention is needed.

Manual rollback — Through the management portal or CLI, you can select any previous successful deployment and redeploy it. This is useful when issues surface after the health check window.

Rollback limitations:

  • Database migrations are not automatically reversed. If your deployment included schema changes, a rollback may require manual database work.
  • Content created by editors between the deployment and the rollback is preserved.
  • Environment variable changes are not rolled back automatically.

Build configuration

Section titled “Build configuration”

NuGet feeds

Section titled “NuGet feeds”

The build system supports:

  • nuget.org — Public packages (default)
  • Optimizely NuGet feed — Optimizely packages (pre-configured)
  • Custom feeds — Private NuGet feeds via nuget.config in your repository

Build scripts

Section titled “Build scripts”

For custom build steps, place a .deployment file and a deployment script in your repository root. The platform will execute your script instead of the default build process.

Build variables

Section titled “Build variables”

Set build-time variables through the management portal:

  • BUILD_CONFIGURATION — Debug or Release
  • WEBSITE_NODE_DEFAULT_VERSION — Node.js version for frontend builds
  • Custom variables for your build scripts

Deployment history

Section titled “Deployment history”

The management portal maintains a complete history of deployments for each environment. Each entry includes:

  • Timestamp — When the deployment started and finished
  • Triggering commit — Git commit SHA and message
  • Duration — Total time from start to completion
  • Status — Succeeded, failed, or rolled back
  • Logs — Full build and deployment output

Use deployment history to correlate site issues with specific code changes. If performance degraded after a particular deployment, the history points you to the exact commit.

Section titled “Related resources”