Adopting DevOps for Salesforce streamlines your development process and improves collaboration. But learning and implementing a new way of working always comes with challenges.
In this post, we’ll look at some common Salesforce DevOps adoption challenges — and explore straightforward solutions. While there are various challenges that teams can run into, broadly they fall into two categories: cultural and technical.
Cultural obstacles
DevOps is about culture as much as tooling and process, so overcoming cultural obstacles on the path to Salesforce DevOps adoption is vital. The goal is to create collaboration and boost confidence within your team, but also to navigate this cultural shift within the wider business.
Confusion about Salesforce DevOps
Much of the Salesforce ecosystem remains uncertain about the meaning of Salesforce DevOps. Plenty of low-code folks who’ve been around Salesforce for a while have noticed the dramatic change in how people practice and talk about release management. For some, “DevOps” can be used to describe any approach to releases.
For other development teams, DevOps is a familiar concept from other platforms. But it isn’t clear to them what DevOps looks like for a low-code platform like Salesforce, where development teams don’t need to maintain infrastructure themselves.
But at its core, DevOps is all about better collaboration, streamlined workflows, and quicker delivery of value. All of these are just as relevant in the Salesforce world as they are in any other development environment.
For Salesforce teams, DevOps means bringing admins and developers together in a shared process for development and release management. It focuses on automating repetitive tasks and making sure everyone is working in sync. Ultimately, the goal is to break down barriers, align your team, and make DevOps a practical and accessible approach for everyone.
Developing in production
Given how easy it is to make declarative changes in Salesforce, it can be tempting to develop directly in production. But by doing this teams risk introducing bugs or errors into their live environment, causing downtime for the business while they try and fix any issues. It can also mean that any changes you want to keep are overwritten in a later deployment. In one sense it’s the quickest way to get your changes live, but the time spent fixing the changes that have broken production take far longer than pushing your changes through a dedicated pipeline.
Introducing a DevOps process allows teams to be able to track and merge changes across environments using a version control system. Having this complete visibility over the whole development process increases collaboration throughout the whole team. The ability to automate testing improves the quality of releases and gives you peace of mind knowing that your release won’t break production — and if it does, you can revert to an earlier version.
Resistance to frequent releases
Traditional release windows feel safe and predictable for businesses that have become used to them over many years. But because so many changes are now being made in these windows, it can often lead to larger, riskier releases which can cause serious issues if something goes wrong.
On the other hand, DevOps encourages smaller, more frequent releases — deploying changes in little slices as soon as they’re ready. This allows teams to catch any issues early and fix them quickly. A DevOps process with version control or CI/CD, promotes automated testing and leads to an overall improved code quality.
This can feel like a big change to process, so getting support from the whole team can be difficult. They might worry that more frequent releases will mean more chances for things to go wrong. The key here is to communicate that DevOps is a proven way to deliver more value to the end user, as quickly as possible — and with fewer deployment issues.
Building team confidence
For admins and configurators, the idea of transitioning to DevOps can feel intimidating, especially with the misconception that proper DevOps practices are far trickier than org-to-org releases.
But with proper training , resources, and the right support, the transition to a DevOps process that everyone is happy with can be achieved fairly quickly. It’s also really important to create a culture where questions are encouraged and mistakes are seen as chances to learn.
Slowing down to speed up
Slowing everything down might sound like the opposite of what we want to achieve with DevOps, but sometimes it’s necessary. If you’re just starting out with trying a new DevOps methodology or wanting to evolve your existing one, you may need to factor in some time to “freeze” your processes. This time could be needed for code development, a certain deployment, or team training. This planned freeze can cause a lot of apprehension for senior stakeholders who are expecting processes to continue at a certain pace. Communication is key in letting them know that while pausing for a number of hours (or days) isn’t ideal, it will make the processes much faster and more efficient overall.
Technical obstacles
Introducting DevOps into your Salesforce release process can radically improve the way you deliver value to your end users. But as with any change of process, there are a few technical obstacles that need to be thought about along the way.
Salesforce platform quirks
The Salesforce Metadata API can make deployments tricky, especially if you’re deploying certain types of metadata — like profiles and permission sets, flows, communities, and layouts. These are notoriously difficult and error-prone metadata types to deploy.
Salesforce orgs get filled up quickly, becoming out of sync with each other. When your environments aren’t in sync, it’s tough to maintain a consistent, reliable development process.
Deployments can also fail if you forget to include a dependency, or you don’t deploy in a particular order — especially when dealing with complex packages. This can make deploying large change sets or working in environments with a lot of crossing-over dependencies particularly tricky.
Using a tool that helps manage and streamline deployments is crucial to DevOps success. Gearset can make your deployments quick and easy, allowing you to catch missing dependencies before they become an issue. You can also sync all your Salesforce orgs and easily deploy tricky metadata types.
Platform and API upgrades
Salesforce releases three big platform updates a year, and many other smaller updates in between. Sometimes these releases go unnoticed, but with others, it can cause significant challenges for a development team.
Every release will include an API version, which can cause your metadata to become mismatched and cause your deployments to fail. This is especially true if Salesforce decides to phase out certain metadata types. Gearset will intelligently choose the best API version for comparisons and deployments where possible, and will give you the power to override the version in just a couple of clicks.
Strict code coverage requirements
Salesforce requires that 75% of your Apex code is covered by tests before you can deploy to your production org. This means that tests need to be maintained. Falling short of the 75% threshold will stall your deployments, leading to delays and added complexity to release processes.
With testing at every step of the process, DevOps speeds up project delivery and improves release quality. You can have automated unit testing up and running with Gearset in just a few clicks, giving you full visibility over the performance of your Apex classes.
Managed packages can be a nightmare
It can be tempting to install managed packages straight into your production org, but as with any other metadata, it’s advised to test them in a developer environment first.
Manually installing packages into orgs can take a long time, but by using version control you can deploy your packages to your other orgs easily, all at once. It’s not always necessary to manage your packages in version control, but it’s good practice for maintaining consistency and collaboration across all your environments — supporting a DevOps workflow.
Limited native deployment tools
The way we deploy to Salesforce is evolving all the time, especially since the introduction of DevOps. But many teams are still using Salesforce’s native change sets to deploy, even though they come with a number of big limitations. The manual process of building a change set is time-consuming, with no promise that your deployment will even work. There’s also no way to automate the process or introduce version control. This means for anyone using change sets, the jump to DevOps can feel like a big one.
Even with DevOps Centre, Salesforce’s native DevOps solution, teams are still limited in their ability to practice true DevOps. The lack of native automation, robust backup and ticketing integrations force teams to look for a third-party tool to help mature their processes.
A third-party, off-platform solution like Gearset includes all of the core DevOps tools, including automation, integrations with your existing VCS, a secure backup solution and plenty of other benefits.
Get started today
Gearset makes Salesforce DevOps easier, with solutions that deliver fast deployments, reliable automation, and secure backups. Whether you’re just starting out on your DevOps journey or you’re looking to build on your existing processes, Gearset can help you overcome these common challenges with our complete Salesforce DevOps platform.
With Gearset, you can automate those tricky, error-prone tasks, catch issues before they become problems, and ensure that your team is always working with the most up-to-date and consistent environments. Start a free 30-day free trial today to see how Gearset can transform your Salesforce development process or read more about taking the first steps towards version control by reading our whitepaper, Version control for Salesforce.
