{"id":2357,"date":"2026-05-19T10:00:00","date_gmt":"2026-05-19T07:00:00","guid":{"rendered":"https:\/\/commerce-consulting-services.com\/en\/?p=2357"},"modified":"2026-03-24T09:47:05","modified_gmt":"2026-03-24T07:47:05","slug":"sap-commerce-cloud-cicd-best-practices","status":"publish","type":"post","link":"https:\/\/commerce-consulting-services.com\/lv\/sap-commerce-cloud-cicd-best-practices\/","title":{"rendered":"SAP Commerce Cloud CI\/CD Pipeline: Setup and Best Practices"},"content":{"rendered":"

[et_pb_section fb_built=”1″ admin_label=”Hero” _builder_version=”4.27.5″ _module_preset=”default” custom_padding=”0vw||80px||false|false” locked=”off” collapsed=”on” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_row _builder_version=”4.18.0″ _module_preset=”5138c454-be54-4233-bd3b-f8e6a8747976″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.18.0″ _module_preset=”73121f80-a3ef-4484-8763-c3f18e3c56d2″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”SAP Commerce” _builder_version=”4.27.5″ _module_preset=”f0c675ea-2574-4d0e-b725-30f8550a8550″ title_level=”h4″ title_font=”IBM Plex Sans|IBM Plex Sans Condensed_weight||on|||||” title_text_color=”#1d3557″ title_font_size=”14px” title_letter_spacing=”1px” title_line_height=”1.4em” custom_margin=”||10px||false|false” locked=”off” global_colors_info=”{%22#1d3557%22:%91%22title_text_color%22%93}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_heading title=”SAP Commerce Cloud CI\/CD Pipeline: Setup and Best Practices” _builder_version=”4.27.5″ _module_preset=”ddeb8c09-9078-4424-bc15-2efb6572e28e” title_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_post_title title=”off” meta=”off” featured_image=”on” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_post_title][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

A team deploying SAP Commerce Cloud once a month is not being cautious. It is accumulating risk. Large, infrequent deployments carry more changes, more potential conflicts, and more pressure when something goes wrong. In contrast, teams deploying multiple times per week ship smaller changesets, catch issues earlier, and build confidence in their release process.<\/p>\n

Getting to frequent, reliable deployments in SAP Commerce Cloud requires a well-designed CI\/CD pipeline. This is more complex than in typical web applications because of SAP Commerce’s build system, type system migrations, and the interplay between code and data (ImpEx). This guide covers the pipeline design, tooling, and operational practices that make continuous delivery practical for SAP Commerce projects.<\/p>\n

[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Why CI\/CD Matters More for SAP Commerce” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

SAP Commerce projects have characteristics that make CI\/CD both harder and more important than in typical applications.<\/p>\n

Long build times.<\/strong> A full SAP Commerce build (compiling all extensions, running the platform build) can take 15-30 minutes. Without pipeline optimization, developers wait too long for feedback.<\/p>\n

Type system migrations.<\/strong> Changes to items.xml<\/code> files require database schema updates (system update). If two developers modify the type system in conflicting ways, the conflict is only visible at system update time, not at compile time.<\/p>\n

Data-code coupling.<\/strong> SAP Commerce relies heavily on ImpEx for data setup, content, and configuration. Code changes often require corresponding data changes, and the two must deploy together in the right order.<\/p>\n

Environment complexity.<\/strong> CCv2 provides multiple managed environments (dev, staging, production) with specific characteristics around scaling, data, and connectivity. The pipeline must manage builds and deployments across these environments.<\/p>\n

These factors mean that ad-hoc deployment processes break down faster in SAP Commerce than in simpler applications. Investing in CI\/CD infrastructure pays dividends throughout the project lifecycle.<\/p>\n

[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”SAP Commerce Cloud Build System Overview” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

Understanding how CCv2 builds work is prerequisite to designing a good pipeline.<\/p>\n

The Build Process<\/h3>\n

When you trigger a build in CCv2:<\/p>\n

    \n
  1. The platform pulls your source code from the configured repository (the repository<\/code> section of manifest.json<\/code>).<\/li>\n
  2. It resolves and downloads the SAP Commerce platform artifact and any configured AddOns or third-party libraries.<\/li>\n
  3. It runs the Ant build process, compiling all extensions declared in manifest.json<\/code> (which generates localextensions.xml<\/code> at build time).<\/li>\n
  4. It packages the result into a Docker image that will be deployed to Kubernetes pods.<\/li>\n<\/ol>\n

    The build configuration lives in manifest.json<\/code>, which specifies the commerce version, extensions, aspects (storefront, backoffice, backgroundProcessing), AddOns, properties, and web tests.<\/p>\n

    Build Triggers<\/h3>\n

    CCv2 builds can be triggered through the Cloud Portal UI, the CCv2 REST API, or the SAP Commerce Cloud CLI tool. For CI\/CD, the REST API or CLI tool is the integration point. Your CI pipeline triggers a CCv2 build, polls for completion, and then triggers a deployment to the target environment.<\/p>\n

    Build Limitations<\/h3>\n

    CCv2 has build concurrency limits (typically one or two concurrent builds per subscription). This means you cannot run parallel builds for multiple branches simultaneously without queuing. Factor this into your pipeline design: feature branch builds may need to queue behind each other.<\/p>\n

    [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Source Code Management Strategy” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

    Branching Model<\/h3>\n

    For SAP Commerce projects, a simplified Git Flow works well:<\/p>\n

    main<\/code> (or master<\/code>)<\/strong> – always deployable. Represents the current production state. Protected with required reviews and passing CI checks.<\/p>\n

    develop<\/code><\/strong> – integration branch where feature branches merge. Represents the next release candidate. Deployed to the development environment automatically.<\/p>\n

    feature\/*<\/code><\/strong> – short-lived branches for individual features or stories. Branch from develop<\/code>, merge back via pull request.<\/p>\n

    release\/*<\/code><\/strong> – created from develop<\/code> when a release is being prepared. Only bug fixes and release-specific configuration changes go here. Merges to both main<\/code> and develop<\/code> upon release.<\/p>\n

    hotfix\/*<\/code><\/strong> – created from main<\/code> for urgent production fixes. Merges back to both main<\/code> and develop<\/code>.<\/p>\n

    The key discipline: keep feature branches short-lived (days, not weeks). Long-lived feature branches diverge from develop<\/code>, and the merge becomes risky, especially when type system changes are involved.<\/p>\n

    Monorepo vs. Multi-repo<\/h3>\n

    SAP Commerce projects typically work best as a monorepo containing all custom extensions, storefront code, configuration, and ImpEx scripts. A monorepo ensures that code changes and their corresponding data changes are committed atomically. Multi-repo setups (separate repos for backend and frontend, or per-extension repos) create coordination overhead that is rarely justified.<\/p>\n

    If you are using Composable Storefront (headless), the frontend deserves its own repository with its own pipeline, since it deploys independently. The backend SAP Commerce code remains in a monorepo.<\/p>\n

    Type System Change Discipline<\/h3>\n

    Changes to items.xml<\/code> files are the most dangerous changes in SAP Commerce. They alter the database schema and can cause data loss if done incorrectly. Establish these rules:<\/p>\n

      \n
    • Never remove an attribute<\/strong> from items.xml<\/code> without a migration plan for existing data.<\/li>\n
    • Never change an attribute type<\/strong> (e.g., from String to Integer) on an existing attribute. Create a new attribute and migrate data.<\/li>\n
    • Review all items.xml<\/code> changes<\/strong> with heightened scrutiny in pull requests.<\/li>\n
    • Test type system changes<\/strong> by running ant updatesystem<\/code> in CI against a database with realistic data.<\/li>\n<\/ul>\n

      [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Build Automation Pipeline” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

      Pipeline Stages<\/h3>\n

      A well-structured SAP Commerce CI\/CD pipeline has these stages:<\/p>\n

      Stage 1: Code Quality (runs in CI, 2-5 minutes)<\/h4>\n
        \n
      • Compilation check<\/strong> – ant clean all<\/code> in a local CI runner (not CCv2) to verify the code compiles. This is faster than waiting for a CCv2 build.<\/li>\n
      • Static analysis<\/strong> – SonarQube or similar tools scanning for code quality issues, security vulnerabilities, and coding standard violations.<\/li>\n
      • Dependency check<\/strong> – verify no unauthorized or vulnerable third-party libraries have been introduced.<\/li>\n<\/ul>\n

        This stage runs on every push to any branch and provides fast feedback to developers.<\/p>\n

        Stage 2: Automated Tests (runs in CI, 10-20 minutes)<\/h4>\n
          \n
        • Unit tests<\/strong> – standard JUnit tests for service-layer logic, populators, strategies, and utility classes.<\/li>\n
        • Integration tests<\/strong> – tests that require the SAP Commerce application context (Spring context, type system). These use ServicelayerTest<\/code> or ServicelayerTransactionalTest<\/code> as base classes.<\/li>\n
        • API tests<\/strong> – tests against the OCC API endpoints, verifying request\/response contracts.<\/li>\n<\/ul>\n

          More on testing strategy below.<\/p>\n

          Stage 3: CCv2 Build (triggered after merge to develop\/release\/main, 15-30 minutes)<\/h4>\n
            \n
          • Trigger CCv2 build via the REST API or CLI.<\/li>\n
          • Poll for build completion.<\/li>\n
          • Verify build success.<\/li>\n
          • Store build code for deployment.<\/li>\n<\/ul>\n

            Stage 4: Deployment (automated to dev\/staging, gated for production)<\/h4>\n
              \n
            • Trigger deployment of the build to the target environment.<\/li>\n
            • Run post-deployment health checks.<\/li>\n
            • Execute smoke tests.<\/li>\n
            • Notify the team of deployment status.<\/li>\n<\/ul>\n

              Stage 5: Post-Deployment Validation<\/h4>\n
                \n
              • Run end-to-end tests against the deployed environment.<\/li>\n
              • Verify critical business flows (search, browse, add to cart, checkout).<\/li>\n
              • Check monitoring dashboards for anomalies.<\/li>\n<\/ul>\n

                Pipeline Tooling<\/h3>\n

                Most SAP Commerce teams use one of:<\/p>\n

                  \n
                • Jenkins<\/strong> – widely used in enterprise SAP environments, highly configurable, requires maintenance.<\/li>\n
                • GitLab CI<\/strong> – good integration with GitLab repositories, YAML-based pipeline configuration.<\/li>\n
                • Azure DevOps<\/strong> – natural fit if your CCv2 subscription uses Azure infrastructure.<\/li>\n
                • GitHub Actions<\/strong> – increasingly popular, good for teams already on GitHub.<\/li>\n<\/ul>\n

                  The choice of CI tool matters less than the pipeline design. Any of these tools can implement the stages described above.<\/p>\n

                  [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Automated Testing Layers” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

                  Testing SAP Commerce applications effectively requires a layered approach, because different types of problems are caught at different levels.<\/p>\n

                  Unit Tests<\/h3>\n

                  Unit tests for SAP Commerce code should follow standard Java unit testing practices:<\/p>\n

                    \n
                  • Mock dependencies using Mockito or similar frameworks.<\/li>\n
                  • Test service-layer classes, populators, converters, strategies, and interceptors in isolation.<\/li>\n
                  • Focus on business logic, edge cases, and error handling.<\/li>\n
                  • Aim for fast execution (the full unit test suite should run in under 5 minutes).<\/li>\n<\/ul>\n

                    The SAP Commerce-specific challenge: much of the business logic lives in services that depend on ModelService<\/code>, FlexibleSearchService<\/code>, and other platform services. Use constructor injection (not field injection with @Resource<\/code>) to make these dependencies mockable.<\/p>\n

                    Integration Tests<\/h3>\n

                    SAP Commerce integration tests run within the platform’s Spring context and can access the type system, database, and platform services. They are essential for testing:<\/p>\n

                      \n
                    • Flexible Search queries<\/strong> – verify that custom queries return correct results with realistic data.<\/li>\n
                    • Interceptors<\/strong> – validate, prepare, and remove interceptors that fire on model lifecycle events.<\/li>\n
                    • Type system behavior<\/strong> – verify that custom types, relations, and enums behave as expected.<\/li>\n
                    • ImpEx imports<\/strong> – verify that ImpEx scripts execute without errors.<\/li>\n<\/ul>\n

                      Integration tests are slower than unit tests (they require platform bootstrap) but catch a class of bugs that unit tests cannot: Flexible Search syntax errors, missing Spring bean definitions, and type system misconfigurations.<\/p>\n

                      API Tests<\/h3>\n

                      For headless projects, API testing is critical. We have had excellent results using the Karate framework for SAP Commerce OCC API testing. Karate’s advantages for this use case:<\/p>\n

                        \n
                      • Readable syntax<\/strong> – non-developers (QA, business analysts) can understand and contribute to test scenarios.<\/li>\n
                      • Built-in assertions<\/strong> – JSON path matching, schema validation, and response code assertions without boilerplate.<\/li>\n
                      • Data-driven testing<\/strong> – parameterize tests with different products, customers, and scenarios.<\/li>\n
                      • Performance testing<\/strong> – Karate’s Gatling integration allows reusing functional tests as performance tests.<\/li>\n<\/ul>\n

                        Write API tests for every custom OCC endpoint and for critical standard flows (product search, cart operations, checkout). These tests serve double duty as regression tests and API documentation.<\/p>\n

                        UI Tests<\/h3>\n

                        For projects using Composable Storefront, end-to-end UI tests using Cypress or Playwright verify the full stack. Keep these tests focused on critical paths:<\/p>\n

                          \n
                        • Search and navigation<\/li>\n
                        • Product detail page rendering<\/li>\n
                        • Add to cart and cart management<\/li>\n
                        • Checkout flow (guest and registered)<\/li>\n
                        • Account management (login, registration, order history)<\/li>\n<\/ul>\n

                          UI tests are inherently slower and more brittle than lower-level tests. Maintain a small, focused suite rather than attempting to cover every page.<\/p>\n

                          [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Environment Management in CCv2″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

                          Environment Topology<\/h3>\n

                          A standard CCv2 subscription includes:<\/p>\n

                            \n
                          • Development (d1)<\/strong> – lower resources, used for development team testing. Automatically deployed from the develop<\/code> branch.<\/li>\n
                          • Staging (s1)<\/strong> – production-like resources, used for pre-release validation. Deployed from release\/*<\/code> branches.<\/li>\n
                          • Production (p1)<\/strong> – live environment. Deployed from main<\/code> after staging validation.<\/li>\n<\/ul>\n

                            Some subscriptions include additional environments. Use them for dedicated performance testing or UAT (User Acceptance Testing).<\/p>\n

                            Data Management Across Environments<\/h3>\n

                            One of the hardest CI\/CD challenges in SAP Commerce is managing data across environments. Production data drifts from staging data over time as business users create content, promotions, and catalog changes.<\/p>\n

                            Strategies:<\/p>\n

                              \n
                            • Regular data refreshes<\/strong> – periodically copy production data to staging. CCv2 provides data backup and restore capabilities. This ensures staging reflects real-world data volumes and content.<\/li>\n
                            • Idempotent ImpEx<\/strong> – write ImpEx scripts that can be run multiple times without error. Use UPDATE<\/code> with [unique=true]<\/code> rather than INSERT<\/code>. Use INSERT_UPDATE<\/code> when appropriate.<\/li>\n
                            • Environment-specific properties<\/strong> – use manifest.json<\/code> property overrides or environment-specific property files for configuration that differs between environments (API endpoints, feature flags, integration credentials).<\/li>\n<\/ul>\n

                              [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Deployment Strategies” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

                              Standard CCv2 Deployment<\/h3>\n

                              CCv2 deployments follow a rolling update pattern:<\/p>\n

                                \n
                              1. New pods are started with the new build.<\/li>\n
                              2. Health checks verify the new pods are ready.<\/li>\n
                              3. Traffic is gradually shifted to new pods.<\/li>\n
                              4. Old pods are terminated.<\/li>\n<\/ol>\n

                                During deployment, both old and new versions handle traffic simultaneously for a brief period. Ensure your code handles this gracefully: database schema changes must be backward-compatible with the previous code version.<\/p>\n

                                Database Migrations and System Update<\/h3>\n

                                The ant updatesystem<\/code> step (which applies type system changes to the database) runs during deployment. This is a critical phase:<\/p>\n

                                  \n
                                • Schema changes are applied<\/strong> (new tables, new columns, altered columns).<\/li>\n
                                • Essential data and project data ImpEx scripts<\/strong> run.<\/li>\n
                                • Content and sample data<\/strong> may run depending on configuration.<\/li>\n<\/ul>\n

                                  For large databases, type system changes can take significant time. Adding an index to a table with millions of rows may lock the table for minutes. Plan these changes carefully and communicate expected deployment duration to stakeholders.<\/p>\n

                                  Hotfix Procedures<\/h3>\n

                                  When production issues require an urgent fix:<\/p>\n

                                    \n
                                  1. Create a hotfix\/*<\/code> branch from main<\/code>.<\/li>\n
                                  2. Implement and test the fix.<\/li>\n
                                  3. Run the CI pipeline (abbreviated if time-critical, but never skip automated tests entirely).<\/li>\n
                                  4. Trigger a CCv2 build and deploy to staging for verification.<\/li>\n
                                  5. Deploy to production.<\/li>\n
                                  6. Merge the hotfix branch back to both main<\/code> and develop<\/code>.<\/li>\n<\/ol>\n

                                    Define the hotfix process before you need it. A documented, rehearsed procedure avoids panic-driven mistakes.<\/p>\n

                                    [\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”ImpEx Management in CI\/CD” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n

                                    ImpEx files are a major source of deployment failures. Establishing conventions around ImpEx management prevents many issues.<\/p>\n

                                    Categorization<\/h3>\n

                                    Organize ImpEx files by their purpose and execution context:<\/p>\n