Salesforce DevOps Overview

If you know the basics about DevOps and CICD you can skip that.

How business logic works is described by metadata, so we would like to move and test metadata between testing environments up to Production according to industry best practices and at a fast pace.

If there are just one or two developers working and deploying the features you don’t need sophisticated CICD, Release/Deployment rules and well-documented process. The process is simple, they see each other changes in Merge/Pull requests, then grab the modified items and deploy them once they are ready.

The problem occurs when there are many developers. The more developers you have the better CICD you need to have. Things like creating and deploying either the package or components must be automated and based on Version Control System (like git).

If we need to automate payload (package/components) creation, let’s see what Salesforce does offer to its customers.

We need to get metadata and transfer it from the test environment to the production environment. Coverage Report – https://developer.salesforce.com/docs/metadata-coverage/54 tells us which metadata we can either retrieve or deploy into the environment. The report is updated as Salesforce Metadata API changes. In the link, we have version 54.0

Salesforce Metadata storage approaches

So we have the following types:

1. Metadata API (MDAPI format)
   1. Old, some say the legacy format of Salesforce Metadata. Deployments are based on package.xml files and mostly ANT migration tool is used for deployments (https://developer.salesforce.com/docs/atlas.en-us.daas.meta/daas/meta_development.htm)
2. Source Tracking (DX format)
   2. This is now the default and recommended way of working with Scratch orgs for SFDX CLI and development with Salesforce. It keeps being updated with new features while MDAPI does not.
   3. Scratch Orgs, Developer and Developer Pro sandbox can track changes done in both local IDE and directly in a cloud environment.
   4. More granular description of metadata files
      1. for example in MDAPI there was one file for “Object” metadata type – in DX it is split into
      2. subfolders like fields, listViews, webLinks, recordTypes, compactLayouts and others. They are still in XML extension just like MDAPI.
3. Unlocked Packaging
   5. Supports only DX (source) format
   6. Group/Pack given metadata files in source format and creates from it an easy to install package
   7. Good for multi-org solutions
   8. Salesforce offers different types of packages, and unlocked packages are especially suited for internal business apps.
      Unless you plan to distribute an app on AppExchange, an unlocked package is the right package type for most use cases.
      You can use unlocked packages to organize your existing metadata, package an app, extend an app that you’ve purchased from AppExchange, or package new metadata
4. 1 & 2 Generation Managed Package
   9. You can rely on managed packages if you want to fully transfer Salesforce features development to a vendor or you are on the other side of the fence and you create some re-usable features and sell them to clients.
   10. Each metadata component that you include in a 1GP or 2GP has certain rules that determine its behaviour in a subscriber org.
       Manageability rules determine whether you or the subscriber can edit or remove components after the package version is created and installed.
       Managed Packages can be installed from App Exchange, they can be free or come with some cost, created by your own devs or 3rd party company.
5. Change Sets
   11. Out of the box SF solution to move metadata changes directly from one org to another
   12. Needs manual work
6. Apex Metadata API
   13. The API lets you make metadata changes directly from Apex

Still, there are some limitations to components that cannot be changed via API – they have to be manually changed inside SF org: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm

Salesforce Deployment approaches

There are multiple ways of promoting changes from lower to higher Salesforce environments:

• Change Sets (works directly in SF Org)
• ANT Migration Tool (supports only Metadata API)
• SFDX CLI (supports both Metadata API + Source Format)
• 3rd party Tools (Copado, Prodly, Flosum, Autorabit & Blue Canvas. Gearset, others) (depending on the tool – can support Metadata API or Source Format)
• Open Source tools: CumulusCI + MetaCI + MetaDeploy (can support both Metadata API + Source Format)

Depending on your needs you have to choose the one that suits you. My main goal as a Salesforce DevOps is to create CICD that is easily scalable, highly customizable and does not require my attention (or very minimal).

In the past, I used to leverage the ANT Migration tool along with (Jenkins) pipelines and git. However when SFDX turned up it was a real gamechanger – finally, we get a dedicated command line for Salesforce. Therefore if you are Salesforce DevOps Engineer position and your goal is like written above, you may think of the following combination:

SFDX (source format) + Pipelines + GIT

Benefits:

• No additional fees, you can use only open source tools
• Most other 3rd party tools are using the SFDX CLI and bring additional overhead, here you don’t have such overhead
• No vendor lock-in
• highly customizable – tailored to your/project needs
  • All checks / validations / custom actions possible
• The Source of truth is the GIT repository
• 3rd party tools can be easily integrated with CICD by Rest API or dedicated plugins (i.e. JIRA)
• New SF(DX) features can be added to CICD just after they are released

Drawbacks:

• No support if the SFDX CLI version breaks some functionalities that use to work, you can always downgrade to one of up to 20 weeks old versions (ref) – and it happens a lot, so test everything before blindly upgrading
• Expertise required – You would need a good Salesforce DevOps Engineer(s)

Additionally, if you want to have some fake data factories for scratch orgs/sandboxes you may think of incorporating open source tools – CumulusCI with Snowfakery. Or if you have a sufficient budget, explore 3rd party tools like OwnBackup with Sandbox Seeding and Data anonymization