Episode 174: HappySoup.io with Pablo Gonzalez

Pablo Gonzalez is a Salesforce Architect at Salto, a small Israel-based start-up that does DevOps for business applications like NetSuite, Zendesk, JIRA, Workato, and of course, Salesforce. Pablo is involved in all discussions of decision-making at Salto regarding Salesforce. Whether marketing, blog posts, product features, engineering, how we solve certain problems, the API, or anything that has to do with Salesforce, he has a say in it.

In this episode, we talk with Pablo about his project, happysoup.io, and another of his projects, Not Another CI (NACI), and other topics for continuous delivery and integration.

Show Highlights:

How Pablo became self-trained in engineering.
What is happysoup.io, and where the idea came from.
What deployment boundaries are and how happysoup.io works with them.
What the deployment options
Pablo’s other project, Not Another CI (NACI)
Things to think about before building out pipelines when designing for CI

Episode Transcript

Pablo Gonzalez:
Around that time, Salesforce released Dependency API, which powers maybe 60% of what HappySoup does.

Josh Birk:
That is Pablo Gonzalez, a Salesforce architect over at Salto. I’m Josh Birk, your host for the Salesforce Developer Podcast, and here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Pablo about his project, HappySoup.io, as well as other topics relating to continuous delivery and integration. Now, we are going to start, however, with his early years, where he almost had a very different career.

Pablo Gonzalez:
No, not really law enforcement. So criminology is really the prevention of crime. So it’s not a reactive approach. So back in the day when I was young and naive, I thought that I wanted to develop programs, not software programs, but I mean like social projects or social programs to combat the causes of crime. So the idea is you study what leads to crime, which could be poverty, lack of education, lack of opportunities, and you develop programs to attack those things to prevent crime from happening in the first place.

Josh Birk:
Interesting.

Pablo Gonzalez:
But I realize in Costa Rica, that field doesn’t really exist, and most people that studied criminology end up in the, let’s say, the Costa Rican version of the FBI. By the way, I’m from Costa Rica.

Josh Birk:
Gotcha.

Pablo Gonzalez:
Working for the Costa Rican version of the FBI can be very dangerous, and it can be very draining, as well, because sure people just get sent to whatever location they want to send you, and you have pretty much no say in. So yeah. Halfway through, I realized that it wasn’t for me, and at the same time, I started working in a call center doing Salesforce support. That’s kind of where I realized that I like this software thing more than getting shot in the head.

Josh Birk:
Yeah. I can … So that’s kind of cool, though. You had this really noble cause, and then you realized, as many of us do in college, that maybe life wasn’t going to go that way.

Pablo Gonzalez:
Yeah. Exactly. Yeah. Yeah.

Josh Birk:
Nice, and so, then, are you self-trained in software engineering? You jumped right into Salesforce itself, right?

Pablo Gonzalez:
So I got started with Salesforce. So before Salesforce, I really wasn’t into any software at all. I was just a normal, I guess, normal person. I knew how to use computers and all that, but I really wasn’t into software. So when I was studying, I was paying for my own university fees. So I had to have a job to do that, and I was working at call center doing TV support. Then, they moved me to another account with this thing called Salesforce, which I thought was some sales thing, and it was basically Salesforce.
So Salesforce used to outsource their support for tier one, tier two, and it was basically that role, like a tier one role. That kind of got me introduced to Salesforce and software in general, so then, yeah, I started, later on, learning on my own. I did a few courses on networking and Cisco and things like that. But yeah. I don’t have a degree.

Josh Birk:
Gotcha. Nice.

Pablo Gonzalez:
So I tell my wife, I always joke … My wife is Indian, and in India, they’re very strict about having a degree to work. You have to have a degree. Even if you’re Bill Gates, you have to have a degree.

Josh Birk:
Right. Yeah.

Pablo Gonzalez:
So I always joke that we can’t move to India, because I’m basically uneducated.

Josh Birk:
“Sorry, honey. I’ll be unemployed. I don’t know what to tell you.”

