Here is what we learned from managing the Salesforce metadata for some of the world’s largest organizations.
Over the past two years, we’ve managed the source code for some of the largest Salesforce implementations on the planet. In fact, we manage over 350 million lines of Salesforce code and it’s given us some unique insights into what is going on across the industry. With new acquisitions like Steelbrick and Mulesoft finally bearing fruit and (relatively) newly released technologies like Lightning, Einstein and Salesforce DX, the Salesforce ecosystem has never been hotter or experiencing more change.
Here are some of the lessons we’ve learned maintaining and managing hundreds of millions of lines of Salesforce code.
1. Apex Development is Still Alive and Well
Despite the fact that the AppExchange has never been stronger and that the platform has more native capabilities than ever, custom Apex development continues apace! Though many teams are trying to leverage more out of the box functionality, companies continue to invest heavily into Apex. Apex classes remains the most heavily changed code type in our system at nearly 15% of all changes. We expect teams to continue to do custom Apex development for a long time.
Also, it’s worth noting that the top 5 components account for over 50% of the development work done.
2. Lightning Adoption is Real!
Despite the name, Lightning adoption didn’t happen in a flash. It has taken a few years for teams to truly adopt Lightning and for the platform to gain the stability and effectiveness of Salesforce classic. That has now changed. Over the last few years, more teams have made heavy investments in Lightning – even in the largest and most ancient legacy orgs. Lightning was once the future but it is rapidly becoming the present.
3. DevOps is Now a Must Have for Salesforce
These days, few teams that we work with are making changes directly in production. This has been a paradigm shift for many companies. The best organizations are starting to treat their Salesforce instance as if it were a real software development platform. Teams are investing in sandbox infrastructure to ensure their changes are adequately tested. Gone are the days of making a change and having the entire business lose a day of work while teams scramble to fix things. Teams are also investing in agile methodologies in their Salesforce teams. They want to release smaller better units of code to their users faster. A smart DevOps strategy for Salesforce is key to achieving this for teams.
4. Refreshing Your Sandbox Regularly Makes You Happier
It also makes you richer, smarter and better looking! But seriously: the teams that regularly “bite the bullet” and refresh their sandboxes end up having smoother deployments and releasing fewer bugs. A lot of teams use Google Calendar reminders to do this.
Most Salesforce orgs are complex beasts. Many have years of legacy code and all manner of different configurations and add-ons. Plus, Salesforce is often rolling out changes that affect various dependencies in unpredictable ways. If you can keep a regular schedule and refresh your orgs you will have fewer bugs because your test environments are more reflective of what exists in production.
You’ll also be able to release faster which means that you can rollback faster. And everyone sleeps easier when that happens.
5. Your Consulting Bill Could Be Lower…
Teams that invested in some kind of automation for their Salesforce deployments spend far less on Salesforce consulting. Some of our clients work with consultants who would literally block out a week of time for each release just to do a deployment. If you invest in CI and automation tools we’ve seen that cut down from 1 week to a day – an 80% reduction in cost for Salesforce dev teams.
6. Source Control Doesn’t Have to Be Major Pain
If it’s taking weeks to get source control in place you’re doing it wrong. Most teams now know that you should use sandboxes and staging environment rather than just pushing straight to production. Most teams also know that you should use a source control tool like Bitbucket or GitHub or VSTS.
But a lot of teams have struggled to set up a source control process that works for their teams, especially their admins. Many source control products require steep learning curves and manual human steps. There are ways to automate your source code using Ant scripts or specialized solutions like Blue Canvas (disclosure I work there).
7. Salesforce DX Adoption is Still Nascent
If you still aren’t using Salesforce DX, you aren’t the only one. Though it is 2 years old now, few teams have really managed to get a successful setup working with DX. The DX roadmap is promising. Over the coming 18-24 months, we expect more adoption. There are some teams starting to be successful with DX for greenfield projects. But DX still needs some maturing before it can handle legacy system transitions smoothly.
As with Lightning, we predict it will take a few years for Salesforce DX to become the predominant method for managing the Salesforce DevOps flow.
If you want to get ahead of the curve you can use tooling vendors like Blue Canvas or Illuminated Cloud IDE to start gaining some Salesforce DX benefits without investing in massive internal reorganization projects to use it.
8. Teams Are Using More Out-of-the-Box Functionality
Clicks not code remains alive and well and organizations are getting better at leveraging out of the box functionality and AppExchange apps wherever they can. Though there is still a lot of custom development work that is done (Apex remains the largest percentage of code that we store in Blue Canvas). But many teams are trying to get by with doing more using existing packages rather than developing in-house solutions for everything.