8 Lessons from Managing Over 350M Lines of Salesforce Metadata

Share this article...

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.

5 thoughts on “8 Lessons from Managing Over 350M Lines of Salesforce Metadata

    1. Avatar

      Shane, that’s impressive. It’s clear that you guys put a lot of thought and work into your CI setup. We can relate to your pain points, it can be really hard to get a process like that working. Trying a first deployment and “[…] one had 1600+ errors on first compile and the other had 1200+ errors” – yeah that’s just super common on Salesforce unfortunately. Great blog post – recommended for any developer who’s interested in DX and CI.

  1. Avatar

    Thank you for the insight. Isn’t it great to be in the mist of growth like we see with Salesforce. If the software industry has taught me one thing, that does not last forever, so enjoy the ride.

  2. Avatar

    As a long-time SFDC Consultant I appreciated how much work and commitment was in play here. To boldly push the technical boundaries and known pathways to improve development and deployment in unprecedented ways was illuminating, to say the least. The platform has changed forever, I was one of the prove it to me that Lightening will work better than Classic guys, I’m still not in love with the UI, but the future of the platform is now well established and Lightning is it.

    All the learning and discovery necessary to articulate the end-result “Ah Ha’s” is amazing but, for smaller firms without the resources to undertake a DX project like this is beyond the reach and budgets of these firms. The gap here is not subtle so I wonder how or if it’ll be possible to package these key CI staging environments such that firms without large resource staffs can undertake similar results? Brave new world time…

    Thanks for the link to the article – things have definitely changed, and as we say here in the States, “Toto, I don’t think we’re in Kansas anymore”…

Leave a Reply