How to practice continuous learning and adaptability with Salesforce open-source (Trails Podcast episode #17 with Shane McLaughlin)

Episode 17: Shane McLaughlin, Salesforce Platform Architect

Watch me 🎬

Listen to me🎙️

Give us a short overview of your Developer career

I had a finance MBA and worked for a big utility company in Houston. They put me in charge of this little e-commerce business, and we would use Salesforce. That was the first time I'd seen or touched it for our customer service. If you called us at the call center or emailed us, we'd be doing typical Service Cloud things with it. It turns out the people we had hired to build the rest of the e-commerce business failed spectacularly at it.

I built it on Salesforce with the help of a couple of people working for me because we had no more budget left to do anything else. That was the awakening: "I can do a lot more good for a company as a Salesforce Developer than I really could managing other people." The company said, "I didn't know you could do that with Salesforce." So, that spun off a few years of building other business processes.

I started off in sales engineering and then moved to platform product marketing, doing platform demos. That's how I started messing with the CLI and plugins to serve my demo needs and make it easier to distribute demo orgs. That's how I also got to know the CLI team and the product.

Fast-forward to 2017, when SFDX and the Salesforce CLI were publicly announced. That brought a lot of fresh air to Salesforce DevOps and how the Salesforce Developer experience is shaped. Do you have any specific memories of that time? I assume you were on that team that launched SFDX back then

No, not at all. When that first came out, I just started moving to product marketing. I was aware of it in the sense that many people were working with it. We would need to be able to talk about it, do demos, use it in demos, etc. That was my introduction to it. As I was looking at it, at the same time, I had a giant spreadsheet that I inherited when I took that job. These are the orgs at these different booths that people might need to log into. Whenever you do one of these, you must spin up and create new orgs and put the usernames in there.

As we were looking at SFDX, it is useful not to demo it but to build demos with it. You should be able to push a button and have an org. When you're done with it, you should be able to throw it away because Scratch Orgs came first with SFDX. You should be able to throw it away and not have to do all the reset steps again. I was initially interested in using it to get rid of that spreadsheet. It was a dream being able to spin up Scratch Orgs and hand them out like candy.

Another big milestone I remember from SFDX was the announcement that the command line became open-source. Do you recall when that was?

That was more of a gradual process. Some of that happened while I was on the team. Initially, there was just one giant monolith of the CLI, and then users could make plugins. We would copy all that to an open-source repo three times a year after a major Salesforce release came out. But it wasn't open-source in the way that it should have been. It was more of a static copy of a point in time.

To take that apart, we broke some of the stuff into libraries. In doing so, VS Code, the VS Code extension for Salesforce and the DevOps Center, and anybody else who wanted to build things could consume those libraries. Those all went out first open-sourced. We started breaking that giant CLI into plugins so you'd have the org commands.

We got higher-quality contributions and bug reports. People would say, "I changed this and fixed the bug." We said: "Thanks, 90% of the work is already done. We'll check it, write some tests, and publish it. Open-source is exciting for us. We use a lot of open-source and have contributed to other open-source libraries. There have been a few things that we've found, or sometimes the users have found, that don't quite work right, which we can contribute back. It's nice working in the open. I like the toolset a lot.

Would you consider your team pioneers for the open-source idea inside Salesforce?

Several teams have contributed open-source work. You see it a lot with developer relations. That was one of the first places where you needed to make it open-source so you could share it with everybody. They probably pioneered getting that stuff through security, using GitHub Actions and pull request processes and all that stuff. I would say we're probably one of the product teams. However, many teams are doing open-source work, especially some off the core platform.

Salesforce.org – the part of the company that builds tools for nonprofits – has also been doing a lot of open-source work for a very long time.

Did you know that nearly 40% of Salesforce Developers contribute to open-source projects, and approximately 45% of Salesforce implementations incorporate at least one open-source solution?

Lightning Web Components (LWC) would be another example, right?

That may have been open-source before the CLI was finished being open-source. You may have seen it, but we've mostly moved all feature requests to GitHub discussions. Once GitHub discussions came out, we decided to adopt that to help prioritize not just bugs but also feature work.

You are the author and maintainer of the awesome SFDX plugins. I think that that's how many people in the ecosystem probably know you and your GitHub. For those who don't know, I would say it's a curated list of extensions to the CLI. We also touched upon it briefly with my last podcast guest, Matthias Rolke, who has something similar now. Could you share what inspired you initially, and do you have any specific plans for that project?

What inspired me initially was a lot of the ecosystem had an inventory CSS. I've used those in a few places where finding a list of stuff is ideal. As new things came out, people put it on the list. I had some plugins from other people I was using then. I knew there would probably be a good chunk of them, and you'll see that was done on GitHub as myself and not as Salesforce. Salesforce is not recommending them.

Additionally, a guy on the internet gave us a list of things we've added since then. We've added the plugins to the CLI, which will show you a curated list in your CLI. It's nice to see the relative popularity and health of plugins.

I think I saw yours showing up first, if I'm not mistaken

There may be a lot of older usage of that. It is primarily unmaintained. Some of those commands have drifted into the actual CLI. Some of them are not as useful now. Some were very specific to stuff I was building for product marketing. You'll see commands like, "I need to set my user profile photo or activate a Lightning branding set." You might not care about these things if you're interested in CI testing, but things that you might care a lot about if you're doing workshops and demos that need to be properly branded with your ‘fake company’ for your demo.

I'd like to touch upon telemetry. I assume your team has pretty unique insights into the CLI's actual usage. Can you share any interesting, weird, or funny observations about the usage?

We collect telemetry. We don't know who you are, and we have to scrub all the identifiable information out. We like to track what commands and flags are being used, but we don't get the values. We get which flags you're using. But we're also interested in the OS and version of the CLI you are running. We also track exceptions. If you get exit errors, we'd like to see those and learn what they are. We may need to search in the code.

Regarding exciting things, I've been interested in Salesforce's transition. 70% of daily executions are now on a new 'SFv2' CLI, and about 30% of that are on some version of the old 'SFDXv7.' You'll see most of that usage is on the very last SFDX that we published. You can write an update, but there's nothing to update to. It's the end of the line there.

If you want to talk about weird stuff, if you look at the top twenty versions, number 15 is really old. It's like '7.123,' which is almost three years old at this point. We don't have a reason why there might be a clump of usage on that really old CLI. We've also been interested in some of the command migration for the new project deployment commands.

It is a set of things and people on the current or recent CLI. About 88% are on the new deploy commands. Only a few people have the current CLI but are still typing for things like “Metadata API deployment.” However, getting people to change their scripts and switch their habits may be harder, but they seem to be doing well.

Some of the stuff has just died. For example, there's an old command, do you know "force:source:status?"

I remember running it. Doesn't it give you the overview of all the connections one has? Or am I confusing it?

That might be the org list. But no, this one tells you what's changed in the org and locally and what might be in conflict. Before, you did a pull or a push, and you would run this command to see what would go in which direction. People have stopped using that command. I think it's like less than 2%. They're using the new deploy preview or retrieve preview commands.

There are people who are not publishing their plugins and keeping them for themselves. How many are on your list in your directory? Do you know?

I don't think we have that many on our public list. We had 295 different plugins that ran in the last seven days. These are all different plugins by different authors. Over 75% of those are not from us. About 230 are third-party plugins that someone's created. You'll see a lot of them have one user and a whole bunch of CI usage. This makes you think someone's done something helpful for their deployment processes or testing. A lot of them have company names. We can see if you name your plugin a company's name, and we can then have an idea of who that might be. The metrics for plugins have been interesting.

You are probably one of the fastest shipping products regarding release cycles within the Salesforce product landscape. Do you still maintain a release frequency of every two weeks?

We release every week. I'll explain how it works. Wednesday is our release day, and we have a nightly release that goes out. It'll be on the nightly channel if you ever want to play with what we merged the day before. Once a week on Wednesday, we promote nightly to become the release candidate. That set of changes will stay as a release candidate for a week. Users like to test the release candidate against their deployment pipeline. If anything is going to break, they tell us, and we can fix and patch it before it goes out. We appreciate that so much. That release candidate then becomes the official release the following Wednesday.

We must patch frequently, even if we aren't fixing and releasing new features. However, you'll see new metadata types for Salesforce in the next major release. We want to get those in so people may start testing on preview Sandboxes and use those new features. As teams finish their metadata, we tend to add those.

The other thing is that internal Salesforce teams like to test their metadata with the CLI. The CLI needs to know about their metadata, which may ship in the CLI six weeks before it's available to users. In doing so, internal teams are using the same CLI. We have to do a lot of releases besides those things. The other thing you'll see a lot is workarounds for server issues, where there's some new error, and it's returnable.

If we're polling for a deployment, and there are new connection reset errors, we would like to be able to put the workaround for that and ship it. That gives the server-side team more time to figure that out without impacting customers using the CLI. However, it may be a little while before they can release their fix, and it may be the next major Salesforce version before they can release their fix. It's nice to be able to patch those things because they break all of our tests, just like they break your deployments.

But there is a lot of beauty to a fast release cycle

It depends who you ask. If you like a certain version – like we saw earlier in the telemetry – if you think 7.200 is fantastic and it does everything you need it to do, you can keep using it.

Practice makes perfect

Thank you for tuning into this episode of Hutte's Trails Podcast.

Who would you like our next expert to be? Let us know on our LinkedIn page!