Easy, point-and-click configuration is a major selling point of Salesforce, empowering Salesforce admins and developers to tailor Salesforce org to their organisation’s needs. Does effortless configuration lead to Salesforce development challenges that now need to be solved?
“10 Things We Learnt from Analyzing 1 Billion Salesforce Metadata Items” was a recently published article where Ian Gotts offers fascinating insights into Salesforce development drawing on his team’s analysis of Salesforce metadata items. From our own experience at Gearset, we would echo the points made in Ian’s article. We have a slightly different take on some of the implications, however, given our DevOps experience. So here’s our 2 cents’ worth…
Common challenges for managing metadata
Ian highlights some of the common challenges for org maintenance and development. These are the same challenges we’re helping Salesforce teams to resolve as a DevOps solution provider.
Like Ian, we see mammoth orgs with ‘staggering’ amounts of metadata: orgs with 200,000 Reports and Email templates, 50,000 Apex classes, and 1,300 Permission sets. In terms of data, we come across objects with hundreds of millions of records, and orgs with up to 35,000,000 accounts. The size and complexity of these orgs, resulting from years of customization, pose significant challenges for the ongoing development and maintenance of code and configurations.
Older orgs, in particular, often suffer from technical debt, as Ian points out. In our experience, this is a common consequence of teams adding or deploying more and more changes to production without a clear view of the impact. That’s why the first thing we built for Gearset was the comparison tool, enabling developers and admins to see the exact differences in the metadata between any two environments. Comparisons allow teams to understand exactly what effect their deployment packages will have.
Teams also run into problems with technical debt if they’re not leveraging automated unit testing and static code analysis. These tools provide early warnings of failing or poorly designed code, ultimately leading to fewer issues in production.
Salesforce deployments can be tricky, and Ian’s comments about the Metadata API resonate with us. In the early days of building our Salesforce deployment engine, we decided to solve the difficult problems first. We knew we had to get to grips with the MDAPI’s quirks if we were going to offer the ecosystem a tool that provides unparalleled deployment success rates. Like Elements.cloud, and no doubt many others besides, we’ve fine-tuned how we fetch and return metadata. And over the years, we’ve developed dozens of problem analyzers that spot common deployment-blocking problems in our users’ deployment packages, and automatically suggest the fix that’s needed to deploy successfully.
A robust process for agile development
In the face of these challenges, it’s important to build the right processes and culture for development. We couldn’t agree more with Ian that ‘long release cycles = poor agility and engagement’. Accelerating your release cadence, shipping small and often, tightens the feedback loop for your developers. And shorter sprints lead to increased agility for your company. We see teams ramp up to multiple releases a day instead of releasing as little as once a quarter.
We also share Ian’s concern that Salesforce teams should maintain documentation explaining why changes have been made, not just when and who by. Teams using Gearset automatically generate comprehensive audit trails with everything they do, including all deployments and automation jobs. Team leaders can also make deployment notes mandatory, so every change in the deployment history has an explanation. And for teams using source control, documentation with a full history of metadata changes is just part of the process.
DevOps for Salesforce
From our perspective, all of the above makes the case for source-driven development and automated DevOps. We agree entirely with Ian’s diagnosis of the common problems faced by teams building on Salesforce, and his ideals about agile development. But we don’t think developing in production is necessary for agile development; our recommendation is to embrace DevOps.
Implementing DevOps best practice doesn’t mean adding needless complexity or barriers to agile development. Quite the opposite! It’s designed to make the most robust and responsive development practices easy. Simple declarative changes can be shipped every few hours through a highly automated release pipeline, while more complex features go through the necessarily robust testing and reviewing process.
At Gearset, we’ve seen teams mature their DevOps processes and reap the rewards: cutting deployment times by 90%, boosting deployment success rates to above 90%, and increasing release cadences by up to 17x using our continuous integration tools.