Prepare for Deployment

Learning Objectives

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

Describe creating a branch.
Summarize steps for committing components and tying a user story to a branch.
List the benefits of making a request for peer code review.
Explain merging branches.
Identify how Overwrite Protection helps users detect and resolve code conflicts.

Creating a Branch

In Flosum, a branch is an independent line of development that allows developers and Salesforce administrators to work in parallel with other team members while keeping their changes separate from the rest of the team’s changes.

A branch is a separate part of—but connected to—a developer’s repository. A repository can contain multiple branches, and these branches can be merged into the repository when necessary.

Flosum supports many types of branches, including:

Feature branches: A feature branch consists of a user story containing each of the features being developed for that user story. (One feature per feature branch is recommended.)
Release branches: After the feature branches move through quality assurance (QA), they are merged into a release branch. A release branch will hold the various feature branches until they’re ready to be pushed to production.

Committing Components and Tying a User Story to a Branch

After a developer has created a branch and tied a user story to the branch, they can modify the components in a development sandbox and add those components to a particular branch.

Flosum automatically detects the components that have been changed in the development sandbox and shows the details of each component, when it was changed, who changed it, the component type, and the component’s name.

Users have the option to filter and select components by type and to search components by name. (Flosum supports all component types that Salesforce supports, whether it’s metadata API or tooling API.)

At this point in the flow, Flosum will run a code quality scan. Read more about this process here.

Once a developer is assigned a user story, they can tie it to a branch in Flosum using Jira, ServiceNow, Azure DevOps, or another application lifecycle management (ALM) tool. For example, the user could search for a Jira ticket within the branch and append it to the branch.

Making a Request for Peer Code Review

When a developer submits a request, they’re asking that one or more of their team members complete a code review of a branch.

Developers should ask for a code review before merging into shared branches, deploying to an org, or committing code to a repository. Making requests for peer code review:

Increases communication among team members who are working on shared components.
Informs team members about changes that have occurred.
Results in higher quality deployments.

Merging Branches

The next step is merging the various user stories or branches that each developer is working on into a release branch. When a user merges branches, Flosum will show the conflicts between both branches or user stories that the user is choosing to merge. The user is then able to resolve the conflicts.

Using Overwrite Protection

With the Overwrite Protection feature (formerly known as “Impact Analysis”), users can compare their deployments and their target orgs to detect and resolve code conflicts. The main purpose of this feature is to prevent any changes on the org from being overwritten unintentionally.

Users can complete these predeployment operations efficiently through Flosum platform’s seamless integration with Salesforce. Now we’re ready to dive into deployment. You’ll learn all about it in the next unit.

Procurando ajuda?