Learn the Basics of Release Management

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.

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

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.

Note

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.

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.