Pablo Gonzalez:
Yeah.

Josh Birk:
How would you describe your current job?

Pablo Gonzalez:
Oh. It’s super interesting. Well, it’s good we’re doing this interview with this job, because if you had asked me … If we had this interview a few years ago, the answer would’ve been very different. I’m very happy, very happy, basically. So I work for Salto. We are a small startup based in Israel, and we do DevOps for business applications. So it’s not just Salesforce. We do for, well, Salesforce obviously, but we also do DevOps for NetSuite, Zendesk, Jira, Workato, and a few others.
So because we support multiple apps, the company needed someone with the main knowledge on the biggest one, which is Salesforce, to make sure that whatever we build is not too generic, but that it still makes sense for a Salesforce audience. Right? Because we’re always kind of playing this balance between, this feature needs to work for all the apps that we support, but it also needs to provide specific value for users of that application.
So my job is basically to represent the Salesforce persona, so everything that has to do with Salesforce sort of goes through me, so marketing, blog posts, product features, engineering, how we solve certain problems with the API. It’s just anything that has to do with Salesforce. I’m not saying it goes through me as an approval, but I am involved in that discussion. I provide the point of view of the eventual person that’s going to use our software.

Josh Birk:
That’s kind of fascinating, because … So you are not just a Salesforce architect, but you almost have a toe in almost like marketing and developer relations itself. You’re sort of the internal voice of the Salesforce developer/architect.

Pablo Gonzalez:
Yeah. Exactly. Yeah. I describe myself as an architect, just because that’s a easier … I mean, I think, I guess at an experience level and skill level, I would categorize myself as that, but in my day-to-day job in Salto, I’m not really architecting Salesforce solutions in the sense that I’m not implementing Sales Cloud or something like that. What I’m doing is, let’s say, architect, or being part of the solutioning for a DevOps solution for Salesforce.

Josh Birk:
Gotcha. Nice. Nice. So, well, speaking of that architect role, let’s start with HappySoup over at HappySoup.io. What’s the elevator pitch for that project?

Pablo Gonzalez:
It’s basically, it’s a software. It’s a free and open source software for visualizing dependencies in your Salesforce org. The most common example is figuring out where a custom field is being used. Right?

Josh Birk:
Right.

Pablo Gonzalez:
So if you have the opportunity stage field, and you’re going to rename one of the stage values, you want to understand what’s going to break. Because you could have flows, validation rules where workflows, reports, so many things that could reference that literal value, and if you change it, then you could invalidate some logic. You could break an entire business process. So it basically scans the dependencies in your org, and it provides that information in a very easy to understand output, long story short, so that you can make changes with the confidence that, “Okay. I understand what would happen if I change this thing.” But it also supports other stuff. It’s not just fields. It supports many other metadata types. That’s the gist. It does a few other things, but that that’s the pitch, I would say.

Josh Birk:
Gotcha. What’s the origin story here? Was there a point where you’re like, “This is going to be easier if I just build a tool to visualize this kind of stuff as opposed to moving forward”?

Pablo Gonzalez:
No. It’s funny, because the main driver for creating HappySoup was imposter syndrome.

Josh Birk:
Really?

Pablo Gonzalez:
Yeah. So I was at a point in my career where I felt that I was pretty decent in my knowledge of Salesforce, Apex, and all that, but I don’t know why around that time … So Salesforce DX and creating plugins and all that wasn’t that prevalent as it is today, but a lot of people, for some reason, were kind of creating this opensource or full stack apps, basically. So the guy who created Workbench, who’s a Salesforce employee.

Josh Birk:
Yeah.

Pablo Gonzalez:
I think he was on the podcast once.

Josh Birk:
Ryan Brainard, episode like 17, I want to say.

Pablo Gonzalez:
Yeah.

Josh Birk:
He was an early one. Yeah.

