Continuous Delivery for SAP Commerce Cloud: Your Pipeline in Front of Theirs

CCv2 ships with a builder, and the most expensive misunderstanding in commerce DevOps is treating it as your CI. The cloud builder takes 20 to 45 minutes per run, gives feedback only after the fact, and bills its capacity against your subscription; using it to discover that a unit test fails is using a freight train to deliver a text message. The architecture that works puts your CI in front: fast, self-controlled feedback on every commit, and the cloud builder invoked only for artifacts that already earned the trip. This guide covers that architecture: the build tiers, the quality gates, the Cloud Portal API glue, and the honest answer to "should merges deploy straight to production?"

The Shape of the Pipeline#

Components you need, whatever brands you choose: a Git repository (the same one Cloud Portal is connected to), a CI server (Jenkins remains common in this ecosystem, and the original CX Works sample pipelines were Jenkins; GitHub Actions and GitLab CI do the job identically), SonarQube for quality gates (see the coding standards guide), and build agents capable of running the platform, meaning the SapMachine JDK matching your update release track and enough memory to initialize the platform with the JUnit tenant.

The flow, end to end:

commit -> PR pipeline (fast build + fast tests + Sonar gate)
       -> merge to develop -> incremental build + broader tests
       -> nightly: full from-scratch build + initialize + full suites + analysis
       -> release candidate -> CCv2 build via API -> deploy to DEV (auto)
       -> promote to STAGE (gated) -> promote to PROD (gated, humans decide timing)

Two Build Tiers, Deliberately Different#

The classic two-tier discipline predates CCv2 and survives it intact, because it is about feedback economics:

Incremental builds run on every commit or PR: reuse the previous workspace, ant build over changed extensions, run the fast unit test subset, report in minutes. Their only job is rapid feedback, so everything slow is deliberately excluded. Frequent integration is what makes this tier pay: developers merging small and often get conflicts and integration breakage while the context is a day old, not a sprint old.

Nightly full builds start from an empty workspace and prove the thing the incremental tier structurally cannot: that the system builds and initializes from scratch. The full sequence is worth writing out because each step catches a real failure class:

1. Clean workspace, fresh checkout
2. Install the platform binaries for the pinned version
3. Full ant clean all
4. ant initialize, the step that catches broken essential data, ImpEx ordering bugs, and type-system issues that update-based development hides (the code review playbook's "initialization must work" rule, enforced nightly)
5. Initialize the JUnit tenant
6. Unit tests, then integration tests, with coverage instrumentation
7. Static analysis (ant sonarcheck) and security scanning
8. Reports published: tests, coverage, analysis trends
9. Optionally: package the artifact, trigger the CCv2 DEV build and deployment

When the suites grow, split further along the natural seams: a functional-test job per environment, a dedicated quality job, and a performance job on schedule (the performance engineering guide's weekly load test slots in here as just another pipeline stage).

Quality Gates That Actually Gate#

A pipeline that reports without blocking is a dashboard. The gates that earn their enforcement, in order of adoption:

1. Compilation and fast tests green before merge; no exceptions, including "it's just ImpEx".
2. Sonar quality gate on new code per the coding standards guide: new blockers fail the PR check.
3. Initialization green nightly; a red initialize blocks release candidacy and pages whoever merged since the last green one.
4. Integration suite green on the release branch before any CCv2 build is triggered.

The cultural half matters more than the tooling half: a broken nightly is the team's first priority the next morning, or the whole tier decays into background noise within a quarter.

Driving CCv2 From the Pipeline#

The seam between your CI and SAP's builder is the Commerce Cloud API (token-authenticated, per the first-deployment guide). Your pipeline treats a cloud build like any other stage: trigger, poll, act on the result. The shape, in portable shell (wrap it in a Jenkinsfile stage, a GitHub Actions step, whatever you run):

# 1. trigger the build for the release branch
BUILD=$(curl -s -X POST \
  "https://portalrotapi.hana.ondemand.com/v2/subscriptions/${SUB}/builds" \
  -H "Authorization: Bearer ${CCV2_TOKEN}" -H "Content-Type: application/json" \
  -d '{"branch":"release/2026-07","name":"rc-'"${GIT_SHA}"'"}' | jq -r .code)

# 2. poll until terminal state (builds run 20-45 min; poll gently)
while :; do
  STATUS=$(curl -s -H "Authorization: Bearer ${CCV2_TOKEN}" \
    "https://portalrotapi.hana.ondemand.com/v2/subscriptions/${SUB}/builds/${BUILD}" | jq -r .status)
  case "$STATUS" in
    SUCCESS) break ;;
    FAIL|DELETED) echo "cloud build ${BUILD} ended: ${STATUS}"; exit 1 ;;
    *) sleep 120 ;;
  esac
done

# 3. deploy to the target environment
curl -s -X POST \
  "https://portalrotapi.hana.ondemand.com/v2/subscriptions/${SUB}/deployments" \
  -H "Authorization: Bearer ${CCV2_TOKEN}" -H "Content-Type: application/json" \
  -d '{"buildCode":"'"${BUILD}"'","environmentCode":"d1",
       "databaseUpdateMode":"UPDATE","strategy":"ROLLING_UPDATE"}'

Pipeline-design notes from running this in anger:

• One cloud build, many deployments. Build once per release candidate and deploy that same buildCode to DEV, then STAGE, then PROD. Rebuilding per environment forfeits the whole "tested artifact" premise.
• Deployment mode is a parameter, not a constant: UPDATE for routine releases; INITIALIZE exists only for non-production and belongs behind an explicit, ugly-looking pipeline parameter that nobody can pass by accident.
• Surface the build log on failure. The API serves it; a pipeline that says "cloud build failed, go find the log in the portal" wastes ten minutes per failure, forever.
• Track what is where. An environment dashboard (the Jenkins plugin, or a pinned channel message updated by the pipeline, the medium is irrelevant) answering "which build is on STAGE right now?" removes a surprising amount of release-week confusion. Your deployment stage already knows the answer; make it write it down.
• Credentials (CCV2_TOKEN, Git tokens, Sonar tokens) live in the CI system's secret store with masking on, never in pipeline files, the same hygiene the first-deployment guide demands of commerce properties.

How Far Toward Production Autopilot?#

The honest maturity ladder, with the observation that most teams should stop one rung below where their tooling could take them:

Rung 4 is the sweet spot for almost everyone: the mechanics of a production deployment are fully automated (one button, or one workflow_dispatch), while the timing stays human, because commerce production deployments interact with business operations (campaigns, imports, peak windows; see the high-traffic guide) in ways a pipeline cannot see. Rung 5 is real and reachable (zero-downtime rolling deployments make it technically safe), but it is a bet on your automated test suite being a complete proxy for "safe to ship", and that bet should be made explicitly by people who have read their own coverage reports, not implied by a pipeline default.

Whichever rung you occupy: the database-affecting release is the one that deserves extra ceremony. Type-system changes ride deployments with migration semantics (the data loading and upgrade guides cover the modes), and a pipeline that makes deploying easy must not make deploying thoughtless; a required "this release changes the type system: yes/no" parameter, gating an extra reviewer, is cheap insurance.

Getting There From Zero#

The adoption order that avoids boiling the ocean: wire the PR pipeline first (fast build, fast tests, Sonar), because it improves every developer's day immediately; add the nightly full build with initialization second, because it protects the thing nothing else checks; add the CCv2 API stage third, killing the portal-click ritual; and only then argue about auto-promotion, from a position of six months of green nightlies. Teams that start by debating rung 5 ship rung 0 for a year; teams that climb in this order are at rung 4 in a quarter, wondering why deployments used to be events.