Manage Changes in Increasingly Complex Releases

This unit describes why Calvin and his colleagues move to developing with code and a version control system. As you read through this unit, consider which choices you would make for your team. Get hands-on by working through the modules listed at the end of this module to learn the process and make the most informed decision about what will work for you.

Zephyrus has one great quarter after another. Salesforce is now being used in other parts of the business, not just in Sales. After consulting with Calvin and leaders from the Customer Service department, the COO agrees to move to Enterprise Edition and buy Service Cloud Lightning. With Service Cloud Lightning, the company can deliver instantaneous and personalized support to their customers. Even better, the Customer Service department has some team members with coding skills to develop Salesforce apps for their team’s needs.

It’s clear to Calvin that the org’s complexity is growing beyond what the team can manage with the change set development process. The company now needs a more rigorous change management process and an audit process (think version control system) to help them manage so many work streams.

The team is also running up against the limitations of what they can do using change sets. For example, they can add but not delete fields (destructive changes).

In a presentation to his director and the CEO of Zephyrus, Calvin proposes they move to the org development model.

As with the change set process, the release artifact they’re creating is a set of metadata changes relative to their production org. In the org development model, however, the team can get a major change management improvement by externalizing the changes they’re making. They can use the Salesforce Command Line Interface (CLI) to extract metadata from a development environment to integrate with a version control system (VCS).

They can also use the Salesforce CLI to script routine tasks and boost the productivity of everyone contributing to the release. Calvin’s suggestion that they start by creating scripts to run test deployments and run Apex tests makes good sense to his director and the CEO.

Thanks to Calvin’s business-driven arguments, his director and the CEO approve the move to org development. In recognition of his contribution to company success, Calvin is promoted to business analyst. The promotion also gives Calvin the scope he needs to manage releases across departments.

Calvin and two customer service team members each work on a different project with separate development environments. The three projects are all scheduled for the same release. As they move through the org development process, they notice some familiar aspects and some things that are different from the change set process.

Just like they do in change set development, all three team members track the changes they’re making. Why? The team needs to know which components change, whether they add those components to a change set or retrieve them with the Salesforce CLI. Also, some of their customizations can’t be deployed to another org, because they include changed components that aren’t represented in Metadata API. Such changes have to be re-created manually on the target org, so it’s still important to keep track of them.

When the team members complete their respective development assignments, their next step is to move their changes to the build environment for integration. But now they use the Salesforce CLI to retrieve the changes from their respective development environments instead of using declarative tools to create a change set. They integrate their work with a VCS, so the changes that team members retrieve can be committed and tracked in the VCS.

Committing and tracking retrieved changes in the VCS provides a key benefit to the team. When using the change set process, team members can (and sometimes did) accidentally overwrite someone else’s changes by deploying a change set right over the previous change set. By using the new process of committing changes to the VCS, customization conflicts can be identified before a change gets overwritten.

Going into the build step, the customizations from the team are already integrated into the project in source control. From the VCS, these changes are deployed together to the build environment for integration and testing. Just like in the change set process, the changes are tested together in the build environment. And just like before, the result is a single release artifact that is effectively one big consolidated set of changes. But Calvin now uses the Salesforce CLI to retrieve the artifact from the build environment. And as the org development process goes on, the release artifact keeps moving from the VCS onward to the next environment.

Though they use additional tools in the org development process, the basic ALM steps, the change set concept, and the environments for development and testing are the same. Everyone working on the first release under the new development model has at least some familiar points of reference. Also, Calvin is excited to use Trailhead and resources on the Salesforce Developers website to grow his technical skills and knowledge.

The move to the org development model helps give Zephyrus the control and the efficiency they need to expand their use of Salesforce throughout the company.