Metadata deployment technologies allow Salesforce administrators and developers to move customizations between orgs. There are some important problems that can be solved with metadata deployment, including org splits and merges, technical debt reduction, release management, and application development. But there is no universal deployment technology that handles every situation in the most effective manner. This paper discusses the best use cases for both administrative and DevOps deployment technologies.
Org Splits and Merges
Conducting org splits, clones, reboots, and merges is one of the most difficult tasks that an administrator or developer can tackle on the Salesforce platform. First, you will need the ability to move all 220 metadata types between orgs. This is inherently difficult because of all the dependencies between metadata types. Next, you must migrate data. This process is also fraught with constraints and special cases. The old standard objects used by the underlying platform are often more difficult to move than new custom objects.
A complex org split or merge can require hundreds or even thousands of deployments and migrations. Powerful metadata deployment tools are needed to hammer the destination org into the desired shape. You need the ability to quickly deploy different combinations of metadata assets to overcome dependencies and constraints. Our Snapshot product specializes in this style of rapid freeform deployment with all 220 metadata types. We also have capabilities to document the org, remove technical debt, and compare org differences.
An org split or merge is a strategic transition for the companies involved. This is a special case deployment scenario where only the final results matter. Trying to conduct an org split or merge with DevOps tools is very painful. Merging XML in the Git repository to create a promotion branch requires additional time and effort for each deployment. There is usually no need to perform any kind of code merge. The individual contributions to each deployment don’t need to be tracked. All this user tracking and XML merging requires extra steps and slows the entire process down.
Technical Debt Removal
Technical debt removal almost always requires the investigation of data records, not just metadata assets. In reality, there is not any kind of clear line between where the Metadata API ends and the Data API begins. Many assets are both data and metadata, and in other cases the Metadata API has coverage gaps. Here are some examples of this:
- The Metadata API covers about 250 out of over 1000 available standard objects
- There are many standard fields missing from the Metadata API object subset
- Field and Picklist Usage requires statistical analysis of data values
- Permission Management requires junction data between users and permissions
- Activity Dates for Dashboards and Reports are only available as data
- Licensing Information for Packages, Permission Sets, etc. are data records
- Complete Information for Roles, Groups, and Sharing is only available as data
Because of these limitations, DevOps deployment technologies are not very useful for optimization and cleanup operations. The only way to see everything is by leveraging both the data and metadata in a live org. With DevOps tooling the “source of truth” is a Git repository with metadata documents. There is no access to the data records and all the other important information needed for optimization and cleanup.
Our Snapshot has a complete suite of tools for technical debt reduction. These applications use the Data, Tooling, and Metadata APIs in parallel for a complete picture of the org. Our Smart Deploy technology can remove assets that need to be deprecated right from the reporting interface. This is a great example of using deployment technology in a completely different way for administrative deployments.
Application Development
Git was designed by Linus Torvalds to manage code submissions to the Linux kernel. As you might imagine, Git is not particularly easy to understand or use. Git is purpose built for code merge. If you are a programmer working on a team, or even a single programmer trying to keep track of changes, then merging code and understanding where the contributions are coming from is an important problem to solve. This is the primary focus of DevOps deployment technologies: coordinating a group of developers and managing their contributions to Apex Classes in the context of application development.
Git has some shortcomings that should be mentioned. Git is not good at merging XML and knows nothing about the special structure of Salesforce metadata documents. Git is not great with large files either. For example, uploading gigantic Profile documents to Git is problematic. Lastly, just because you put some XML in a repo does not mean that it can actually be deployed anywhere. I have never been sure why Git is called the “source of truth.” The only container guaranteed to hold valid metadata is a Salesforce org.
All that being said, DevOps deployment technologies are purpose built for helping teams of developers build Salesforce applications and implement platform customizations. The combination of package development and Salesforce DX projects is a sweet spot for DevOps deployment technology. Salesforce’s new DevOps Center product looks like a good start for DevOps teams that need code merge with deployment.
Release Management
Application developers tends to focus on a handful of metadata types. The usual suspects include Apex Classes and Pages, and Custom Objects, Tabs, Metadata, and Applications. But there are over 200 other metadata types in a typical Salesforce org. These metadata types are used for managing the Salesforce platform and product line. Developers might create hundreds of Custom Objects for their applications. But there are over 1000 standard objects in a typical Salesforce org. These data objects are also used for managing the Salesforce platform and product line. Looking at these numbers, the 800-pound gorilla in the org is the Salesforce product line. DevOps is a great way for developers to extend and customize the platform. But I see DevOps as the icing on the cake. Our Snapshot product is focused on the cake. We develop tooling to manage the core platform, keep the org healthy, and support the release cycle.
Release management requires the ability to move all 220 metadata types. These types are not usually needed for application development, but rather to manage the Salesforce platform itself during the release cycle. The same requirement applies to data migration. The legacy Salesforce objects are central to platform operation and are more difficult to handle than the Custom Objects needed for application development. Because of these factors, I recommend administrative deployment capabilities for managing the release cycle and DevOps deployment tools for application and package development. But many companies use DevOps tooling for Release Management, especially when multiple administrators need to work in a coordinated fashion. The following table highlights some of the strengths and weaknesses of administrative vs. DevOps deployment technologies.
Demo Movie
This brief movie shows the Snapshot administrative deployment capabilities in action.
Conclusion
This whitepaper has discussed the different use cases for DevOps and administrative deployment technologies. The Snapshot product from Metazoa provides a best-of-breed solution for administrative deployments for data migration, freeform deployments, release management, technical debt reduction, and org splits and merges.
Congratulations! 