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

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

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."

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.

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.

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 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.

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.

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.

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.