Why community, learning, and sharing is essential in Salesforce DevOps (Trails Podcast episode #12 with Julian Joseph)

Episode twelve: Julian Joseph, Salesforce DevOps Engineer

Listen up 🎧

Watch it in action 🎞️

Please give us a brief overview of how you first became involved with the Salesforce ecosystem and how your career evolved from there

I started as an intern on the nonprofit side of Salesforce work. The VP asked me to learn Salesforce, so I went the Admin route. It was before Trailhead existed, so I spent a lot of time looking at help articles and trying to understand what Salesforce was.

Did you know that Salesforce's Trailhead platform launched in 2014 and has empowered over 30 million learners globally to skill up and advance their careers in the Salesforce ecosystem through interactive, gamified learning experiences?

That led me to learn about the Nonprofit Success Pack (NPSP), one of the largest managed packages created by the community and then taken in-house at Salesforce itself. With that set of packages, I became familiar with installing them and getting them up and running at the nonprofit I worked for. From there, I transitioned into a job in San Diego, where I'm now based.

I was working with another company in the nonprofit space. I was their first technical Salesforce-focused support person. They had a product on AWS (their app), but the integration was Salesforce. I focused on that managed package within that company, transitioning from technical support and working with customers to working with the dev team.

I also did a mix of testing and DevOps tasks building environments when scratch orgs were brand new. I then transitioned to Salesforce in their nonprofit division, working on NPSP. I moved to what many call "the Mothership" and worked there for a few years.

So, NPSP didn't start at the Mothership but was a community project that Salesforce took on?

Yeah, that's what I understood from people in the community. This was before I started using NPSP. I think the story goes that it was an open-source community project that was then brought into “Salesforce.org.”

They funded and supported it under the Salesforce Foundation, Salesforce's nonprofit. Later, "Salesforce.com" purchased "Salesforce.org" right when I joined. But it started in the community and is open-source.

It's probably one of the packages with the largest subscriber base. I think there were about 30K subscriber orgs in that package. So, I can imagine that it raised some challenges for DevOps processes and pushed the tooling that Salesforce also came up with to bring in proper practices around packaging and distribution

I think CumulusCI itself was born out of the need to scale many of these issues that were being done with small one-off bash scripts or some smaller processes being done manually. But once you hit that set, scale, and size, you need to figure out a better way to distribute and update the package. It's actually a set of multiple packages, dependencies, and things like that.

How did you see the big picture of the Salesforce DevOps ecosystem evolve over the past few years until now?

Much of my experience comes from the ISV side of DevOps, which is 'a niche within a niche, within a niche,' because Salesforce itself has its flavor of DevOps from, if you say, "Oh, I'm a DevOps Engineer." I always have to caveat, "No, I'm a Salesforce DevOps Engineer," which is a little more focused on the ISV side. That's even its own kind of subset. In terms of how it's changed, I feel like I've benefited from being more on the end-user side of DevOps, even though I've also been developing some of these automations.

I think we've gotten to a place where many of the tasks that were manual early on can be automated. Whether that's creating an environment with, for example, scratch orgs or even using the CLI to create sandboxes, it's about being able to create an environment in a programmatic way that used to be impossible. That was a huge achievement. And then getting deeper into metadata and data configuration while these processes were partially automated.

I'd also say that any process you want to do can be automated today. That being said, I think there's still a long way to go to actually being able to practically automate everything. Just because you can't do it doesn't mean it's easy to do. For example, there are still some things that can be done programmatically that I've personally built UI automations to do.

We've come a long way in terms of having the capabilities to simplify things and actually create a full end-to-end development flow. But there's still a long way to go to actually wanting to do that in every situation and having enough resources to do it.

With Git being somehow de facto at the core of most DevOps processes, how do you see the penetration of Git-based development in the Salesforce ecosystem?

Between the partner community of, for example, ISV and OEM development versus customers on the ISV side, a good portion of midsize to larger ISVs are doing Git-based development.

In fact, over 90% of Salesforce Developers use Git as their primary version control system for managing Salesforce metadata.

Many would say they want to have a better branching strategy. But using version control as your source of truth is pretty common (less so on the customer side). I think one of the biggest reasons for that is the importance of sandboxes and how difficult it is to replicate your production environment without wanting to resort to the relatively easy way of creating a sandbox, getting all the metadata and configuration, and making modifications on top of it.

We will not see a huge shift until we move away from that being the base process in creating and distributing your next environment. That being said, I think the mindset is there.

From my experience, many teams want to make the change. They are probably using Git extensively for their branch management and then figuring out some way of sometimes deploying that to sandboxes when they can. It could also involve creating a data set or bash script and locating that in your version control.

I feel that there is quite a positive dynamic in the Salesforce open-source landscape. Do you share that impression? Did you have touch points with any of those toolings (like DX@Scale) beyond your hands-on work on CumulusCI at Salesforce?

I see the open-source landscape for Salesforce DevOps as being extremely encouraging. Besides the tools themselves, it feels like that group is always growing. Whether it's creating things like the Salesforce DevOps Manifesto, encouraging conversations on LinkedIn, or creating tools like Flxbl (formerly known as "DX@Scale").

I like to read the documentation to get ideas. I think each one has its sweet spot. I'm thinking about some that focus on pooling and others that allow you to bring in custom bash scripts, which is easier versus having it be more prescriptive in terms of these sets of tasks or flows you already have.

There is a lot of value in seeing what each one is doing, and there are ways to use them interchangeably. I have seen a lot of progress with using GitHub Actions as existing scripts, and I have even seen people who've created their own GitHub Actions. GitHub Actions are small actions or steps that could be large. You can incorporate them in your deployment to run something like modifying an environment or creating a Salesforce environment.

Once I started to look for more actions and plugins, I found quite a few out there, some of which are not even non-Salesforce specific. For example, a Slack notification that lets you know a job is done elevates your builds. When you pair it with a tool like CumulusCI, you can find ways to integrate them all together. You can have a pretty powerful setup, and you can get a lot closer to that ideal of having everything automated in a practical way.

Can you tell us about your git-together training activities and also what drives you behind being open to sharing your knowledge and helping others on their journey?

One funny story is about a consultant at the nonprofit where I worked who was supporting me. About four years later, I realized that I'd been working with them for the last year in my next company. It never clicked that it was the same person, but I said, "Wait, you taught me what objects and tables were." It just never clicked until one day when we were working together.

Through seeing how people give their time so readily towards training, I realized I wanted to do the same. My class or course was a one-time thing for now. I might rerun it in the future, but there's something between me and a few other Salesforce friends that I've gained over the years through different meetups.

The focus is on the idea that many of them had Salesforce knowledge but were somewhat new to GitHub or how DevOps tools worked. Meetups are an easy way to onboard people to their first experience with Salesforce DevOps.

I wanted to test it out with friends distributed across a group of companies and see if I could empower them to do a little task at their company and grow that into something bigger.

I will say it's not completely selfless. Like with anything in the industry, it's always nice for those people to think of you down the line and hire you for a contract role. Overall, my request is always that people pass along what they've learned from me to somebody else down the line. If I'm helping you, pass it along. Give them some free information, whether it's the same information or something else, like some skill you're bringing to the table.

Sharing is caring

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