Explore Continuous Integration

Learning Objectives

After completing this unit, you’ll be able to:

Explain the importance of a well-defined continuous integration process.
Describe how continuous integration works with continuous delivery and continuous deployment.
Describe how B2C Commerce CI/CD development process steps relate to instance types.
Explain what to consider per instance type when designing an integration process.

Continuous Integration

In addition to testing, another important part of the build phase is integration, the process of pulling separate code into one application. Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. It’s a primary developer best practice, enabling them to merge code changes frequently into a central repository where builds and tests are then run. Developers use automated tools to make sure the new code is OK before integration.

A source code version control system makes CI possible. The version control system is supplemented with other checks, such as automated code quality tests, syntax style review tools, and more.

Development teams use CI to build and test their code, and then deliver or deploy their application to production. In this diagram, continuous integration is followed by continuous delivery or continuous deployment.

With continuous integration, development teams can implement continuous delivery or continuous deployment.

See the Develop for Salesforce B2C Commerce trail for details.

Continuous Delivery or Deployment?

The acronym CD can refer to either delivery or deployment—the difference is how the release happens.

Continuous delivery: Teams produce software in short cycles, ensuring that the software can be reliably released at any time manually to a test or production environment.
Continuous deployment: Automated testing validates if changes to a codebase are correct and stable for immediate automatic deployment to a production environment.

The way a development team develops is important for integration. Here are the typical development methodologies.

Agile is about continuous delivery. Continually plan, learn, and improve as you strive for team collaboration, evolutionary development, and early delivery. It focuses on flexible responses to change, time to value, and the economy of speed.
Waterfall breaks down project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. You can't ship code without finishing the full project lifecycle of the waterfall: Discovery, Design, Build, Test, Deploy. Such a cycle takes months.

CI/CD on B2C Commerce Instances

B2C Commerce provides four environments, called instances: sandbox, development, staging, and production. Review how instances work in the Architecture of Salesforce B2C Commerce module, and consider instance type when designing your integration processes.

The B2C Commerce CI/CD development process typically uses three steps that reflect the state of the software development process and the instance types involved.

The B2C Commerce has three steps for CI/CD integration across the sandbox, development, and staging instances. The text above each box of the diagram is a prerequisite for the actions listed on them. For example for code to reach staging, UAT & Accepted must occur. In the diagram, the text above each box is a prerequisite for the actions listed on them. For code to reach a sandbox, the code must have been pushed from the feature branch; on a development instance, the code must have been reviewed and merged, and on a staging instance, UAT and accepted must have occurred.

Sandbox

Developers work in their personal sandboxes and push a feature branch that triggers and executes the sandbox CI process. While working on features, a developer confirms that the code is working and passes all development quality gates. This approach ensures that only functional code is reviewed. In large enterprise projects where time is critical, this process saves time by limiting pull request discussions.

Sandbox instances are designed for development and not intended to be a 1:1 copy of a development or staging instance. Having 500 to 1000 products, including prices and inventory, is more than enough for development tasks. If you need other products or categories, add them using site import. For CI processes on a sandbox, a larger set of products or other data means longer build times and a longer period before a code change can be approved through test automation. Use dedicated products for individual test cases, so you have, for example, one preorder product that your test automation uses to verify the preorder functionality.

The sandbox instance comes in two flavors.

Point-of-delivery (POD) sandboxes: Part of the production hardware that’s statically provisioned
On-Demand sandboxes: Hosted in a public cloud environment and provisioned as required

B2C Commerce on-demand sandboxes are great for the CI/CD process. You can create and populate them during the CI/DC process for both integration and testing. You can create them with different sandbox profiles. The xlarge profile has enough resources to handle a production-size catalog on a production instance.

When you open a pull request, it's possible to automate the process of creating and deploying to a sandbox, running tests, and then deleting the sandbox. However, various part of this process must be done manually, such as:

Opening the pull request
Using multi-factor authentication (MFA) to create the sandbox

You can configure OCAPI settings in your provisioning request.

Whatever process you use, be consistent. Always use it testing a feature branch before it’s merged into the integration/develop branch, or a release branch before it’s merged into the main/master branch. You can easily do this with the sfcc-ci tool.

Development

Integration on a development instance is similar to integration on a sandbox. The development instance serves as the last quality gate before pushing code to staging. Developers should run a complete test suite, including functional testing, to ensure the code works as expected for integration and from an end-user perspective. In most projects, the QA engineers test on the development instance.

Automated test suites provide even more complete regression testing. As the data is synchronized with live data coming from staging, make sure your test suite can handle changes in the data set. For example, if you are testing search and want to find out if the word blue returns a result, make sure you review products in the search results for blue. Don’t just check to see if the search result count is 12 items.

Staging

Creating a meaningful CI process for staging is the most difficult part of the setup. Staging requires its own process for code and data upload. Because staging is the only way code can reach production, multi-factor authentication is in place for this instance for added security.

To release code, it must be deployed to staging where it’s replicated to production. The CI process running against the staging instance must provide one-time data uploads that don’t overwrite existing objects on the instance, such as a content library.

Don’t run tests on staging. You don’t want integration test data or code on staging to end up on production by accident. If the merchant has a good way of preventing test data (for example, test products) from being moved to production, then test on staging. If you deploy test code to staging, you might replicate it to production, causing a security risk.

Multi-factor authentication using a client certificate as the second factor is required when uploading code on staging. This adds an extra layer of security to the platform. Add multi-factor authentication to the code deployment process via SFCC-CI.

The certificate that Salesforce Customer Support provides on realm creation is used to sign individual user certificate requests. Don’t use this certificate for code uploads. Instead, create individual certificates for this purpose. Here’s how you do it.

Before running any code, create a .p12 certificate file, as described in the documentation.

SFCC-CI allows you to use the generated, user-specific .p12 file for the code upload to the Staging instance.

Important: Do not store the certificate and the password together.

Example Using a SFCC_CI Command Line to Push Code to Staging

To use the SDCC-CI CLI to deploy code to Staging. Check the example for pushing code.

Production

For the continuous delivery process, replication to production should be manual. For the continuous deployment process, replication must be automated.

Next Steps

In this unit, you learned about the importance of a well-defined continuous integration process, and how the B2C Commerce CI/CD development process relates to instance type. Next, learn how to automate and test during integration.