What’s so different doing DevOps for Salesforce? — Glad you asked!

Photo by Dylan Gillis on Unsplash

Yeah but… That’s not how {Salesforce||DevOps} works!

For DevOps teams, Salesforce is its own beast. Any modern DevOps configuration built for other systems will not work on Salesforce. No containers, no environmental control, no versioning*… (*applies to non-SFDX orgs. I’ll talk about SFDX — Package-based development in later articles)

For Salesforce teams— especially the ones who’s been working in Salesforce exclusively — DevOps might sounds daunting. What is it and do we even need one for Salesforce? I think our system is working?

DevOps for Salesforce?

It’s important for Salesforce folks to learn and understand DevOps as Salesforce is opening up its gate to more modern software development processes.

Think about how you/your team currently introduce changes to Salesforce production org. Without proactive improvement on the development pipeline, it’s highly likely an Org-based development model: You make changes to a sandbox, and moves changes using change set.

Biggest issue with Org-based development model is that your precious time is spent more on activities that doesn’t create value: Sandbox sync, Sandbox refresh, Building out change set(s), manual testing, manual rollbacks… And the issue only gets bigger as your org grows and your Salesforce team grows.

So, DevOps can help automating manual steps, saving development time. DevOps team takes over, and would like to implement modern DevOps solutions: Put everything in the Git, and let CI tools to built, test, and deploy Salesforce changes.

But… That’s not how Salesforce works

Says the Salesforce team.

1. Not everything can be tracked in Git

There are certain metadata types that cannot be tracked as files, and has to be manually configured.

2. XML metadata files

Except for several metadata types, large majority of Salesforce’s metadata types are in XML format, making it hard for Git to parse and understand changes and merges. Especially, merging a metadata file requires a logic that understands each metadata file structure so files can be merged properly without breaking the file.

Each profile, out of the major metadata types, is one giant XML file with lists of permissions. often times the order of the permission changes, which can cause Git to track as ‘changes’ when it actually is just a location change.

3. Test and Deployment

Deploying Salesforce metadata via metadata API requires well-built package.xml that contains the metadata files to deploy. Tests can be run after the changes were successfully deployed to a target environment. Test can pass in one environment and fail in others.

4. Metadata difference between Production and Sandbox

You can’t technically deploy everything as is to sandbox and production org. There are certain permissions that only appears on Production environment. Each sandbox re-construct usernames and some URLs to match the Sandbox environment and is different than what’s in Production.

5. What to track / Not to track?

Do you want to track Reports, and ask users to build and make changes to reports using Development pipeline? Should you track Page layouts? How about Queues, where the user data gets saved as part of the metadata? Not having an active user listed on the Queue will cause the deployment to fail.

Salesforce DevOps — To Be or Not To Be?

There’s no easy or straight answer for Salesforce DevOps. A Salesforce DevOps specific tool like Copado might fit your teams needs (Spoiler alert: Copado is not in any way a one-stop solution for all the issues, and has very steep learning curve), or your team might decide on build your own solution. Either way, it is critical for every single member of the team understands that the change is coming and is willing to put time and energy learning about Salesforce DevOps. The goal of DevOps is not to build a DevOps stacks, but to allow Admins and Developers to spend more time on activities that creates and adds value.

Majority of those Salesforce DevOps concerns mentioned above can be mitigated by building a well-constructed scripts. The rest of the concerns can only be resolved by discussions between individual contributors with understanding of the issues and trade-offs on each decisions. But knowing what to expect from Salesforce DevOps sure can help your team to get closer to a proper DevOps configuration with less trial and error of your own.

More on Salesforce DevOps

Lots of things to consider for Salesforce DevOps mentioned in this article are combination of my own experience and knowledge collected by reading or watching related videos.

A recent 30-minute webinar from Copado explains DevOps and Salesforce DevOps (+Some very convincing Copado sales pitch) very nicely. — Salesforce DevOps: To Script or Not To Script?

Also a book Mastering Salesforce DevOps (Also written by Andrew Davis) explains more in-depth, if you’ve got more than 30 minutes after watching the previous webinar video.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store