Hutte Trails Podcast – A podcast about all things Salesforce

Why Salesforce DevOps Consultants should be near user problems (Trails Podcast episode #16 with Matthias Rolke)

• Hutte • Season 1 • Episode 16

Share episode

Join us in this episode as we delve into Matthias Rolke’s perspective as a Salesforce DevOps Consultant. We talk about the importance of being close to user problems. Explore his journey, gain insights, and discover valuable tips.

Harald (00:01)
Hey Matthias, you'll hate me for this introduction because you are a humble person, but you are a legend in Salesforce DevOps and certainly one of the most knowledgeable people in the world when it comes to all the tricky details of deploying Salesforce metadata. Please tell us how this happened.

Matthias Rolke (00:25)
Yeah, thanks Harald. That must mean I'm an old man in the meantime, having so much experience. But yeah, I mean, do you want to hear my full Salesforce journey and how it came to that point?

Harald (00:41)
Absolutely. How did you get in touch first and how did it evolve from there?

Matthias Rolke (00:50)
Yeah, so I mean, Salesforce, I didn't know Salesforce before, but I was studying computer science in Munich and was always a working student. So for my bachelor's, I worked at a Linux distribution. This is basically where my whole knowledge of command line tools and open source comes from. And in the master studies, I was looking for a new job.

And, at that time, many interesting companies were far outside of the city center. So I did a nearby search and found a Salesforce as I partner consulting partner called parks. And yeah, this is where I landed my job and stayed there for seven years, starting as a Salesforce developer doing apex, visual force, aura, and.

Very soon I basically found that the development tools which existed back then, so that was in 2011, were a nightmare. So there was the Eclipse based force .com IDE, which was slow. And yeah, that was for deployments only change that obviously and the end migration tool.

and that quickly became my passion to look into those things.

Harald (02:23)
So you haven't been really put into a role of a, or hired into a role of a DevOps or release manager or so, but it came basically during the job as a developer, right?

Matthias Rolke (02:39)
Exactly. Yeah. So, first, for example, with the IDE, there was a, a new, so my, my role was developer, but I hated basically how I had to do those things. Right. I loved the platform, but, I hated using Eclipse and stuff like that. So there was a cool, alternative IDE called Maven's Mate by Joe Ferraro, but it, it.

was only for Mac OS and my computer was a Windows PC at home. I was running Linux and so I just ported for myself, this Maven's mate to, to, Windows and Linux. And yeah, that was basically also when I did my first pull request ever on GitHub.

and it was also rejected. So my first experience with open source was a really bad experience. I can't blame him because he rewrote the whole tool to switch to Python instead of Ruby. So not his fault. But yeah, I really liked basically looking into open source tools and that was my...

passion basically from day one and that's how things evolved that more and more I basically switched to the deployment release management side of things at my role.

Harald (04:25)
And what was your stack back then for deploying or releasing? So did you use this end migration tool, which I don't know personally, so I never touched upon it. Was that your default?

Matthias Rolke (04:42)
No, the default in the company was change sets. And basically I only for myself explored how I could enhance that. And with the end migration tool and package XML deployment, I found out that it's possible to create an outbound change sets in the UI and then deploy to your sandbox.

with a package XML referring to the outbound change set name and that you basically were able to add the metadata components based on a package XML file, which was more, like what I, I wanted to have. And so I basically improved my, my process, from time to time to be faster to leverage Git for myself.

And later on, basically this, I was able to bring this into the company.

Harald (05:46)
And was that what you then open sourced as the force dev tool?

Matthias Rolke (05:54)
That came later. So in 2014, it was time to write my master thesis. And I was really in love with this topic. So I suggested this topic and the end result of my master thesis actually was a tool called force dev tool. This is what I developed in my...

master thesis and, yeah, so did two main things that I explored in my master thesis was writing a CLI, which didn't exist back then. So there was the end migration tool and later on, or at the same time, also to court DMC by another guy and.

Having a CLI was just so essential that you could automate things because and wasn't so scriptable at all. And the other outcome of the thesis was implementing CI, CI CD with Salesforce. And here I explored implementing CI by doing validation deployments to an empty sandbox.

So basically you have your metadata in your Git repository. And as part of the CI job, you do a full validation deployment, including test run to an empty sandbox. So I had to prepare a sandbox by deleting all metadata. And I also used my own tool to do that. And yeah, this was a huge step, I think forward because yeah, previously you couldn't.

have any kind of validation for your CI pipeline.

Harald (07:56)
And then again, a bit fast forward Salesforce released something called SFDX, which included a command line, probably the first one that Salesforce, yeah.

published or made accessible. So can you maybe share a bit your perception and memory about what this launch of SFDX, it was not only about the CLI that also I think included just the launch of Scratch Orgs. So yeah, please share a bit your memory and perception of what that brought and how that changed since first DevOps.

Matthias Rolke (08:39)
Yeah, that came really as a huge surprise to me. I think it was Salesforce DX was announced at Dreamforce 16. And so this was after my thesis. And yeah, it came really out of nowhere, I have to say. And the CLI back then was, well, I would say slower than my tool.

But the huge, huge thing was, as you just said, scratch orgs. And this basically blew my mind because this is something I explored for CI, like having a clean or empty org. And I basically knew the benefits of having that, but not for development. So when scratch orgs really basically allowed you to get your own empty org.

for development as well, which wasn't possible in my world before. And so I was hooked. I participated in the pilot and knew that basically my first dev tool was eventually going to be deprecated. Of course, but I embraced Salesforce CX completely.

Harald (10:09)
And yeah, I think you also then continued building on that new opportunities that the CLI and the ability to build plugins to the CLI. Yeah, you used that and released at least one, I know the browser force, but probably more.

Maybe you can share a bit about your open source work on the generation of, let's say, SF CLI, SFDX, SF CLI.

Matthias Rolke (10:47)
Yeah, I mean that comes a bit back to my job and how I was also working at this SI and later on as an independent DevOps consultant. So I really like to have problems firsthand at the customer and the more the better.

So that I was able to know where, what things don't work currently. And, this was always a kind of, good, point of getting ideas for open source projects. And so one of that was, SFDX browser force plugin, which basically where I was trying to fill the gaps of the metadata API.

with browser automation. So really doing the clicks in a scripted headless browser and yeah that turned into a huge success for myself and for our project because then we were really able to automate the missing pieces and without that I think we wouldn't have been able to do that.

Harald (12:11)
Yeah, I can be testimony to it because we had been and that was before our collaboration at HUTE which goes on to today. Yeah, we had been in such a situation. We had been an early adopter to scratch orgs, but there had been gaps that prevented us to bring it was an ISV back then and it prevented us to...

Yeah, do what we wanted to do, basically push our entire package source to a scratch org in order to run CI CD. And yeah, the browser force plugin came to the rescue, closed an important gap or a complete roadblock actually. And I think in the meantime, is that correct that Salesforce has closed many of these gaps so that basically, yeah, most...

Most org shaping or preparation that you want to do today, you can solve with deployments or APIs, but there are still remaining gaps, right? So I think browser force is still alive and used.

Matthias Rolke (13:27)
Yeah, that's correct. So, I mean, there has been a huge initiative to close those gaps. and I really appreciate that. And, yeah, there's some edge cases require a browser automation. that's for sure.

Harald (13:45)
Yeah, I'm going a bit back to your career in the Salesforce ecosystem. You already mentioned that today you are working as a freelancer, independent Salesforce DevOps consultant, as well as dedicating part of your time to Hute. So it's no secret that you have been key to getting the product to where it stands today, for example, by guiding our engineers through the

Salesforce API jungle and many more contributions. So yeah, maybe you can share a bit about your choice to split your work and between basically being independent, taking different customers, but also continuously helping us on the product.

Matthias Rolke (14:42)
Yeah, I think I really need this variety of being a firefighter when things don't work and being able to build something and that on both ends, like on the client side and on a basically product side. So I really enjoy having both.

participating on both ends. That makes me really happy to see as many problems as possible. I think I have a passion for diving into problems, reporting bugs, making them reproducible. Yeah, this is part of my job and I enjoy that.

Harald (15:38)
We are very lucky that you enjoy that because you're running a DevOps product which heavily builds on the Salesforce CLI, not exclusively, but to a relevant part.

Yeah, it also brings us to the situation that sometimes a customer or user of ours reports a bug to us that we can then trace back actually to the Salesforce CLI. And I think you have earned yourself already quite a reputation in doing very diligent.

bug reports to the CLI team and also seeing quite a successful pickup by that team of issues that you report. So I think it's a very fruitful collaboration with the Salesforce team owning the CLI.

Matthias Rolke (16:31)
Yeah, that's a great way. Like the Salesforce CLI team is really open. They have a Slack channel and they really respond to GitHub issues. That's really, yeah, I only have praise for them. It's really great.

Harald (16:51)
So yeah, rounding up this interview, which I really enjoy. Do you have any projects ongoing basically in Salesforce open source, anything we can expect or enhancements to existing projects you are involved, anything you are ready to share?

Matthias Rolke (17:15)
Yes, indeed. So the SF plugin ecosystem is quite good. So there are the well -known plugins from Techay and Hardis and SFDX Git Delta. And most of them I discovered from the awesome list of SFDX plugins by Shane McLaughlin.

which is a Salesforce employee. So this is a handpicked list. But I think there is more that are more awesome plugins, which are not known. And I explored basically building a website to explore the plugins so that you are able to search for plugins you need.

And this is my current project and I'm looking forward to, yeah, it's already public, but I'm looking forward to get some users and more feedback on that. So the name is SFPluginExplorer and you can find it in my GitHub repo Amtrak. So I'm really...

looking forward to get feedback because I used it for myself to find useful plugins already and it helped me a lot. And yeah, just.

Harald (18:53)
Awesome. So we had talked about it briefly. You shared once this idea with me, but I had no idea that it's already basically launched. So did you buy a domain? Is it reachable under that domain or do I have to check out your repo and run it on my machine to access it?

Matthias Rolke (19:12)
It's a website published with github pages. So my goals for this project was that it shouldn't cost anything and it should be basically as simple as possible. So right now it looks really bad on purpose because I first want to improve the data and make it pretty later on and...

If that basically turns out to be a success, I will think about buying a domain. Yeah. But right now it's hosted for free and with the least amount of effort as possible.

Harald (19:57)
Awesome. So I'll check it out right away after finishing this podcast and encourage everyone to do so as well. So, yes, thank you very much, Matthias, for taking the time and see you soon on our collaboration on HUTE.

Matthias Rolke (20:19)
Thank you Harrod, pleasure to talk to you.