Skip to main content

Get Started With Build Tools

Learning Objectives

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

  • List the tools available to set up the Salesforce B2C Commerce application build process.
  • Explain the benefits of various version control systems.
  • Explain B2C Commerce versioning methods.
  • Describe Git branching strategies.
  • Explain how tagging works in the Salesforce Reference Architecture (SFRA) repository.

The Build Phase

As a B2C Commerce technical architect, your overall goal is to design a high-performing site that scales with well-designed integrations. Throughout the implementation process, it’s important that you use project management best practices to manage the site development lifecycle. In this module you explore the build phase, which includes the application build, test, and deployment processes.

In the build phase, you build an application, and then test and deploy it.

You must have a code repository where developers store the code and data as they develop the application. Developers often share code and data, and need a way to check out and merge them when they are ready to test.

You must develop a build process, which must be standardized so that multiple people can run it from the repository. 

Let’s take a deeper look at the processes and tools to consider when creating your plan.

Version Control System (VCS)

The term version control broadly includes any system that helps people keep track of multiple versions of something. In the software development world, it typically describes software tools such as Git. While Git is the distributed version control system of choice for B2C Commerce software development, your merchant might use something else.

Each VCS has pros and cons, but all of them can be categorized as either centralized or distributed.

  • Centralized: Works on a client-server model. There’s a single (centralized) copy of the code base, with the pieces of the code that are under development typically locked (or checked out). Only one developer is allowed to work on that part of the code at a time. The server controls access to the code base and the locking mechanism. When the developer checks their code back in, the server releases the lock, making the code available for others to check out.With centralized version control, developers can commit and update code that only they can work on.
  • Distributed: Works on a peer-to-peer model. The code base is distributed among individual developer computers. The entire history of the code is mirrored on each system.With distributed version control, each developer has a working copy of the entire repo, from which they create a branch that’s their working copy.

Git is one of many distributed version control systems available, but it’s probably the most widely used. Git is essential for using GitHub, the most popular public website and platform for hosting and sharing projects. It’s a hub for projects that use Git version control. (That’s why it’s called GitHub!) If you’re on GitHub, you can access all kinds of B2C Commerce-related repositories, such as the Salesforce Commerce Cloud Command Line Interface (CLI) (login credentials required).

Versioning Methods: Ensure the Right Balance

Versioning means that after you add or update code, you end up with a code set that’s identifiable by a version number. Having lots of versions isn’t a good idea. Storefront merchants don’t want to see site disruptions caused by lots of updates. You need to recommend the right balance for your versioning approach. Here are some approaches to consider.

Divide and Conquer

The divide and conquer method means that not all assets have to be part of the same repository. In addition to code, the implementation has other data that’s often stored in a separate repository, including:

  • Deployment and testing processes
  • Test data
  • Configuration and production data

For example, the repository can be asset based, where code and test data require a different repository than configuration and production data.

Make sure you control who can do what on the version control system. For example, for merchants and other contributors who need limited or no access to code repositories, restrict access to certain repositories. Multiple repositories also mean different responsibilities and release cycles. It’s important to get into the details on this to make sure subsystems or teams have compatible process and permission requirements.

As Little as Possible/As Much as Necessary

Another method is to version as little as possible and as much as necessary to support the entire development and test approach. Should you version test scripts, test data, and compiled distribution code or just the source code? What about the documentation and manuals?

Avoid versioning sensitive data, such as clear text passwords for repositories and code, because they can be shared with others, creating security risks. For B2C Commerce, you can store encrypted service credentials because they can only be decrypted on the client’s realm; the private key is point of delivery (POD) specific.

Note

A B2C Commerce POD is a group of compute, storage, and network resources that conform to a standard operating footprint (usually made up of multiple equipment racks or cabinets).

For other Salesforce products, like multi-cloud projects, use other methods to secure secrets. For example, most CI/CD tools use secret managers to inject secrets into data definitions during the build process.

Your merchant might have other criteria for a separate repository. It’s up to you to find out.

Set Up a Build Process

