Best Practices: Continuous Integration

What Is Continuous Integration?

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. CI is used in combination with automated unit tests written following the practices of Test-Driven Development in order to improve software development quality.

In addition to automated unit tests, organizations that develop according to CI principles typically use a build server to implement continuous Quality Control processes. In addition to running unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code, and make manual quality control processes easier.

The continuous application of quality control methods throughout the development process aims to improve the software Quality and delivery times. By replacing the traditional practice of applying quality control after completing all development with the more modern practice of CI, teams can detect problems sooner, allowing easier troubleshooting, less rework, and a more nimble development process.

It's important to understand what Continuous Integration is and how it relates to other state-of-the-art development concepts, such as Continuous Delivery and Continuous Deployment.

Continuous Delivery

Continuous Delivery (CD) is a development practice that produces software in short cycles, ensuring that the software can be reliably released at any time. It involves building, testing, and releasing software faster and more frequently.

Continuous Deployment

Continuous Deployment can be thought of as an extension of Continuous Delivery, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in a Production instance.

To achieve Continuous Deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that when each code integration successfully meets the release criteria, the live application is updated with new code.

In practice, the big difference in these approaches is the automation of acceptance tests instead of expecting manual acceptance with human intervention. In order for Continuous Deployment to be effective, the percentage of test coverage needs to be very close to 100%. As soon as a release passes all tests it is then automatically deployed into a Production instance.

It is considered a good practice to perform acceptance testing in a sandbox or development instance, where all most up to date content and catalog information is present, before releasing a new version into a Production environment.

Choosing the Appropriate Development Methodology

In order to achieve a continuous integration and delivery process, different development methodologies must be used. The methodology you want to use determines whether you adopt CI or CD.

The act of continuously integrating software, testing and deploying it, is a natural fit to the concept of iterative development. If your organization implements a waterfall model for project delivery, with a separate build and testing phase, Continuous Delivery is not appropriate. Continuous Integration can still be used, although it is not required. Iterative development, through agile methods like Extreme Programming, actually demand some form of Continuous Integration and Continuous Delivery due to the short cycle nature of the development and integrated testing phases that usually happen on a daily basis.

What Should I Use?

Development Methodology Development Practice
Waterfall Continuous Integration
Agile Continuous Delivery

Continuous Integration in Salesforce B2C Commerce

Continuous Integration in B2C Commerce is a simple process.

The build process in a Continuous Integration environment is divided into several stages and can be triggered either automatically or manually by a build engineer or developer:

  1. Check in changes into a Version Control System (VCS)using a source code approval workflow.
  2. Checkout from VCS and get all source projects from a specific code version.
  3. Execute project build.
  4. Execute unit tests.
  5. Execute static code analysis.
  6. Notify team about build output.

Overview of Development and B2C Commerce CI Environment

The developer environment is defined as a Sandbox with an IDE and a server connection. This might be Commerce Cloud UX Studio or similar Commerce Cloud compatible IDEs running on a development host. The developer checks out source projects from the VCS, uploads and tests new code versions, and pushes the changes to the VCS.

The CI environment might be configured to automatically trigger a build process on a build server like Jenkins, Bamboo, or TeamCity. When built, the code version is uploaded to the Continuous Integration sandbox. As the final step, the build process communicates with a CI instance to run integration and acceptance tests. This CI instance is usually used as the demo environment during the build phase.

Preparing for Continuous Integration

The Commerce Cloud reference application "SiteGenesis" is built natively to support a continuous integration process. It provides tools to build, analyze, and test the code base.

During site implementation, each developer manages the sandbox and development host they are using to customize the platform. Each developer is therefore responsible for building, analyzing, and testing the modifications in order to push code into the VCS.

Consult the SiteGenesis Readme for more information. Inside the test folder, study the Readme file to understand more about the testing strategy.

SiteGenesis Continuous Integration: Use Case and Configuration

In this example, Bitbucketis being used as an example of a VCS.

VCS Setup

This section describes how to set up Continuous Integration using SiteGenesis as a reference application, similar to what you would do in a custom implementation project.

Step Description
1 Clone SiteGenesis repository
2 Create a local repository, with git clone
3 Install npm with npm install
4 Create a new remote repository

Add SiteGenesis local repository to new repository with:

git remote rm origin

git remote add origin

When a source control system is in place, development can start. The following table describes very briefly the number of steps performed inside the developer environment until the code is ready to be used by the Continuous Integration Server.

Step Description Command
1 Create branch for individual task git branch -b feature
2 Implement customizations + unit tests  
3 Execute local build

_ npm run compile:scss - Compiles all .scss files into CSS.

_ npm run compile:js - Compiles all .js files and aggregates them.

_ npm run compile:fonts - Copies all needed font files. Usually, this only has to be run once.

4 Execute code analysis npm run lint
5 Execute unit testing npm run test
6 Perform local commit git commit -m "message"
7 Perform pull request  
8 Reviewer approves code  

When the code is ready to be built, the Continuous Integration server executes a number of steps until the code is active in the respective CI sandbox.

