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

Join us in this episode as we delve into Julian Joseph's perspective as a Salesforce DevOps Engineer. We will discuss the importance of community, learning, and sharing in the Salesforce ecosystem. Explore his journey, gain insights, and discover valuable tips.

  • Published 19 Apr 2024
  • 8 mins read
Why community, learning, and sharing is essential in Salesforce DevOps (Trails Podcast episode #12 with Julian Joseph)
Table of contents

Episode twelve: Julian Joseph, Salesforce DevOps Engineer

Article Highlights
  • Community-driven development has played a crucial role in advancing Salesforce DevOps by fostering open-source projects like the Nonprofit Success Pack (NPSP), which started as a community initiative.
  • Automation in Salesforce DevOps has evolved significantly, enabling the creation of environments and managing metadata programmatically, though challenges remain in fully automating all processes.
  • Git-based development is becoming a standard in the Salesforce ecosystem, with over 90% of Salesforce Developers using Git for version control, highlighting a shift towards more structured and reliable DevOps practices.

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.

🤝
I became even more familiar with Salesforce DevOps and worked with what I consider to be the best Salesforce DevOps team there is (at least at that time). Jason Lantz and this team built open-source tooling. After that, I moved to another ISV, and most recently, I'm a Salesforce customer for the first time.

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.

If you are looking for some tips on how to execute Salesforce DevOps, have a look at the strategies below:

  1. Automation: Automate your development, testing, and deployment processes as much as possible.
  2. Version control: Utilize version control systems like Git to track changes to your Salesforce metadata and collaborate effectively with your team.
  3. Modular development: Break down your Salesforce org into smaller, modular components.
  4. Continuous integration: Implement CI practices to automatically merge code changes into a shared repository and run automated tests.
  5. Continuous deployment: Aim for continuous deployment to automatically deploy changes to production or sandbox environments after successful testing and validation.
  6. Environment management: Establish clear processes for managing Salesforce environments, including sandbox creation, data seeding, and environment refreshes.
  7. Feedback loops: Establish feedback loops between Developers, Testers, and stakeholders to gather insights.
  8. Monitoring and analytics: Implement monitoring and analytics tools to track the performance of your Salesforce applications in real time.
  9. Training and collaboration: Invest in training and fostering collaboration among your team members to ensure everyone is aligned with DevOps practices and can contribute effectively to the development process.

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 think many teams are moving away from org-to-org deployment to moving towards deploying from version control. However, many of them are also hamstrung by the fact that it is easier to create a sandbox. When you're facing a time crunch, you're going to resort to that when you have that ability, and it's going to be a barrier to making that switch.

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.

🔎
For example, one I've used is SGD ("sfdx-git-delta"). It's a plugin for SFDX. It looks at two different branches or commits and the changes between them. Specifically, it looks for things to deploy, delete, update, or modify. 

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?

🧠
What drives me is the input and resources others have put into me. I mentioned my journey starting off in the nonprofit space as an intern – somebody was always teaching and sharing knowledge with me. This was often free of charge and out of their own time. 

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.

🎓
My class was born out of wanting to share some of that same knowledge and realizing that in the company I was working for, I was seeing that the most valuable thing I was doing wasn't creating automations. It was teaching people how to do that for themselves, whether through a GitHub Action and learning Git, or learning to use a tool like Hutte and making the same modifications. 

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.

⬇️
Who would you like our next expert to be? 

Let us know

on our LinkedIn

Last updated: 09 Jul 2024