Pablo Gonzalez:
Yeah. So, to me, that’s like a genius, right, that not only you have all the knowledge of the Salesforce API and the Salesforce core scheme and all that, but you can also create a full stack application. So around the time, this was maybe two and a half years ago, for some reason, a lot of people in my network were kind of creating smaller apps like that. And I felt … Well, you know what imposter syndrome is like. Right?

Josh Birk:
Oh yeah.

Pablo Gonzalez:
You feel like, “Well, I’m not a real developer, because all I do is Apex, and deployments are basically just uploading files to an org. So I don’t know. I don’t know anything about real CI/CD or real dependency management. So I kind of felt … I had this dumb voice in my head telling me that I wasn’t a real developer, basically. So I decided to listen to it and then do something about it. So I spent a few months doing some courses on Coursera for full stack development with Node.js and Vue.
Around that time, Salesforce released Dependency API, which powers maybe 60% of what HappySoup does. And so it was kind of like the right thing at the right time, because if it hadn’t been that, I don’t know what I would’ve done. But it just, they released it, and I thought … I tried the API, and I realized this can be improved a lot. Because the API is pretty raw. It just gives you the result in a very raw way. And I thought, “There’s a lot we can do with this.” I started building the product on the weekends and the evenings and all that, and it took maybe around 10 months for the initial … Let’s say the MVP took 10 months.

Josh Birk:
Yeah. Wow. What’s the future looking like with HappySoup if the … Because the Dependency API is being sunsetted, right?

Pablo Gonzalez:
Well, we don’t know.

Josh Birk:
Okay.

Pablo Gonzalez:
So yeah. Maybe about a year ago or more, Salesforce said that the API wasn’t … It never came out of beta. Right?

Josh Birk:
Mm-hmm.

Pablo Gonzalez:
So it was leased as a beta API, and then it was going to be GAed, and then it just wasn’t. Salesforce gave a lot of explanations on the reasons. There was basically a lot of technical complexity. It requires pretty much all the different teams that own different metadata types to do something. I don’t know what that is, but they need to do something in order for the Dependency API to be able to catch those dependencies. And so they were going to sunset it, and I made a lot of noise about that. So they’re-

Josh Birk:
You’re like, “I spent 10 months on this, guy.”

Pablo Gonzalez:
Yeah. It’s my 10 months for the first version. I’ve been doing it for two years now. So it’s kind of my baby. So there is a Chatter group for the API, and when that news was announced, I created the hashtag #GAPlease, like generally available, please.

Josh Birk:
Right. Yeah.

Pablo Gonzalez:
I asked a lot of people in my network to please go in to that Chatter group and make a comment about GA please. If you find that thread, it has so many comments, so many people just either just saying GA please or just giving their own use case for why this API should remain. So thankfully, Salesforce did take that into account, and basically, what they said is that because they know that there’s a lot of apps even outside HappySoup. I know other Salesforce vendors, other products also use that API.
Because they know a lot of people are using it in production environments, they’re not going to just kill it, but there’s also not going to be any development for the time being. So if it was sunsetted, then yeah. HappySoup would essentially, it wouldn’t die, because as I said earlier, that API powers like 60% of what it does. I also have a lot of my own logic to figure out dependencies, but it will give such an incomplete picture that that it may not even be worth using it. So it would essentially die. Yeah.

Josh Birk:
Got it. Okay. Well, #GAplease. I like it. I like it a lot.

Pablo Gonzalez:
Yeah, but I’ve created other products or smaller things since then, so I’ve kind of moved on. Because it did affect me, to be honest, emotionally when I saw those news, because I was like, “This thing is my, kind of my source of validation, to be honest.” I created this thing to feel better about myself, and people are using it. I like it, and people like it. People tell me all these good things about it. Then, for it to just disappear, it would … It’s a loss.

Josh Birk:
Right. Yeah. Seriously.

Pablo Gonzalez:
Yeah. So I did have some time where I was kind of sad about that, but it’s been a while. I’ve created other products since then, and I’ve kind of … I’m at peace with it. If it goes away, then I know it’s not my fault, and whatever.

