DevOops: a Salesforce horror story

Mistakes are inevitable. The question is whether or not we learn from them. In this Halloween post, we’ll look at 10 common mistakes made by teams building on the Salesforce platform, and how to turn these tricks into treats.

Don’t feel too spooked if you realize you’re making most or all of these errors — you’re not alone! Identifying missteps is necessary for getting back on track.

1. You can’t recover from mistakes

Building stuff to customize Salesforce is fun. Planning for when things go wrong isn’t. But least fun of all is discovering your work has been lost, or even that your work is to blame for some unintended consequences, and not having an easy option to fix it.

Plenty of teams don’t have data and metadata backups in place. If you’re not ready for disaster recovery, you’re making the fundamental mistake: not being able to recover from any other mistakes! Backing up metadata protects your own work. Backing up Salesforce data makes sure you’re prepared for those worst-case scenarios where customer data has been lost or scrambled in production.

Another essential for your toolbox is an effective rollback solution. Manually unpicking a problematic release costs you and your business, but with a reliable way of rolling back you can deploy with confidence.

2. You build everything you’re asked for

If you’ve spent any time browsing Org confessions, you’ll have seen countless people complain about orgs with too much metadata. Reports, flows, lines of code — everything’s maxed out. Salesforce’s configurability is great, and every business has a long wish list of features and customizations, but building everything makes your orgs slower and more difficult to navigate.

Develop the habit of asking searching questions when feature requests come in. What problem is being solved? Is the requested feature really the best solution? Will it replace something else? Giving users exactly what they ask for every time doesn’t do them any favors in the long-term. The answer isn’t to keep them at arm’s length. Instead, work with them more closely to understand what they really need.

3. You never delete anything

Too many teams fail to remove metadata from their orgs. Often an oversight in the early stages, it quickly becomes a downward spiral: the more metadata you have, the scarier it gets to delete anything. The sheer volume of metadata, the inevitable dependency nightmare, and the all-too-common failure to use naming conventions all make it hard to know where to begin a cleanup operation.

Many admit to using permissions to hide redundant fields from everyone, rather than removing them properly — which doesn’t help org performance. Some teams also adopt questionable workarounds, like creating multiple objects for one purpose to get around field limits. All of this makes data governance a nightmare.

The hard truth is: there’s no easy fix for rescuing an org in this condition — some teams even start over with a fresh org. Once the org is in a manageable condition, a new approach to development is needed to make sure you don’t end up in the same position. Maintaining an audit trail for development work should mean it’s possible to see why features exist, and who to ask about removing them.

4. You can’t see who’s changed what, why and when

A lot of teams lack real visibility into their Salesforce development workflow and the state of their orgs. It’s unclear what metadata exists where, who built it, why they built it that way, and when it was created or deployed.

Changes made directly in production easily go unnoticed — make sure the group of people with sysadmin permissions is tightly controlled. But even changes deployed from other orgs can be effectively undocumented.

Version control is a game changer for generating a robust audit trail in the course of development, giving you both insight and resilience. A Salesforce DevOps platform should also help you identify the differences between environments, track changes in each environment, and gain visibility over every aspect of your process.

5. Your devs and admins work in silos

Devs and admins build things differently. Programmatic and declarative approaches call for different tools during development and testing — and that’s a strength. But when planning, development and deployments are all conducted separately, it’s inevitable that these two different work streams will collide. An admin’s change in production can block a developer’s release; or a developer’s release might wipe out an admin’s change. Either way, it’s frustrating and counter-productive.

Bringing devs and admins together is imperative, and it’s a significant driver for the adoption of DevOps platforms. It isn’t just the developers that get time-saving solutions and all the power of DevOps at their fingertips — so do admins. And the whole team can share one process, one platform, and one audit trail.

See for yourself how a culture of collaboration is the defining characteristic of high-performing Salesforce teams. Download Gearset’s latest State of Salesforce DevOps report.

6. You artificially boost code coverage

Plenty of Salesforce developers admit to gaming their Apex code coverage to meet the 75% threshold. This is pretty tempting when test coverage is blocking a critical deployment. But it defeats the purpose of the threshold and undermines the value of all unit tests across the board, which makes it even more tempting to do it again — creating a downward spiral that’s painful to reverse.

Automated unit testing that tracks your code coverage saves you from discovering the issue in the middle of a release. But ultimately there’s no replacement for a culture that embraces test-driven development with meaningful tests.

There are plenty of other ways to improve testing as well. It’s essential to have a full sandbox that’s a close enough replica of production to ensure QA will catch the vast majority of problems before release. Don’t skip sandbox seeding as a way of getting realistic test data on the relevant objects for every new feature.

7. Your environments are out of sync

Environments getting out of sync is a common problem. Orgs’ metadata will always drift apart, but this process can be exacerbated when there’s no defined release process and no strategy for cleaning up orgs. Once orgs are significantly different, it can be a tedious process to sort out. But failing to address the issue makes it much more likely features stop working as expected or cause a regression in upper environments.

Setting up a regular cadence for sandbox refreshes and syncing is a good idea. But even better, build a release process that constantly brings environments back in sync.

8. You don’t have a defined release process

How do changes get into your production org? Would everyone in your team give the same answer? Even where teams have a sensible release pipeline with a series of environments, that’s no guarantee the process is followed. Team members under pressure to get changes live might skip the full building and testing cycle and treat most work as hotfixes — get it into production now, intending to sort out the mess later.

Deciding on a release process should be a collaborative process, so every member of the team gets to explain what’s important to them. You need buy-in from everyone for a process to stick.

9. Your release days are high-stress

How many weekends have you had to work because a Salesforce release needed troubleshooting? Most teams have horror stories of deployments falling at the last hurdle, whether it’s a bunch of error messages from Salesforce, low code coverage, or a merge conflict that needs untangling. On average, Salesforce devs and admins spend 9 hours outside of contracted work hours on releases every month.

You’ll never eliminate deployment headaches entirely, but the vast majority can be avoided by following development best practices. Bring the pain forward — find and resolve issues early on, not during a release. Continuous integration and automated testing are the key ways to “shift left”, validating that different changes can be merged successfully, deployed to an org, and pass all tests. This is how you achieve a central DevOps principle: always be in a position to release on demand.

10. Your release cycles are too long

If your deployments are slow and painful, it seems logical to put them off for as long as possible. As a result, your team may well have a long release cycle — perhaps lasting a fortnight or longer. But this only fuels the problem, and there are major downsides to a slow release cadence:

• Users have to wait for a release before seeing value, even for small improvements.
• Larger releases are more likely to fail and trickier to unblock.
• It’s difficult to get feedback on the direction of development, compromising agility.

The first step is to find a deployment process or solution that’s quick and easy. Once releases run reliably, it’s possible to introduce automation with CI/CD, testing, and monitoring. High-performing teams can release multiple times a day.

A silver bullet?

Ok, so it’s unrealistic to imagine there’s a silver bullet that solves all of these problems — certainly not straight away. But adopting DevOps as an approach to Salesforce development and releases will tackle all of them. Create a culture of collaboration and transparency within the development team, and work towards short release cycles that increase your agility and improve engagement with end users. That shift of mindset and attitude is vital.

Continuous learning is pivotal for success in Salesforce DevOps. Check out the free courses on DevOps Launchpad to solidify your knowledge and add to your skill set.