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

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.

  • Published 14 Jun 2024
  • 9 mins read
How to deliver first and explain later in Salesforce DevOps (Trails Podcast episode #15 with Diéffrei Tiepo de Quadros)
Table of contents

Episode 15: Diéffrei Tiepo de Quadros, Salesforce Technical Architect

Article Highlights
  • Hutte simplifies sandbox creation and management. It allows non-technical team members to easily create and access sandboxes with a single click, eliminating the need for complex CLI and Git commands.
  • With Flxbl (formerly DX@Scale), multiple teams can deploy independently and frequently, decoupling domains and maintaining velocity even after merging multiple companies. This modularity ensures swift and efficient report creation and deployment.
  • Engaging with the Salesforce community on platforms like Twitter and adopting Flxbl enabled the creation of feature-based packages and advanced permission set management, leading to continuous improvement and open-source collaboration.

Listen up 🎧

Tune in 🎬

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

First, I appreciate the work you have done with Hutte. I like the product because I was one of the first customers or beta users, so I love what has been done to it so far. I also appreciate the impact that Hutte has had in the ecosystem as far as DevOps is concerned.

But talking a little bit about my career, I think my first contact with Salesforce was in 2008 when I came to my former manager and asked to work with something different. I was slightly saturated with the technologies they had been working on, like Java. And then she said, "All right, I'm going to give you a new opportunity. We just had some engineers come from San Francisco, and they learned some new technology."

I was excited and curious to understand this new technology. In my company, when I created a field and added an edge to the report, it cost about $3K. I heard that I could do it very quickly with the new technology and platform without spending much money. That's how I joined Salesforce by working for an ISV. It was for fleet management, and I learned a lot. After that, I went to the open-source community and discovered they could use MavensMate with Sublime, which immensely helped me.

Another contact I had in the open-source community during that time was using ANT Migration Tool, but I didn't enjoy it as much. I then found another excellent repository. I think it was from Matthias (Salesforce DevOps Consultant, product supporter for Hutte, and future Trails Podcast guest). As far as I remember, he created a repository called "force-dev-tool." It's already archived, but it helped a lot.

I also spoke with him briefly on Twitter (X). I like Twitter because I contact the product teams from Salesforce when I need something. It's a faster way to do that.

Coming back to the point of my career, I moved to consulting. I worked on many large projects, but it was painful from a DevOps perspective. We used to utilize change sets, and we would spend six months developing everything in there. At some point, we just deployed UAT. Maybe one week before we went live, we would have ten engineers in a war room trying to create code coverage to deploy. It was a kind of integration test.

We didn't use that trick of adding a lot of 'i++' in the code. We would say, "Okay, let's create code coverage because the deadline is almost here, and we need to deploy to production." I was slightly frustrated because I already had some background in Java and other technologies. I saw that the Salesforce platform was very behind.

I tried to think about CI/CD automations. It was a bit hard initially to convince my team, as we didn't have Trailhead. We had Salesforce documentation. I started to look for more information to convince them. I always work in the same way. I use this strategy to deliver first and then explain later. I think that's how I achieved most of the things in a lot of successful cases in this situation specifically. 

Around 2015, I traveled to Europe. It was my first project abroad. My team arrived to work for a month. In that month, we spent a lot of time building new functionality. We finally reached the last week and allocated time to plan to do the deployments and change sets.

One day before the deployment, my team went to the grocery store. We bought a lot of chocolate and coffee. Everybody was prepared to start creating and deploying the change sets, but the deployment was already done. I then introduced them to the way that they could do it. It wasn't CI/CD. It was using scripts from Force Dev Tools.

Everybody was shocked as we deployed everything in half an hour, and only minimal configurations were left to do. Management then invested the money and gave me some budget to apply CI/CD, which improved the Salesforce lifecycle and the value of the consulting firm.

Did you have a specific job title as a DevOps or release manager, or were you one of the developers on that team and took the responsibility to improve the delivery methodology?

When I moved to that consulting firm, I moved as a Salesforce Technical Architect. I was leading the development of best practices. At that time, I only knew a little because my background was more Java-based. When I learned from Salesforce, they'd mention tests. But there are many tests, like unit, integration, and end-to-end tests.

Author's note: Did you know that Salesforce requires a minimum of 75% code coverage by unit tests for deployment to production? However, many best practices suggest aiming for higher coverage, often around 85-90%.

You need to understand when you will use them, how you will run them, which stage of development you can run them, etc. So, I didn't move to the Salesforce ecosystem without this knowledge. A lot of the knowledge I got was through learning what didn't work. I didn't find any documentation. I think my primary source was Jeff Douglas' blogs.

I think in 2018, SFDX became generally available. I assume you were an early adopter?

I think it was in 2013 when I remembered that the FinancialForce library was launched. But talking about Salesforce DX, I got very excited trying to find the link and install it. I remembered that they were working on one large project. Whenever I used a command to deploy the code to a scratch org, I got a non-descriptive error. Imagine you have 10K of metadata you're trying to deploy. It's very painful to work with that. But when I saw that, I thought that's the way to go.

Can you tell us how Flxbl (formerly DX@Scale) evolved?

My contact with Flxbl was interesting because, in 2018, I moved to the Netherlands to have the opportunity to work abroad. It was one of my dreams. The first project I worked on was for a company that focused on building things properly. We used a lot of Flxbl, Salesforce DX, and packaging.

We learned what to do and what not to do. For instance, when you use many namespaces and need to do some data migration, it's excruciating. So, this is a disclaimer to be careful if you are thinking of decoupling your domains using a namespace.

But going back to the point, my involvement with Flxbl revolved around working for the first customer of the outsourcing company that they used to work for. My contract then came to an end, and my former manager moved to another company.

I texted him: "Hey, I want to keep working with you because I like your leadership." I liked how he gave me flexibility and budget to work with excellent tools. I also saw the business impact of using the proper tools and techniques. I was then hired to work with him in this new company. At that time, he moved from a manager position to the CTO of the company.

My biggest challenge was to move or rebuild the production work from scratch. For instance, when you opened the triggers, you saw the logic there. There were no tests, or the minimum test was enough. You could see 99% of the bad practices you can imagine there. My boss understood that, and he said: "To fix that org is going to take a lot. It will maybe work if we just started from scratch." This was the first contact I had with Hutte and DX@Scale. 

My CTO hired me to lead that development, but we already had a consulting company with some developers and an architect who was already building something. They were basically using things like change sets, and one of the first questions they had was:

  • "Okay, why are we going to change something that is already working?"
  • I said, "It's okay, but we are thinking about the future when the company grows. How are we going to be scalable? Maybe it was working well for that size of the company, but think about the future."
  • My CTO already knew about our experience and the way to go. So, it was terrific that the company's leadership understood where we should go.

My manager gave me the power to use scratch orgs, packaging, etc. As we know, one of the very painful parts of DevOps used to be scratch orgs. Scratch orgs were fantastic because you just created them from the source. It's source-based development. However, the time it took to create the scratch org was long. In the beginning, it used to take thirty-five minutes to install the package. But during the release period of Salesforce, it took two and a half hours.

Do you want to know about some more pain points when using Salesforce scratch orgs?

  1. The initial setup and configuration of scratch orgs can be time-consuming, particularly for complex projects.
  2. There is difficulty in seeding scratch orgs with necessary test data, which can slow down development and testing processes.
  3. Scratch orgs come with limited storage, which can be insufficient for large projects or extensive testing needs.
  4. Ensuring consistency across multiple scratch orgs can be challenging, leading to discrepancies and potential integration issues.
  5. Managing the lifecycle of scratch orgs (creation, usage, and deletion) can become cumbersome, especially in large teams.
  6. Performance can degrade over time, impacting the efficiency of development and testing activities.

I was thinking about how we could fix that, so I started thinking about scratch org pooling. I considered creating a “Node.js” microservice to pass the DevHub and some basic information. When I went on Twitter, I remember somebody posting about Hutte. I contacted Evgenii (flair's CEO) and a former developer and was introduced to this fantastic tool we could start using. Regarding pooling, developers didn't like (or know how) to use Git.

Read more: Are you in the dark when it comes to Git? Download our starter guide to Git-based development.

My CTO really liked CI/CD, and Hutte was perfect as it allows those who don't know or have enough knowledge about the command line to go to Hutte, click a button, and create sandboxes or access sandbox pooling. I think that's the main point for a lot of companies. When I talk about Salesforce, they say, "We need to use a lot of CLI and Git commands. And 67% of the team are administrators. How can we do that?" I think you can do that with Hutte and Flxbl.

After one year of the project with Flxbl, it ran smoothly. We released weekly as a small team. After one year of the project, another large company acquired that company. In two or three years, they acquired four or five different companies. When I moved to this new company for their new structure, my challenge was that we had one team working well and delivering fast. When they acquired all those companies with different teams and merged those orgs into one, they also had to keep the velocity.

My first challenge was to make this scale scalable, as we no longer have just one team. We have seven teams, and I needed to figure out how to keep the value stream flowing to production. That was how I had the initial contact with Flxbl.

The first thing I thought was that we had to have modularity. When you are working in the sales and service domain, for instance, sometimes you just need to create a report and deploy it to production. I started to create a draft of the solution. I went to Twitter again and asked the community which way to go, and that's how I got very involved. To make this story short, we had multiple teams releasing daily. Imagine having seven Salesforce teams deploying two or three times a day. It's unbelievable.

For instance, if you need a new report in production, you can quickly create the report and deploy. You don't need to wait hours for other domains. Decoupling the domains and having this modularity guided by a flexible framework was amazing for us. It was good that we had the observability tools as we could show leadership in the company that the budget and the time they spent on refactoring or modularizing was worth it. We had one big package split into 150 packages that allowed us to deploy many teams or different domains, decoupling and deploying every day.

You probably started taking things into your own hands, creating issues, pulling requests, and making improvements, right?

Exactly. Since I started using Flxbl, I have liked thinking outside the box and finding new ways to do things. When working on a small project, you might see only some of the pain points you will have in the future. With Flxbl, you can think about feature-based packages when you're deploying and thinking about modularity.

When considering feature-based packages, consider the granularity of the permission sets and groups. When you're deploying a permission set, sometimes the permission set group gets recalculated. If you deploy one package and it changes a permission set, and then in another second, you try to deploy, depending on the impact of the permission set groups you have, it can fail. 

I submit a pull request where you can retrieve the metadata, check the status of the permission set group, and deploy the other packages just when the permission set groups get calculated. So, that was the first involvement I had with Flxbl. Nowadays, I am one of their maintainers as it's open-source. It's a struggle because I have a job and have to do it in my free time. So, I need to share this time with my family, daughter, and girlfriend, but that's life.

It’s all in the delivery

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: 10 Jul 2024