Josh Birk:
There are several things we can control in this world, and one of them is not whether or not Salesforce takes something out of pilot.

Pablo Gonzalez:
Yeah. Yeah. Exactly. Unless you are higher up the chain. Then-

Josh Birk:
And really high. My hope right now is there is a product manager internally at Salesforce. I’m not sure who it is. I still actually remember the first time I saw this demoed internally, and it was like, at the time, it was somebody’s kind of like pet project to kind of prove that it could actually work. The demo itself, just, it was just a meeting full of product managers. The demo itself just took over the entire meeting, because everybody’s just like, “Oh my God. Everybody could use this kind of thing.”

Pablo Gonzalez:
Yeah.

Josh Birk:
So fingers crossed for you.

Pablo Gonzalez:
Thanks.

Josh Birk:
One more note. When I was looking into this, I had not heard this term before, so walk me through it. What are deployment boundaries, and how does HappySoup work with?

Pablo Gonzalez:
Yeah. So that’s a term that I made up, which is probably the reason you hadn’t heard of it before.

Josh Birk:
I like it. I like it.

Pablo Gonzalez:
So it’s actually, it’s funny, because that was the original reason I created HappySoup. When I set out to create HappySoup, I wasn’t thinking of impact analysis or where is this used, kind of use case. My initial intention was that … You know scratch orgs and unlock packages and the whole idea of breaking up your org into packages is actually very complicated in real life.

Josh Birk:
Yeah. Yeah.

Pablo Gonzalez:
And so one of the things that I was thinking is that, well, it wouldn’t be so hard if you could take a top-level component, so let’s imagine a trigger. Okay. I have the lead or, let’s say, the opportunity trigger, and if I could figure out what the trigger is using … Let’s say, okay, it’s using one Apex class, the opportunity trigger handler, and if I could then figure out what that class is using … Let’s say it’s using some fields, and maybe those fields are using … Well, fields don’t use anything, but they do if they’re formula fields.

Josh Birk:
Right.

Pablo Gonzalez:
Right? So it’s using maybe an object, and that object has a record type. That record type controls picklist values, et cetera. If I could figure out, recursively, all the way up onto the last item, that all these things are somehow related to that top-level component, I can draw a boundary around that and basically take a chunk of my org, export it with the metadata API, and in theory, then, put that in a scratch org so that I can then do development on that top-level component.
So the use case is, for example, if I want to modify the Apex trigger in a scratch org, in real life, as I said, it’s not possible, because there’s just so many things that that trigger would use. But if you could take everything that the trigger depends on to exist and preload the scratch org with that metadata, then you can actually deploy the trigger to that org and do whatever changes you want, and the trigger, let’s say, won’t know that it’s not in its source org. Because it has everything it needs to exist.

Josh Birk:
Needs. I like it.

Pablo Gonzalez:
So that was the idea of HappySoup. That’s why I gave the name deployment boundary. It’s funny, because I showed it to a colleague of mine a few years ago, and he liked it. He was like, “Yeah. It’s nice, but can you do that reversed so I can see where a field is used?” I’m like, “Yeah. Actually, I can,” and turns out that’s the most popular use case. So if I had just released the original version, which was deployment boundaries, probably nobody would use it.

Josh Birk:
Well, first of all, I love that idea. You’re just, you’re giving yourself a safe little island in order to work on things. But then, my guess is that other, I don’t want to say the reverse of that, but the other use case is kind of … Because the other thing that happens is that somebody just doesn’t realize somebody, for some reason, is referencing that one custom field, and that’s the reason why their flow is breaking or something like that. And so the flip side is that HappySoup allows you to make sure that the map is showing you all those connected dots.

Pablo Gonzalez:
Exactly. Yeah. So the term deployment boundary, so it works in principle. I have an example documented somewhere where I did just that, where I took an Apex trigger that depends on a bunch of different things, and I just exported the package XML with the HappySoup or the deployment boundary deployed to a scratch organization, and created an unlocked package out of that, which is, it’s amazing.

Josh Birk:
Nice.

