Learn the Basics of Release Management

Learning Objectives

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

  • Identify the three release categories and the kinds of changes that go in each category.
  • Describe a change set.
  • Explain why it’s important to track changes and dependencies for change set releases.

In this unit, Calvin and his colleagues begin applying the ALM process. As you read, consider the choices you’d make for your team. Then work through the modules listed at the end of this module to get familiar with the process so you can decide what works for you.

Create a Release Management Process

The Zephyrus team adapts their customization practices to the best-practice ALM steps. The process takes a little getting used to, but their efforts are worth it. They see an increase in their development velocity and a decrease in Sales team disruptions. That’s enough to win over the team, and management is delighted.

By implementing the ALM cycle, Zephyrus has adopted a basic release management process. But the team has both large and small projects in progress, all at different steps in the ALM cycle. To help keep projects and expectations under control, Calvin adds more structure by setting up a release schedule and defining criteria for releases of different sizes.

Releases typically fall into one of three categories.

Bug fixes and simple changes. Simple changes include reports, dashboards, list views, and email templates.
Changes with limited impact, such as a new workflow rule or trigger impacting a single business process. These releases typically require testing, but only limited training and change management. Typically, a team delivers the changes for a minor release within a few weeks.
Changes with significant impact, including changes with one or more dependencies. Because these releases can greatly affect the user experience and data quality, they require thorough testing, training, and careful change management. Major releases are typically delivered once a quarter (Salesforce does it three times a year).

Release on a consistent schedule. Aim to release at regular intervals and on a given day of the week. For example, maybe minor releases occur at 8 PM eastern time on the first Tuesday of every month. Scheduling consistency helps with company-wide planning and sets expectations with your business users. One more thing: Try not to release near holidays or other major events.

Track a Set of Changes All the Way to Production

As they move through the ALM steps, the team at Zephyrus uses the change set development model. They use the Setup UI to create changes in a development environment, and migrate these changes between environments as they work through the ALM steps.

In change set development, the team’s release artifact is a set of metadata changes, like a diff or delta, relative to what’s in the production org. What gets released is only metadata that has been added or changed—if it doesn’t change, it’s not in the release.

  • Each developer tracks any changes made in their customization for the release. The tracking tool can be anything from a spreadsheet to a work tracking system.
  • Certain changed components may not be available in Metadata API yet, and have to be migrated manually between environments. If you track these changes, you won’t forget to migrate them.
  • As the release manager, Calvin works to discover and include dependent components in the release. For example, it’s impossible to migrate a new custom field to the next environment if the custom object it belongs to doesn’t exist in the target org. The change set tool helps Calvin identify these dependencies.

Component Dependencies page, listing dependencies by name and what references them.



Migrating profiles and permission sets can be tricky. Review the special considerations for deploying and retrieving profiles and permission sets before proceeding.

Tracking the changes in each release takes work, but if you keep your books, you’ll have a smooth rollout when you release to production.

All Together Now!

Your release can contain multiple projects, and each project can be developed and tested in separate environments. But before the build step, you migrate all of the changes from every project to the same environment for integration. From this point onward, your changes and customizations in a release travel together as a single integrated change set, headed for production. In the test release step that follows build, you test all the changes together.

As release manager, Calvin tracks changes from all his release contributors. He also tracks any changes made in production that aren’t reflected yet in the development and test environments. Why? It’s the only way they can deploy customizations successfully, without inadvertently overwriting changes on the production org.