Achieving Continuous Delivery

The key aspect to achieving Continuous Delivery is the introduction of a Continuous Integration Server that uses most of the Commerce Cloud Community Build Suite capabilities to be able to test, build and deploy the software. The Commerce Cloud Community Build Suite is available on GitHub as part of the Commerce Cloud private project.

B2C Commerce doesn't recommend any particular build server, but be aware that the Build Suite requires Grunt to execute, which means the Continuous Integration server needs to support Node, Grunt, and Mocha. Standard build servers, such as Jenkins or Bamboo, support the Commerce Cloud Community Build Suite.

A typical set of steps to achieve a Continuous Delivery process using SiteGenesis is as follows:

Step Tools Description
1 - VCS Download:

CS Build Suite

Native Build Server Connector

Build Suite / native connector download all source code from repository

Build Suite / native connector downloads all CI metadata from data repository

2 - Unit Tests SiteGenesis Scripts

SiteGenesis unit test framework is based on Mocha test framework and provides comprehensive support for unit testing

Command : npm run test

3 - Static Code Analysis SiteGenesis Scripts

Linting your code

npm run lint / gulp lint

Execute linting for all JavaScript and SCSS files in the project. You should run this command even before committing your code.

4 - Build CS Build Suite

Build Suite builds the JavaScript and CSS (minify, browserify, and other build functions) using Grunt or Gulp

Zips the build into new code version

Zips the site configurations and metadata as new file

5 - Upload CS Build Suite

Build Suite uploads code to CI Sandbox via WebDAV, then unzips the new code version

Build Suite imports all CI metadata files into Webdav

6 - Configure Sandbox CS Build Suite

Build Suite logs in into Business Manager, goes into code deployment and activates the latest code version

Build Suite uses Site import to import all metadata files

7 - Integration Tests SiteGenesis Scripts

SiteGenesis integration test suite, based on the Mocha test framework, was developed so one can easily use this framework to deliver complex integration testing. New integration tests can be added and functional test suites can be expanded.

Command : npm run test:integration -- --baseUrl https://hostname/on/ test/integration/*

8 - Functional UI Tests SiteGenesis Scripts

SiteGenesis functional test suite performs headless and browser-based functional testing, based on WebdriverIO (Selenium 2.0)

Command : npm run test:functional -- --url --chrome

9 (optional) Fitness Used if hooks are developed to customize Open Commerce APIs

Metadata Deployment

While Continuous Integration is a relatively simple process, when discussing only code deployment. However, it's also important to understand how the data is managed in a CI environment. A good practice is to follow the SiteGenesis repository structure and host the entire metadata configuration inside a "demo_data_no_hires_images" folder. This folder should contain a cut down version of the full catalog, as well as all necessary custom attributes and configurations that support customization.

By including and effectively managing code and metadata in a source code repository, one can easily include them in the build process. The Build Suite has an importSite goal to import the metadata to the Sandbox Continuous Integration WebDAV folder and perform a site import automatically.

B2C Commerce Build Suite

The Build Suite is an easy-to-use set of scripts to automate your build processes, developed by B2C Commerce architects. It's licensed under the current NDA and licensing agreement in place with your organization. (This is explicitly not open source licensing.) A full list of features and release notes can be viewed here:

The Build Suite is powered by Grunt (together with NodeJS v4.4.x or newer) - a popular and well-tested JavaScript task runner.

CI Workflow

UAT & Production

During the User Acceptance Testing (UAT) phase, it becomes necessary to manage different code versions and deploy them independently in both the CI environment Sandbox instance and Staging, so the code can be properly replicated and tested in Development and Production. The easiest way to achieve this is by branching your code and performing separate builds for the different environments, checking out the appropriate branch for each one.

During UAT and after you go into code freeze, it is necessary to maintain at least the following branches:
  • RC (release candidate): contains the code version that will be going live.

  • Develop: contains the most up-to-date code version, which is updated every day with RC fixes and new functionality that might be deployed after go live.

When the production release is ready, it's also best practice to create a production branch out of the Release Candidate, and have this branch deployed into Staging and replicated into Production and Development.

Managing the code version is an easy task and you should use your CI Server of choice to download the appropriate code versions and deploy the version in the correct environment.


Depending on the specific project requirements and the needs of your organization, you might decide to introduce some elements of CI and CD but not all. For example you might chose not to use Unit Tests or Functional tests if you want to use manual testing.

Continuous Integration is a very important topic that can improve the overall project quality and customer satisfaction and so it should be taken seriously. We provide several pre-built tasks in the Build Suite, but these can be customized or complemented by your own, in order to meet your needs.

Commerce Cloud is continuously improving its capabilities to support CI and CD. Over the years, SiteGenesis and the Build Suite were developed to meet most of clients' needs for CI and CD. In the future we plan to improve our strategy with better control over Sandbox initialization and easier tools for building and testing.

HTML Cheatsheet collects the most common tools for web editors on a single page. Use it every time you are composing HTML markup code.

X Privacy Update: We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used. By continuing to use this site you are giving us your consent to do this. Privacy Policy.