Pablo Gonzalez:
But in real life, if you give that to a real org, it will only give you, let’s say, I don’t know, 70% of the picture, but it’s still good enough. You know?

Josh Birk:
Gotcha.

Pablo Gonzalez:
Because there isn’t any other software today that allows you to recursively inspect dependencies from top to bottom to understand everything that needs to exist for that top-level component to exist in a target org. So it’s still useful.

Josh Birk:
Gotcha. Now, not everybody might be comfortable with the idea of logging into a web-based application and basically throwing their credentials out, having you scour their org. What are the deployment options that people can use for HappySoup?

Pablo Gonzalez:
Yeah. So you can deploy to your own Heroku account, so there’s a deploy to Heroku button.

Josh Birk:
Nice.

Pablo Gonzalez:
Because the app is a Heroku account, sorry, Heroku app. So you can deploy to your own Heroku account. It’s pretty simple. You just need to set some environment variables for a few things, but it literally takes 10 minutes. You can also use it locally, as in just git clone the project, and then build it there, and run it locally. You can also use it in Docker. So there’s a Docker image for HappySoup. It’s better than using it locally, as in git clone, because then, all the dependencies are already there. It comes with the Redis database and the Express server and everything.

Josh Birk:
Nice.

Pablo Gonzalez:
So I know some people use the Docker version.

Josh Birk:
Okay. Nice.

Pablo Gonzalez:
I mean, I think I covered pretty much all the possible scenarios. One thing, though, is I’m going to start working, in the next few months, on making HappySoup a CLI plugin.

Josh Birk:
Oh really?

Pablo Gonzalez:
Yeah.

Josh Birk:
Nice.

Pablo Gonzalez:
That’s going to be another pet project, because I also realize that while some people may not want to use any of those things, or they may not want the UI, and they’re, may have some use case where you need to extract dependencies in an unscripted way.

Josh Birk:
Right.

Pablo Gonzalez:
So the good thing is that HappySoup, the web app, as you know, it’s HappySoup.io, is actually just a wrapper, like, let’s say, a front and backend wrapper for an MPM package that I also created, of course, called [inaudible 00:21:03] Soup. That is the actual core logic that extracts all the dependencies. That package can work in any context, because it doesn’t … It’s totally agnostic. You just need to pass a connection and an ID of what you’re looking for, and it’ll give you those things. So to translate that into a, or convert it into a CLI plugin, it’s just using that Node.js package and just passing it the ID of what you’re looking for, and that’s it. So it should be pretty straightforward.

Josh Birk:
Very, very cool. Yeah. I think you should feel very validated for being a full stack developer at this point.

Pablo Gonzalez:
Yeah. Yeah. I’m a real developer now. Yes. I feel like a real one.

Josh Birk:
Yeah. So let’s talk about another project you have, and I want to walk through this verbally so that people get it, the project, Not Another CI, a.k.a., NACI, which is over at Salto.io. So serious bonus geek points for the wordplay. People can walk that through, that acronym through their head. I think they’ll eventually, they’ll get them, get there. Give me the elevator pitch for that one. What’s that project about?

Pablo Gonzalez:
Just, first, about the name, it’s because … So Salto has … This is not a Salto project. This is my project, but we host it on Salto’s website, because it’s-

Josh Birk:
Got it. Okay.

Pablo Gonzalez:
In the future, it’ll benefit us, and I’ll explain why in a second.

Josh Birk:
Okay.

Pablo Gonzalez:
So Salto has this … I guess I need to give some background. I can’t just explain this without giving some background.

Josh Birk:
Go for it.

Pablo Gonzalez:
So the way Salto works is we translate the Salesforce metadata and the metadata of any other business app into our own language. That language is based on the Terraform language, and we basically have a whole type system to describe the configuration of a business app. That language is called NACL, which stands for Not Another Configuration Language. So, in Salto, we like using this Not Another X, Y, Z theme a lot. So when we went to Dreamforce and TDX a few months ago, also, if you went to our booth, our, what do you call it, not title, I forgot, our catchphrase is not another DevOps vendor.