Most systems integrators and technical architects have a preferred set of build tools. There are some common features to consider, such as the ability to run console commands and use npm modules. This lets you use SGMF scripts to set up continuous integration and delivery.

Check out these tools for the B2C Commerce build environment.

Tool

Purpose

Details

SFRA repositories on GitHub

Repository

Contains Storefront Reference Architecture (SFRA) and other B2C Commerce applications.

Visual Studio (VS) Code

Integrated Development Environment (IDE)

Use with these:

  • Prophet Debugger extension
  • ESLint extension

IntelliJ IDEA

IDE

Includes two plugins that allow a comprehensive B2C Commerce experience.

UX Studio

IDE

Required to handle pipelines, such as with SiteGenesis-based applications.

SGMF Scripts

Code tools

Use this to create overlay cartridges, with the following features.

  • JS, SCSS, and CSS instrumentation
  • Upload cartridges
  • Execute unit and integration tests
  • Linting
  • Instant upload/watching for local file changes

Dwupload

Code deployment

Upload to Business Manager.

Replication

Code deployment

Transfer code from instance to instance.

Define a Git Branching Strategy

There are several branching strategies you can choose from. Not every branching strategy fits all projects. Here are two of them.

Strategy

Approach

Details

Gitflow

Comprehensive: for complex project setups and bigger team

  • Main branches: main, develop
  • Supporting branches: feature, release, hotfix

GitHub Flow

Simplified: for smaller or agile projects

  • The main branch: main (always deployable)
  • Feature branches should be descriptive

The Gitflow strategy supports multiple developers, and offers comprehensive branching, tagging, and release management. Git branches enable multiple developers to work simultaneously on their own copy of the repo, and then merge their work back in when they are ready. 

Git supports forking, the ability to create a server-side clone of a repository. That means you create a copy of the project’s current code base and use it as the basis for a separate, alternative project (or use the fork to contribute to the original project). 

Pull requests are how you check source code changes into a branch. When you open a pull request, you can see and collaborate on the code changes before the pull.

SFRA Versions and Releases

Semantic versioning uses the major.minor.patch standard for version numbers, for example, 100.23.07. This type of format is best practice. 

The SFRA product repositories on GitHub use semantic versioning with this format.

v<major_version>.<minor_version>.<patch_version>

For example: v3.3.0

Here’s what the version numbers mean.

Version number

Represents

major_version

A version that is not backward-compatible with previous versions.

minor_version

A version with new functionality and features that is backward-compatible within the major version.

patch_version

Bug fixes or patches that are backwards-compatible within each minor version

The SFRA base repository (storefront-reference-architecture) is continually updated. Each incremental update corresponds to a new version, but only some versions correspond to actual releases.

Git Tags in SFRA Repositories

Git tags are references that point to specific points in Git history. Developers use tagging to capture the point in history of a marked version release (for example, v1.0.1). A tag is like a branch that doesn't change. Unlike branches, tags have no further history of commits after they’re created. 

SFRA versions have matching Git tags. For example, SFRA version v3.3.0 corresponds to the Git tag v3.3.0. SFRA repositories are tagged separately but follow the same pattern. After cloning the SFRA repositories, you can fetch the tags for each repository, list the tags, and check out the same version tag for each repository to ensure you are using the same version everywhere. While Salesforce updates SFRA repositories on GitHub, only some of the updates correspond to a release.

The Build Process

Here’s a checklist of what steps are involved in a typical B2C Commerce build process.


Task

1

Download SFRA to the local machine. (Salesforce recommends that you do not modify SFRA core.)

2

Create custom cartridges locally.

3

Upload new code to the repo (such as via pull request in Git).

4

Upload new code to the B2C Commerce server.

5

Configure the cartridge stack load order in Business Manager.

You can find detailed instructions in these Trailhead modules.

Next Steps

In this unit, you explored the tools available for a B2C Commerce application build process. You took a look at version control systems and other build process methodologies. Next, learn how to automate testing. 

Resources

Keep learning for
free!
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities