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.

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.
  
• 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.
  

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.

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.

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.

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.

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.

You can find detailed instructions in these Trailhead modules.

• Tools & Resources for Salesforce B2C Commerce Developers
  
• Salesforce B2C Commerce Cartridges
  

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

• Trailhead: Git and GitHub Basics
• Trailhead: Project Documentation for Salesforce B2C Commerce Technical Architects
• Trailhead: Tools & Resources for Salesforce B2C Commerce Developers
• Trailhead: Salesforce B2C Commerce Cartridges
• Salesforce Help: SFRA