Josh Birk:
Got it.

Pablo Gonzalez:
So we basically, we play a lot with this theme, because it … I don’t know. We feel that it differentiates us a lot. So when I was thinking for the name of this, I thought, “Let’s just keep the trend.” And so I call it Not Another CI Tool-

Josh Birk:
Like it.

Pablo Gonzalez:
… or Not Another Continuous Integration Tool, and we call it NACI. It’s pronounced NACI.

Josh Birk:
NACI. Okay. Okay.

Pablo Gonzalez:
Okay. So long story short. So basically, what it is a way for you to create an entire continuous integration configuration file with point and click. So let’s give the example of GitHub actions. Right? If you’re doing continuous integration with GitHub actions, you need to create a YAML file based on some GitHub actions, I guess, guidelines. They have their own, not their own language, but their own implementation on top of YAML of how you define what job it is or what kind of filters, if the job runs when a pull request is open or when it’s closed. They have their own way to define if you want to call a batch script or Node.js. So even though most continuous integration servers, they use YAML, they all do it in a different way.

Josh Birk:
Got it.

Pablo Gonzalez:
So when I was learning the CI/CD maybe about a year ago, I realized that creating that whole YAML file, it has two problems. One is you need to do it by hand, and it’s just very time-consuming. But the most important thing that I realize is that it’s not random. There are are patterns to this. A lot of people are doing the same. People are doing, let’s say, a static code analysis when a pull request is open, or people are doing a delta deployment instead of deploying the entire branch, or, I don’t know, we keep the org OAuth URL in a secret of the CI server. There are a lot of patterns that actually repeat themselves across any CI server.
And so the idea is that it’s twofold. It’s one, if you don’t know CI/CD well, you may not even be aware of those patterns. So you may not know, well, “How do I implement CI? What should happen when a pull request is open? Should I do a validation deployment? Should I do a full deployment to an integration sandbox?” So you don’t know, and even if later, you do know those things, then you need to figure out how to represent that in a YAML file. So NACI is supposed to abstract those two things in one go.
So it’s basically, it’s a very simple UI, that it kind of asks … It’s kind of like a wizard where it walks you through those questions that eventually become patterns, like, “Okay. What are you looking for? What do you want to do? Do you want to deploy? Do you want to run tests?” Then, let’s say, if you say, “I want to deploy,” then it’s going to ask you, “Okay. When do you want to deploy, when a pull request is open, when a push is made on a branch?” If you choose a branch, then it’ll ask you, “Okay. What is the branch name?”
So it kind of walks you through this thought process that may not be obvious to a lot of people, and once you’ve gone through that, then there’s a button that you click generate, and it basically creates the entire YAML file for GitHub actions with all the settings that you selected. So it speeds up development of continuous integration, because, one, you don’t need to think about the patterns that you may not even know exist, and two, it automatically creates the entire YAML file for you.

Josh Birk:
Gotcha. It’s one of the things I love that’s pretty consistent in your blog posts, on your content, is you’re sort of like, at the end of it, you’re like, “This is the YAML file we just created. Please use it as kind of a boilerplate for, if you don’t know where to start from a CI/CD point of view, here’s where you go.” I love that, because it’s like package.json for CI/CD. It’s like, you know need it. You know there’s a format for it. You’re not entirely sure of all the working bits. Here’s an example.

Pablo Gonzalez:
Yeah. Exactly, but I think … So it would be very easy to create examples, and actually, there are examples. If you Google continuous integration Salesforce, one of the Google hits is on a Salesforce developer site. I think it’s about SFDX or something like that, and somewhere there, Salesforce has these examples of continuous integration in different CI servers. So there are examples of how to do it in CircleCI, GitHub actions, Bitbucket Pipelines. So it could have been very easy for me to just put those things in a Google Doc and say, “Okay. Here are some templates,” but to me, that’s not enough. Because then, you just paste a template, and you don’t know why it’s doing what it’s doing.

