Why Salesforce DevOps Consultants should be near user problems (Trails Podcast episode #16 with Matthias Rolke)
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.
Starting as a computer science student in Munich, Matthias' journey into Salesforce began serendipitously through a local consulting partner. This led to a seven-year tenure and a passion for development tools.
Faced with slow and cumbersome development tools like the Eclipse-based Force.com IDE, Matthias was driven to improve the process, eventually open-sourcing tools like "force-dev-tool" during his master's thesis.
The release of Salesforce DX and Scratch Orgs revolutionized Matthias' approach to development, aligning perfectly with their passion for open-source solutions and leading to the development of innovative tools like the SFDX browser plugin and the "sf-plugin-explorer" website.
Tune in 🎬
Listen up 🎧
How did you get in touch with Salesforce first, and how did it evolve?
I didn't know about Salesforce before, but I studied computer science in Munich and worked as a student. For my bachelor's, I worked at a Linux distribution company. This is basically where my knowledge of command-line tools and open-source comes from. During my master's, I was looking for a new job. At that time, many interesting companies were far outside of the city center. I searched nearby and found a Salesforce consulting partner. This is where I landed my job and stayed there for seven years, starting as a Salesforce developer doing Apex, Visualforce, and Aura.
🐌
I quickly learned that the development tools that existed back in 2011 were a nightmare. There was the Eclipse-based Force.com IDE, which was slow. That was for deployments only and the end migration tool. That quickly became my passion to look into those things.
So, you weren't hired into a DevOps or release manager role, but it came during your job as a developer, right?
Exactly. For example, I hated how I had to do those things with the IDE. I loved the platform, but I hated using Eclipse. So, there was an excellent alternative IDE called MavensMate by Joe Ferraro. It was only for macOS, and my computer was a Windows PC at home. I was running Linux, so I just ported the MavensMate to Windows and Linux. That was also when I did my first pull request on GitHub, which was rejected. So, my first experience with open-source was horrible.
I can't blame Joe because he rewrote the whole tool to switch to Python instead of Ruby. But I liked looking into open-source tools – that was my passion from day one. I then switched to deployment release management.
Did you know that over 70% of Salesforce customers actively use or contribute to open-source tools to enhance their Salesforce implementations?
What was your stack back then for deploying or releasing? Was that your default?
No, the company default was change sets, and I explored how I could enhance that. With the end migration tool and package XML deployment, I discovered that creating outbound change sets in the UI is possible. You can then deploy them to your sandbox with a package XML referring to the outbound change set name. You were able to add the metadata components based on an XML package file. I improved my process from time to time to be faster and leverage Git for myself. Later on, I was able to bring this into the company.
Was that what you then open-sourced as the "force-dev-tool?"
That came later. In 2014, it was time to write my master's thesis. I was really in love with this topic, so I suggested it. The end result was a tool called "force-dev-tool." This is what I developed in my master's thesis. In my master's thesis, I was writing a CLI, which didn't exist back then. But there was the end migration tool. A CLI was essential to automating things because it wasn't so scriptable. The other outcome of the thesis was implementing CI/CD with Salesforce. I explored implementing CI by doing validation deployments to an empty sandbox.
💬
Your metadata is in your Git repository. As part of the CI job, you do a full validation deployment, including a test run to an empty sandbox. I had to prepare a sandbox by deleting all metadata and using my own tool to do that. This was a huge step because, previously, you couldn't have any kind of validation for your CI pipeline.
Salesforce then released SFDX, which included a command line. It was probably the first one that Salesforce published or made accessible. Can you share your perception and memory about the launch of SFDX and Scratch Orgs? Also, how did it impact DevOps?
That came as a huge surprise to me. I think Salesforce DX was announced at Dreamforce 16. This was after my thesis. It came out of nowhere. Back then, the CLI was slower than my tool. The massive launch was, as you said, Scratch Orgs. This blew my mind because I explored this for CI, having a clean or empty org. I knew the benefits of having that, but not for development. Scratch Orgs allowed you to get your own empty org for development, which wasn't possible in my world before. I was thus hooked. I participated in the pilot and knew that my first dev tool was eventually going to be deprecated. I embraced Salesforce DX completely.
Can you share a bit about your open-source work on the generation of Salesforce CLI and SFDX
That comes back to my job, where I worked at the SI and later as an independent DevOps consultant. I like to see problems firsthand with the customer – the more, the better. I was able to know what things don't work currently. This was always a good point for getting ideas for open-source projects. One was an SFDX browser plugin, filling the metadata API gaps with browser automation. You could perform clicks in a scripted headless browser, which was a massive success for our project. We were able to automate the missing pieces.
You mentioned that you are an independent Salesforce DevOps Consultant, dedicating part of your time to Hutte. It's no secret that you have been vital in getting the product to where it stands today. Please share a bit about your choice to split your work
I need a variety of things that need to be fixed. Being able to build something on both ends – the client and product side. I enjoy 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, and making them reproducible. This is part of my job, and I enjoy it.
Do you also have a passion for picking up problems? Here are some tips on how to spot Salesforce bugs:
Monitor user feedback: Pay attention to user-reported issues or complaints.
Review error logs: Regularly check Salesforce logs for anomalies or recurring errors.
Test edge cases: Validate Salesforce functionalities in various scenarios, including boundary conditions.
Compare expected vs actual results: Ensure outputs match intended outcomes during testing phases.
Check integration points: Verify data consistency across integrated systems or modules.
Utilize debugging tools: Leverage Salesforce debugging tools like Developer Console or Debug Logs for insights.
Sometimes, a customer or user reports a bug that we can trace back to the Salesforce CLI. I think you have already earned yourself a reputation for diligently reporting bugs to the CLI team. I think it's a very fruitful collaboration with the Salesforce team owning the CLI
The Salesforce CLI team is really open. They have a Slack channel, and they respond to GitHub issues. I only have praise for them. It's really great.
If you regularly use GitHub, here are some best practices:
Use branches: Work on features or fixes in separate branches to isolate changes.
Commit regularly: Make small, atomic commits with clear messages to track changes effectively.
Pull requests: Use pull requests for code reviews, discussing changes, and integrating features into the main branch.
Write descriptive comments: Explain the "why," not just the "what," in your commit messages and pull request descriptions.
Use issues: Track tasks, enhancements, and bugs using GitHub Issues to manage project workflows effectively.
Review code: Participate actively in code reviews to maintain code quality and share knowledge.
Automate testing: Integrate automated tests into your workflow using GitHub Actions or other CI/CD tools.
Documentation: Maintain clear and updated documentation in your repository's "README" and Wiki pages.
Manage permissions: Grant appropriate permissions to collaborators and contributors based on their roles.
Monitor security: Regularly review and update dependencies and enable security alerts for vulnerabilities.
Do you have any ongoing Salesforce open-source projects?
The Salesforce plugin ecosystem is quite good. There are well-known plugins from "sfdx-hardis" and "sfdx-git-delta." I discovered most of them from Salesforce's Shane McLaughlin's list of SFDX plugins. This is a handpicked list. I think there are more beneficial plugins that are not known. I'm building a website that allows others to explore and search for the necessary plugins. This is my current project. It's already public, but I look forward to getting some users and feedback. The name is "sf-plugin-explorer."
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?
It's a website published with GitHub pages. My goals for this project were that it shouldn't cost anything and that it should be as simple as possible. Right now, it looks really bad on purpose because I first want to improve the data and make it pretty later on. If it turns out to be a success, I will think about buying a domain. Right now, it's hosted for free and with the least amount of effort possible.
Problem-solving made simple
Thank you for tuning into this episode of Hutte's Trails Podcast.
Samantha is Hutte's Content Manager and Chief Editor. She has over six years of experience as both a content writer and a copywriter. Bringing the written word to life is the name of her game.
