Hutte Trails Podcast – A podcast about all things Salesforce

How to deliver first and explain later in Salesforce DevOps (Trails Podcast episode #15 with Diéffrei Tiepo de Quadros)

• Hutte • Season 1 • Episode 15

Share episode

Join us in this episode as we delve into Diéffrei Tiepo de Quadros’ perspective as a Salesforce Technical Architect. We talk about effectively delivering when it comes to Salesforce DevOps. Explore his journey, gain insights, and discover valuable tips.

Harald (00:01)
Hey Jeffrey, great having you on the podcast, thank you very much for taking the time.

Dieffrei Quadros (00:07)
Nice to meet you, Harald, and thank you for having me in the podcast.

Harald (00:11)
So Jeffrey, we actually met each other online quite a few times. I think on LinkedIn, it's just Salesforce DevOps is a narrow field. And yeah, as I dare to say, like -minded people who have a passion for scratch orgs and packaging, there was just no way to not bump into each other. And yeah, I'm super glad. I think it's the first time we speak actually in person. And I'd like to start with

My typical first question, what is your history with Salesforce? How did you get in touch with Salesforce technology in which role? When was it and how did your career in the ecosystem evolve from there?

Dieffrei Quadros (00:57)
Yeah, first thing is I really appreciate the work that you have done with Hute. I really like that product because I was one of the first customers or beta users for that. So I really love what has been done for that so far. And also about the impact that Hute had in the ecosystem as far as when we are talking about DevOps. But talking a little bit about my career, I think I began to work...

or my first contact with Salesforce, it was in 2008 when I basically, I came to my manager, former manager and asked to work with something different because I was a little bit saturated with the technologies that they have been working so far, Flex and Java. And then she said, all right, so I'm going to give you a new opportunity. We just had some engineers, they came from San Francisco.

and they learned some new technology. And then I was really excited and curious about to understand what was that technology, because in my, that company, just to create a field and create an edge to the report, it costs like, I don't know, $3 ,000 or something like that. And I heard that with the technology and that platform I could do basically did very quickly without a lot of, spend a lot of money.

And then that's the way that I joined Salesforce, actually working for this ISV. It was for fleet management. It was very cool. I learned a lot. It was very in the beginning. So no trailhead. We had that first ID, which was very painful for me. And then after that, I went to the open source community and then I found out that they could use Maven's mate with Sublime, which helped me a lot.

In that time, I really liked that tool. And then another contact that I had with the open source community in that time was, in the beginning, I was using anti -migrations, but I didn't like that much. It helped a lot, of course, but I didn't like that much the XMLs, et cetera. And then I found another very good repository. I think it was from Mathias. I think Mathias had some involvement with Huty, right? So he create a repository. Yeah.

The name was Force Dev Tools as far as I remember. It's already archived, but in that time it helped a lot because we had that kind of GIF delta deployment stuff and it really worked pretty well. Yeah.

Harald (03:39)
Let me just side step for our audience who might not know Matthias. So Matthias is certainly a future guest on this podcast. We haven't had an interview with him yet.

yet, but he's, yeah, he's a Salesforce DevOps legend. He did the force, the force dev tool, which was long before Hute existed or even the idea for Hute existed, but he eventually became a supporter of Hute and he's still basically working with us. He's working as a DevOps consultant, but also working with Hute. So he's very close to the very core of Hute and yeah, we'll certainly.

I'll have him as a guest sooner or later, but sorry for the briefing. Back to you.

Dieffrei Quadros (04:22)
Yeah, this guy is brilliant. I already talked with him briefly also on Twitter. So that's why I for like work wise, I really like Twitter. So I already that's the way that they found, for instance, flexible, the former DX at scale as in Renzi, even Matthias. So that's really nice. And also when I need something, I just reach out to the product.

teams from Salesforce because it's a faster way to do that. But yeah, so coming back to the point of my career, then after some moment, I moved to a consulting. So then it was a very nice for me because I work in so many large projects. And in that time, it was very painful when we are talking about DevOps perspective. So we are just using before to come to the first DevTools and all these automation tools.

I used to just, we used to use just change sets. So we used to spend like, I don't know, six months developing everything in there. And then some point of time, we just deployed QAT. And then maybe one week before we go live, we have, we had like, I don't know, 10 engineers in a work room, everybody trying to create code coverage. We didn't properly test. It's just like create code coverage.

to just deploy. Of course, it was like kind of integration test. We didn't use that trick of add a lot of plus plus, E plus plus in the code because that's terrible. But yes, so we just say, okay, let's create some code coverage because the deadline is almost there and then we need to deploy to the production. And then what happened is I was a little bit frustrated about it because I already had some...

background from Java and other technologies. And I saw that Salesforce platform somehow was very behind. And then, guys, how we can do that? So I think that knowledge from another technologies, another platforms helped me to think a little bit out of the box. So I tried to think about CI -CD, some automations. And then I think it was a little bit hard in the beginning to convince my people, my team.

colleagues management that we the way that you do right because if you read in that of course we didn't have Trailhead, but we had some Salesforce documentation and Salesforce just say okay use change sets, etc. Right and then I realized okay, but we have the concept of CI CD We have like some automations how we can do that and then when they start to look for more information about it and how to do then I found this another tools in how I

was my approach to convince them to do that. So I always work in the same way. I use this strategy to deliver first and then explain later. I think that's the way that I achieved the most of the things in a lot of success cases in this situation specifically. So I think around 2015 or something like that, I traveled to Europe. It was my first project abroad.

And my team arrived, I don't know, to work around one month. And then in that month, we spent a lot of time building new functionality. And then finally we reached to the last week. And basically we had, I don't know, three or four days just to, we prepared or allocate the time just to do the plans. And how was, how we plan to do the deployments, creating a lot of change sets, deploying, and you know,

how is it painful to deploy profiles, et cetera. And then finally on Friday night, one day before the deployment, my team went to the grocery store. We bought a lot of chocolate, coffee, et cetera. And everybody was inside of the room. Everybody was prepared to start to create the change sets and deploy. And they say, guys, let's enjoy, have fun in Madrid, in Spain, because the deployment was already done. And everybody got very shocked. Like, what happened? How come? Et cetera.

And then I introduced them the way that they could do. So it wasn't CI -CD actually. It was just like some scripts using force dev tools. And then everybody really got shocked. Okay, how you deployed everything in just, I don't know, half an hour, everything was deployed. And now we just need to do very small configurations. So that's the way that they impact the team and show to the management that's the way to go. And then they start to give me some room to try different.

tooling and invest the money and give me some budget to then apply CICD and another, yeah, to use another tools that I needed. And then it improved a lot the Salesforce lifecycle, the value of the consulting firm. So, yeah.

Harald (09:26)
And may I quickly ask in this period of time in this role, did you have a specific job title as a DevOps or release manager or were you one of the developers on that team and you just took the responsibility to improve the delivery methodology?

Dieffrei Quadros (09:46)
Yeah. So when I moved to that consulting firm, I moved as a Salesforce technical architect. So I was leading the development in the best practices. But of course, at that time, I didn't know a lot because my background was more into Java. Right. So, and then when I learned from Salesforce, okay. So that's the way, for instance, I'm not sure nowadays, right. But I remember that I saw many times in Trailhead or in other publications.

that not talking just about real hand, but another content from Salesforce community, they'd say just about tests, but actually there are a lot of different types of tests, right? So if we think we have like a pyramid of tests that you have unit tests, integration tests, end -to -end tests, all of them, they are very important. They have like a cost related to it. And you need to really understand when you're going to use them, how you're going to run them, which stage of the development you can run them, et cetera.

So that's the things that I was learning painfully because these kind of things I didn't learn. Okay, so I didn't move to Salesforce ecosystem without this knowledge. A lot of this knowledge that I got was just by trying, no, it didn't work. I didn't find any documentation. And I think that my primary source, as I mentioned, was Jeff Douglas blogs, basically. That's the way that they learn.

Harald (11:15)
And if we then fast forward, so I think in 2018 or so SFDX went general availability. I assume you were an early adopter having this interest and background, but you were certainly excited that there was a command line rather than.

Dieffrei Quadros (11:32)
Whoa.

was very interesting. Yes, it was very interesting because I think in that reinforce I didn't, yeah, I just went into the reinforce. I think it was in 2013 when I remembered that the financial force library was launched or at least it was publicly available as far as I remember. And then in 2016, but talking about Salesforce DX, I got very excited. I was trying to, my God, where I can find the link and how I can install.

And then I remembered that they was working for one very large project. And yeah, it was very painful actually, because every time that I use a command to deploy the code for scratch or something like that, I got some error. It wasn't like an error, very descriptive. It's just like saying a no pointer reception error or these kinds of things. So imagine like, I don't know, 10k of metadata you're trying to deploy, right? So it's very painful to work with that.

But I really, when I saw that, I thought that's the way to go. Really trying to push it. But it was a little bit painful in the beginning. And thanks God now it's working very well and we can see a lot of success. And I think that's the way to go.

Harald (12:50)
And so, yeah, you already mentioned the exit scale recently rebranded to flexible. So, yeah, I think you joined that community or that open source project probably already in its early days. Maybe you can tell us a bit how this evolved.

Dieffrei Quadros (13:09)
Yes. All right. So yeah, my contact with flexible, the former DXXK was very interesting because in 2018 I moved to Netherlands just to have the opportunity to work abroad. It was one of my dreams. Now, so to speak in English. And then it was very cool because the first project that I worked was for a company that they really focused on to build the things properly.

And we used a lot of DX at Salesforce DX and also packaging. And we learned a lot. Things to do and not to do as well. For instance, like to use a lot of namespaces and then when you need to do some data migration, it's very painful when you're doing this. So this is just a warning for, or a disclaimer for everybody that be careful if you are thinking to decouple your domains using namespace.

But going back to the point, my involvement with the XSK was that I was working for the company, the first customer of the outsourcing company that they used to work for. And then I really liked to work in the company, but then my contract ends and then my former manager moved to another company.

And then I texted him, hey, I really want to start to keep working with you because I really like your leadership, et cetera. And I really liked the way that he gave me flexibility and budget to work with nice tools. And also I saw the impact that when you are using the proper tools and techniques, right? It how the way it impacts the results of the company. And then I was hired to work with him in this new company. In that time he moved.

the position from manager to CTO of the company. And my biggest challenge was to move or rebuild from the scratch seven years old, sorry, production work that was very painful. When you open the triggers, for instance, you just saw the logic there. There's no tests or the minimum test is enough. You could see a lot of, I think 99 % of the...

the bad practice that you can imagine I found there. And he understood and he said that, okay, so maybe to rebuild from this, sorry, to fix that org is gonna take a lot. So maybe it work if we just start from scratch. And then it was very fun because this was the first contact that I had with Huty. And also with, yeah, the exact scale and...

former DexSK, it was another company, then I'm going to reach out to that point later. But with HOOTI, it was like that. So I joined the company. And I think the first really difficult point for me was to convince the consulting company in how was the setup of the Salesforce team. My CTO hired me.

to lead that development. But we already had a consulting company with some developers and one architect from them as well help and they already started to build something. And they were basically using art -based development, change sets, et cetera. And then the release was a little bit painful. It was working in the beginning, right? And it was one of the first questions that they had. Okay, why we are gonna change something that is already working? And I say, okay, it's fine.

But we are thinking for the future, maybe in one, two, three years, when the company get bigger and bigger, how we are gonna, it should be scalable. Maybe it was working very good for that size of the company, but think for the future. And my CTO already know our experience in the past, the way to go. So that was very good. And it was very nice because the leadership really understand where we should go.

leadership needs, where we need to go. And then he gave me the power to, okay, so let's go, let's use scratch orgs, let's use packaging, et cetera. And then we achieved a lot. So it was very good. But as we know, one of the very painful part of DevOps in that time was scratch orgs. Scratch orgs was very cool because you just create from the source, right? It's a source -based development.

However, the time to create the scratch error, it was very long because we were using the CPQ. So like in the beginning used to take like a third five minutes to install the package. But after that 45 minutes and then in during the release period of Salesforce used to take like that, I don't know, two hours, two hours and a half. And then some package that used to take like, I don't know, a half minute used to then sometimes it took.

like 15 minutes, et cetera. And then I was thinking how we can fix that. And I was thinking about this scratch art pooling. And I thought, okay, so let's create a Node .js microservice just to, you know, I can just pass the dev hub and some basic information and then we can create a pool of scratch arts. But when I went to the Twitter, I don't remember who posted something, but I remember that somebody posted about Wootie. And I say, Jesus, exactly what I'm looking for.

So that's the way that I got in contact with Abigene and I think it was a former developer, Tiago. And then I was introduced for this tool, amazing tool that we start to use. For pooling, another thing is because the developers, even the developers of that consulting company, they didn't like to use Git. Actually, they didn't know how to use Git. And then I thought, how we are gonna do that? And my CTO said, okay, I really...

like CI -CD, I like the search -based development, et cetera, when we need to find a way to support them. And then HOOTY also was very nice for that feature that allows that who doesn't know or doesn't have enough knowledge about the command lines, just you go to HOOTY and then it just click, and you can log in in another sandbox, you can create your own sandbox, you can create...

access the pools, et cetera. So who allows us to, how can I say, allow not just developers, but also administrators, everything work together. Because I think that's the main point for a lot of company. So when I talk about Salesforce, they say, yeah, but you know, we need to use a lot of CLI, we need to use a lot of Git commands. And we are just, we just have most of

I don't know, 67 % of the team, they are administrators. How we can do that? So HOOTI, I think is that way that you can do. So you can leverage HOOTI and also flexible.

Harald (20:36)
Yes, thank you very much for this credit. So indeed. So you had been very, very early in finding HUTE when it wasn't really a product, a proper product. Let's say it was, it's no secret that HUTE spun out of an ISV where it was built to address the...

Dieffrei Quadros (20:36)
Yeah, so.

Harald (20:59)
own pain points of that team. And I think your first touch point fell already in that time. So before Hute was even founded as a company. But yeah, I think you summed it up very well. And that's still our main mission, I think, to allow teams to follow a proper development life cycle, which is still not excluding the less technical team members. So no one needs to install DLI, maintain it, use it.

Dieffrei Quadros (21:25)
Yeah.

Harald (21:29)
or even an IDE because an IDE like VS Code is not a natural environment for an admin maybe who really prefers doing a work inside the org. Yeah. And I hope we address this gap very well that this admin can then from an ICE interface, which has evolved a lot since that early days can basically pull, we call it pull changes. So take the source, the metadata.

and put it into version control without being familiar in -depth with Git or having to worry about branching strategies or anything like that.

Dieffrei Quadros (22:08)
Yeah, and you know, one of the things, another thing that I like about Huty, that is flexible, right? I'm not talking about the framework right now, but it's flexible with the ML, you can create the buttons, you can do a lot of things. So I had a lot of fun with Huty in that time. And then, sorry, because I missed the point to talk about flexible, right? You know, what was my involvement with that amazing framework that I'm one of the maintainer. So in that situation, Harold,

After one year of that project, it's running very smoothly. We are releasing weekly in that time because it was like a small team. Then what we did was actually what happened is that after one year of the project, that company was acquired by another large company. So that company, they were acquiring a lot of companies. In two or three years, they acquired like, I don't know, four or five different companies.

Harald (22:45)
you

Dieffrei Quadros (23:07)
And the interesting part that every that company's company that was acquired acquired, they had one Salesforce org and also internal team. So, and then when I moved to this new company for this new structure, my challenge was, okay, so we had one team that company was, they were, they were working well, delivering fast. But then when they acquired all those companies with different teams and they had to merge those

orgs into one and then also they had to keep the velocity right then it was the challenge and then my first challenge was okay so we need to make this scale scalable and now we don't have anymore just one team but we have five six seven teams how we are gonna do that how we can keep the value stream really flowing to production

And that was the way that I had some contact with flexible. First thing I thought, okay, so we have to have the modularity. So this org is just had soup, you know, everything connected. We cannot, for instance, when you are working in the sales domain and you are working the service domain, sometimes you just need to do a report, create a report and deploy to production. Why we need to wait, I don't know, one week to deploy reports.

So I was thinking to modularity, I started to create some draft of the solution. And then I went again to Twitter and then I don't remember, but I was asking something for the community, the way to go, or I had some questions about specifically for the Paxi -Quant or stuff like that. And then I think Asma reached out to me and say, do this. And I didn't understand anything what he said. But then he...

text me again, explain a little bit, and then I start to, Jesus Christ, that's the way to go. And then I remembered that we had the first time with NEPM artifacts, and that's the way that I got very involved. And then just to make this story short, because it's a long story. So in the end, we had like multiple teams releasing daily. Can you imagine like you have like six, seven Salesforce teams deploying two or three times a day? It's insane. For instance, okay, I need a new report.

In production, you just really quickly create the report and deploy. You don't need to wait hours for another domains. So decoupling the domains, having this modularity guided by a flexible framework was really amazing for us. And that's the way it was very, what was good that we had the data doc, the observability tools. So we could really show to the leadership that the budget and the time that they spent refactoring or modularity.

modularizing really worth it. You could see the picture, the snapshot when we start the day one, we just had like a big one package into hundreds, 150 packages that we have in India that allow us to deploy many teams or many different domains decoupled and deploying every day. Sorry to the long story.

Harald (26:22)
Awesome. No, no, it's very interesting. And so you basically, you came from discovering this open source initiative to become a user. And then eventually I assume a contributor. So you probably started taking things in your hand and instead of creating issues, creating pull requests and make your own improvements. Is that correct?

Dieffrei Quadros (26:44)
Yeah, exactly. So then you start to use and then, okay, but what if we have this in the basic? I don't know. Since I start to use the X at scale now flexible, I think they basis I used to talk, okay, man, what, what if, because I think I really like to think out of the box or think about new ways to do. And, and he's a very smart guy and like, okay, what if you do that? But we are.

Yeah, but maybe we should go in that direction. What if we had these mold and et cetera? Because when you are working on a small project, maybe you don't see all those painful points that you're gonna have in the future. And with Flexbo, yeah, for instance, one of the things that, like in the time that I was working for this project that we contribute was,

about permission set groups that I don't remember in that time it was documented. But for instance, when you're deploying and you are thinking about modularity, you can, you think about feature -based packages, right? And then when you're thinking about feature -based packages, you also thinking about the granularity of the permission sets and permission set groups. And when you're deploying a permission set, sometimes the permission set group got recalculated.

And then if you just try to deploy many packages, like if you deploy one package and it changes a permission set, and then in another second you just try to deploy, maybe depends of the impact of the permission set groups that you have, it can fail. And then we built some way, basically I submit like a pull request that you could just...

retrieve the metadata, check the status of the permission set group, and just deploy the another packages just when the permission set groups got calculated. These kind of things, right? So that was the first involvement that I had with Flexible. And nowadays I became one of maintainer. Of course, it's open source. It's a struggle because I have my job and then I have to do it in the free time that I have.

So I need to share this time with my family, my daughter, my girlfriend, but that's the life.

Harald (29:12)
Great. So yeah, I could go on and on and I think this will end up in a second episode, re -inviting you as a guest. But yeah, for today, I think I'd like to wrap up. Thanks for... Yeah.

being a loyal supporter somehow to Huth as a user who also gave us important feedback. Thanks for contributing to the open source community in your role at, or basically as a part of the, one of the maintainers of the awesome flexible stack. And yeah, it was a huge pleasure talking to you. Thank you so much. And the one last call out, we will put it in the, in the article.

we publish with this, you, Jeffrey, did an awesome article about scratch orgs or even a serious, I think on medium, right? On the pros and cons of scratch org based development versus sandbox based development. And actually I didn't tell you Jeffrey, but I refer to it quite frequently because I, in my work, I have a lot of conversations with team who question their status quo of their development life cycle. And quite often the question comes up since who they support.

supporting both Scratchic or DevSendbooks based development. Quite often the question comes up, mostly it comes from teams who work with Sandbox based. Well, what are the benefits? Should we consider switching to Scratchic? And then I typically point them. I Google the article, your article, and then I send the link because I think it gives a great nuanced look at the whole topic. So also thank you for...

Dieffrei Quadros (30:47)
Hehe.

Harald (30:55)
for sharing that know -how and your own experiences in transitioning.

Dieffrei Quadros (31:01)
Thank you so much, Harold, for the opportunity. I appreciate it. Yes, sometimes I'm fighting to myself because I really would like to have more time to write articles and these kind of things. Probably we are going to spend more time writing about how to use also the snapshots and also the modularity, that's the way to go. So just, if you need me, just reach out and also for all the community. I'm really happy to.

contribute or help anybody that needs. Thanks so much.

Harald (31:34)
Thank you.

Here's the stop button.