Josh Birk:
Right.

Pablo Gonzalez:
So I wanted it to walk you through that thought process, that, are you deploying? To which environment? Why? When should it happen? That kind of almost educates you … Right?

Josh Birk:
Yeah.

Pablo Gonzalez:
… on the spot as to how a continuous integration pipeline should work.

Josh Birk:
Nice.

Pablo Gonzalez:
So at the moment, it only supports GitHub actions, and I plan to introduce support for Bitbucket and GitLab, but it takes time. I have a lot of other side projects, and I have a real baby at home, as well.

Josh Birk:
Gotcha.

Pablo Gonzalez:
That takes most of my time these days, so I need to be very ruthless with prioritizing things. If it’s not super critical, then it just doesn’t get done. That’s it. I just don’t even spend time on things that are not really critical.

Josh Birk:
I hear you. Well, and I appreciate the fact that you’re leaning into your parent voice and not your imposter syndrome voice, so …

Pablo Gonzalez:
Mm-hmm. Yeah. Yeah. Yeah. Of course.

Josh Birk:
Tell me a little bit about designing for CI in general. We could probably spend a whole other episode on some of the stuff, but what are some things that, before people actually start building out their pipelines, what do you think that are some things that people should think about?

Pablo Gonzalez:
Yeah. There’s a lot of things that I actually think that creating the pipeline is pretty much the last step, is the culmination of an entire thought process. So there are different things, let’s say, for example, the sandbox strategy. The sandbox strategy has 100%, in my opinion, an influence on everything you do after that. It’ll influence your Git branching strategy, because it’s not the same having two sandboxes versus five. Then, you need to decide, should every sandbox have a branch, and if so, how do I merge them? Or do we only use one branch, and we deploy to all sandboxes using tags or something like that?
So even something as simple as how many sandboxes you have is going to influence everything after that. So, to me, that’s kind of the foundation. So that’s one thing, defining a well-thought-out sandbox strategy, which could mean everyone having a developer sandbox, and then maybe a QA or integration sandbox. I also advocate to the idea, or no, I don’t advocate, but I don’t criticize the idea of a shared sandbox. Right?

Josh Birk:
Okay.

Pablo Gonzalez:
Because a lot of people, of course, if you say this in public, people are like, “Oh my God. No. Are you actually saying that? It’s such a bad practice. It’s misinformation.” Right? But it’s very easy for you to say, “Oh. Everyone should have a personal sandbox.” That’s a very easy statement to say. You just say it, and that’s it. Nothing happens. There are many huge Salesforce organizations that, they have … They’re working with a lot of complexity in their Salesforce org.
I’ll give you an example, that I used to work in a company where the developer sandbox or the personal sandbox was pretty much useless without production-like data. This wasn’t on purpose. It was kind of accidental, that as the complexity of the org grew, so many, let’s say, code paths or different execution paths of the code were derived by field values on 10 different custom objects. The reason I say accidental is because this could also be on purpose.
If you think of a package like CPQ, CPQ, a lot of the configuration is done on custom objects. That is a conscious decision. That’s how you configure CPQ, and then, their Apex code, which we cannot see, but, for sure, their Apex code sort of reads that configuration from those objects, and it behaves differently. This wasn’t a design choice. This just was that the natural evolution of that org was that there could be 10 permutations of a single Apex class based on the values of 10 different custom objects.
So what it meant is, was that, again, if you have a developer sandbox, it was super hard to reproduce anything, whether it’s a bug, or a new feature, or an enhancement. We were almost never sure that, is this actually going to work, unless … until that code or change reached UAT, and then we could test that, okay, it works. I know I’m going on a tangent here, but what I’m saying, and there are ways to fix this. I’m not advocating to not fixing it, but there are some scenarios where, let’s say, if you have a project that is like that, where you really need a lot of data, you could work on a shared sandbox for maybe two or three developers, no more. Maybe those guys are focused on that project. They have their own process for that very specific circumstance.
Let’s say everyone else can work on their own, on different projects, on their own samples. It could also be that you are working on a project that requires integration with different systems, and it’s really hard to configure multiple sandboxes to be integrated in the exact same way with MuleSoft, or [inaudible 00:33:45], or Slack, et cetera. So for those scenarios, as well, it may make sense to use a shared sandbox for a few developers.
So I guess what I’m trying to say is that I’m not like, “Oh. You have to have one sandbox per developer, and period,” because we don’t know all the Salesforce orgs that exist out there. So the point I’m trying to make is that you need to make a conscious choice about what your sandbox strategy is going to be, and if that conscious choice is that, “Well, for this specific project, we’re going to use the shared sandbox because of these reasons,” then that’s okay. That’s fine, and you can work around that. So that’s one of the first, I guess, kind of pillars to continuous integration.
That, as I said earlier, also influences your branching strategy, if you’re going to have one branch per org, or if you’re going to use something like GitFlow, where you just have a main branch and then a development branch where everything gets merged into, or if you’re going to do something like trunk-based development, which most people don’t do in Salesforce. There are other foundational things like also … A very important one is deciding, what are you going to actually put in Git? Because doing continuous integration doesn’t mean that your entire org needs to be done into a Git repo.
Again, it’s all about making conscious choices. You can make a conscious choice that, “We’re going to just do CI/CD for code-based metadata, so Apex, Visualforce, [inaudible 00:35:20] components, et cetera, S-controls.” I’m joking. Anything that is called, let’s say, “Okay. We’re going to do it in CI/CD,” and, again, maybe we have other teams. We have contractors that come in and out, et cetera. Maybe we have super users that are allowed to modify, let’s say, email templates in production or annuity.
So it just needs to be a conscious choice that, “Okay. We’re going to track this much metadata in Git to do a CI/CD on that.” Also, if you’re starting out, if you don’t know anything about CI/CD and SFDX and all that, trust me, you don’t want to be dealing with all the different quirks of the metadata API, like with profiles and all these very complicated objects. So very important, as well, to make a conscious choice as to, what are you going to track in Git?

Josh Birk:
What are you actually biting off? Yeah.

Pablo Gonzalez:
Yeah, and again, it does … It’s not all or none. It could be just a small subset set of metadata, and you can always add more stuff as you progress in your DevOps journey. So I’ll stop there, but those are three foundational, I guess, topics or thought patterns that you should be thinking of before you even go and write.

Josh Birk:
That’s our show. Now, before we go, I did ask after Pablo’s favorite non-technical hobby, and, well, it’s a tasty one.

Pablo Gonzalez:
What would that be? I guess eating and cooking.

Josh Birk:
Yeah? Okay.

Pablo Gonzalez:
Yeah.

Josh Birk:
Nice.

Pablo Gonzalez:
I love food, so if I want to shut my brain off, I’ll just watch some YouTube videos on cooking, especially Indian food. As I said, my wife is Indian, and Indian food kind of ruins you. Because it’s just so tasty that-

Josh Birk:
I know.

Pablo Gonzalez:
Just, then, everything else just feels bland. You know? My taste buds are, they don’t respond to other things anymore. Those nerve ending don’t work anymore.

Josh Birk:
I feel you. Like my 2017 trip to India, I’m like, I know this sounds so dumb, like, “Man, the Indian food in India is so good.”

Pablo Gonzalez:
Yeah. It’s so good. Yeah. Yeah. Yeah. Especially in India, it’s really, really good. So I really enjoy that. I mean, I don’t have that much time these days, again, because I have a toddler at home. But before that, I used to cook a lot. Maybe once a week, we would make something special, something new. So I would say, in general, eating and cooking.

Josh Birk:
I want to thank Pablo for the great conversation and information, as always. I want to thank you for listening. If you want to learn more, check out the show notes at developer.salesforce.com/podcast, where you can also hear old episodes that have links to your favorite podcast service. Thanks again, everybody, and I’ll talk to you next week.

Show Highlights:

Links:

Episode Transcript