From product manager to DevOps evangelist: my Salesforce journey

Share with

Description

In this 30-minute DevOps Launchpad “Careers in DevOps” webinar, Eric Kintzer shares the key revelations that shaped his career — from deploying with change sets at “Yahoo! Legal” to becoming one of the most respected voices in Salesforce DevOps today. Along the way, he’ll unpack real-world lessons, highlight common pitfalls, and explain how best practices (and the odd StackExchange post) can transform your delivery process. Learn more:

Transcript

So without further ado, I'm very excited to introduce you all to today's speaker, Eric Kintsa, Salesforce architect, Stack Exchange top contributor, and Salesforce community and DevOps leader. So if everyone is ready to get started, Eric, I shall hand over to you.

Great. Thank you very much, Amy.

Let's get started.

So, you know, who am I?

I often describe myself as the all singing, all dancing Salesforce person because I have to be an admin, I have to be an architect, I have to be a developer, I have to be a DevOps person, sort of all wrapped up in one package.

So lots of experience in doing this for since two thousand and eight. And let's let's get into that journey.

So the before times, What was I doing before Salesforce?

Well, I was a sort of tech executive in engineering, CTO, product management, that kind of stuff. Not exactly a rule of Garg.

With much smaller companies, but I didn't do any hands on work. I basically managed people and budgets and product direction and all that kind of stuff.

And, anyway, in two thousand and seven, all that came to an end with the last startup failing.

So I got a new job as a Salesforce person as an individual contributor working at Yahoo, specifically their legal department.

Now I thought I was going to be designing a product for content rights management and have other people build it and their chosen platform of choice with Salesforce. But, no, Yahoo said, nope. You don't do that here.

You're gonna build it yourself.

So I became the individual contributor with my hands dirty, no more managing budgets and people.

And so I meant I had to learn Salesforce. Now back then, there was no trail trailhead.

You you learn from some websites, a lot of books, and it was, you know, sort of a different learning experience back in two thousand and eight. But nevertheless, you know, Salesforce knew that in in order to build apps they had to train people how to do it and they provided the learning materials, to do that including, you know, you know Dreamforce sessions and things like that.

So as I started building Salesforce apps, you know, by myself, I had several revelations on my Salesforce journey. The first and most important one was I could deploy my own work to production.

All my prior companies, which were basically on premises companies, deployment was complicated.

It was sometimes a whole of engineering, whole of product management, whole of ops effort that could go to three in the morning before we ever got anything deployed to production.

And with, you know, it seems obvious now, but with cloud based systems or platform as a service companies like Salesforce, they provided tools to let you deploy yourself. And so you were in much more control and the turnaround time to get things done was way faster.

And how do we do that? Back then we did use chainsets.

Now I chose this graphic because chainsets are sort of blah.

There's lots of problems with them but they were accessible and they were the only tool really available to the sort of one man band that I was on Salesforce.

The second revelation was that as I started doing development I had more tools than just the developer console.

Specifically, there were integrated development environments. Now I'm sort of aware of them back then, but with respect to Salesforce, there was a specific one which was Eclipse, which had a Salesforce plug in that lets you do Visualforce and Apex work. This is way before flows existed, even before process builder existed.

So, you know, that was a useful tool to do development, and it made me feel empowered. And I learned how to use an IDE. Not very well, but I definitely learned.

So the next revelation was that there was actually a DevOps ethos.

Other implementations that people did on non Salesforce platforms, like real engineering systems, used DevOps approaches.

And these were called continuous integration and continuous deployment solutions.

Salesforce offered something called the Ant migration tool which was essentially a bunch of command lines that you would script to get your deployment from your local machine into version control into your org and then moving from that org onto future or so downstream orgs in the deployment cycle.

Now this wasn't great for me or for most Salesforce people because the scripts were managed by, you know, script developers inside in this case was Yahoo.

They were opaque, a lot of command line stuff.

If something broke or needed enhancement, you had to wait on somebody else.

None of this was ideal and not really what at least the sales work professional needed.

Rob Cowell who's the DevOps evangelist for Gearset has a whole DevOps byte bytes video on this topic which I recommend you listen to. It's only like three minutes long on the pluses and minuses of your roll your own DevOps solution.

Okay. Next revelation was that there were good ways to build Salesforce apps, specifically design patterns.

Now design patterns have been around, of course, for decades in the traditional software engineering world, but as applied to Salesforce, not so well documented or not so well exposed at least in the early years.

So for me, what do design patterns mean? Well, the first one that most people run into are trigger frameworks of which there were several back in the twenty ten, twenty twelve era.

But the big points, at least big revelations for me were a couple of books.

One was the Advanced Apex Programming by Dan Appleman which had a superb asynchronous pattern that I've since implemented in every org I've ever worked in. And then there was the CTO of FinancialForce who had since became the CTO of, one of the CTOs at Salesforce, Annie Faucet, who did, the Salesforce platform enterprise architecture book, which is like was game changing for me. I remember curling up with this book, the first edition, this is the fourth here, on a chair and annotating every piece of code that was just written about in the book, because it was so insightful. It was I don't know how to describe this.

It was like this was the way it was supposed to be done. Everything I had done before was sort of not quite half assed but sort of eighty percent right but not quite right. And I sort of knew it wasn't right. It could have been done better.

And after I read the enterprise architecture pattern book I went like this is how systems are supposed to be built and I adopted this strategy and everything I ever did since.

Next revelation. So as I learned throughout the years of doing Salesforce development, first at Yahoo, then at VMware, then at other companies, I was learning stuff and I was learning from others in the Salesforce community and so I decided that I should be able to give back to that community. And specifically the community I gave back to was Salesforce Stack Exchange. This is my profile. I'm property.

So it was gratifying to have people post questions and be able to answer them because I knew the answers to some of the stuff. Not everything, but I knew the answers to a fair amount. I post answers and people would say, yep. That's a good answer. I'll upload it or the original questioner would say, yep. That's the solution and mark it as a solution.

So this is a gamification community. You earn reputation points as people vote up your answers or accept your answers.

So I thought this was great, and I really enjoyed giving back to the community. And I learned a lot, of course, by giving back because I would read people's questions and have to think about them. And so then I learned myself and that would apply or be applied to my own projects, at work.

So the next revelation were vendor DevOps solutions, and hence why I'm here with Gearset.

So one day, I went to Dreamforce, and I encountered the chief product officer of Gear Set, Matt Dickens, who if you haven't met him, he's a great guy, and a superb leader for Gear Set because he actively engaged with customer prospects, of which I was one, about the product, Gearset, and how to do and deploy Salesforce solutions.

And specifically in engaging, he would accept critiques from users like me and that would be folded into product enhancements.

So I became actively engaged with the gear set product development roadmap particularly in their early years.

And this meant that that collaboration between a vendor and the users, meaning I would give advice, they'd take advice, they'd give me ideas, I'd feedback those product ideas to how I thought they should work, was a symbiotic relationship and, you know, really made me feel not only valued to the DevOps community, but also had something to offer beyond just a user.

So, you know, how did this manifest itself?

There are some private gear set Slack channels that I could interact with the developers and the product managers.

There are gear set round tables I interacted with, again, with product direction, advice, and recommendations, and in general, other gearset product planning. So it's more than just user voice which gearset offers as a feedback mechanism for customers but it was more intimately involved with the actual decision makers at gearset about how stuff would get done. So this was a great addition to my career, and I think as a vendor, a really positive way gear set could be interact with our customers.

Some of the things that we did, as a gear set adviser, and I wasn't the only one, were two of the biggest, feature rollouts that gears that have. One is pipelines, which was a visualization and automation between getting your changes from your dev environments up through version control to integration staging and production.

This is a huge feature, really, a must for any DevOps person. And then the second was precision deployments, which allows one to deploy, not the entire, for example, layout or lightning page or even an Apex class but only segments of it if only those segments are ready to be deployed into production or for that better integration environments allowing for more fine tuning and less, merge conflicts as you worked on teams with other people modifying the same resources.

So, like, what are my final takeaways over these fifteen year it's more than fifteen years now. Seventeen years of, Salesforce work. If I had to summarize it in one sentence, it would be use best practices always.

So you're so tempted so tempted while you're doing work is to take shortcuts, and believe me, I took shortcuts in the early years.

But you might be living with your Salesforce implementation for more than a decade. I mean, I've got orgs that I still work on that I started on in two thousand and nine.

Now when I look at those orgs and the decisions I made in two thousand and nine, I go like, ugh. You know? This is what a bad Apex class or what a bad piece of automation or at least naming conventions are terrible or whatever. You know? The design pattern's wrong.

And so, you know, and so I'll then I'll go when I have to go touch that part of the system, I'll go fix it and make it right. And I believe strongly that if you're gonna work on Salesforce development, whether it be flows, custom objects, your schema, Apex classes, whatever, you should do it well and take the extra time to design it properly.

This means not only be an artisan but also be ruthless.

Naming conventions.

Don't be slapdash. That's a good word. Don't be slapdash about your naming conventions. Look at what's how things are already named or if you need to find a new pattern, you know, set up a pattern and name everything that way. Follow Salesforce with naming patterns.

Make things clean to the eye. If you're looking at a flow, if you can't understand what the hell it's doing just by inspection, then you need to re architect it or refactor it. Same with Apex classes. If your eyes can't figure it out an initial with, you know, first couple of glances, it's not designed right. And then you should be you should again refactor it.

I've looked at, you know, so much code over the years by written by so many people who just try to get it done rather than try to get it done well.

And then the last sort of ruthless piece of advice I have is through a comprehensive regression test.

Again, if you're gonna be living with an org or even if you care about the people who are gonna be managing your org or maintaining it over time, you wanna build things well, have a serious regression test week that tests everything. So you can go to sleep at night knowing that if something is changed, your test will catch it. Things will break in the dev environment and not get pushed into production and break there.

So I can assure you that I spend more time probably writing test methods than I do in the initial development of the core software.

Third takeaway is essentially leverage the work of others.

So I use a lot of tools from software that's been built by other people. Unofficial Salesforce stuff for flows, the famous declarative lookup roll up summaries, to mitigate the limitations of roll up summary fields in Salesforce, various GitHub libraries that are open source, the f f loop library, which is Apex Design Patterns, ApexMox which is like a huge tool for making it easier to do unit testing, Sobjectfabricator which is used as part of unit testing. All these tools are great and anyone who sort of doesn't use these or their equivalent, it's not that these are the only ones, is really making themselves less productive and creating a less well architected system.

Fourth takeaway, and it's pretty obvious, should be it by now, is I love Gear Set. I've used them for nine years. We initially looked at Caputo and Autorabbit.

Caputo was just it was too complicated, when we looked at it. Gearset was seductive, and Autorabbit was, you know, required professional services implementation skills, or by them in order to even get something going. They were from much bigger orgs than we were. None is maybe true now.

I haven't really looked at them. But Gearset's been great. They've evolved well. The product is intuitive.

The vendor support is excellent. The customer support is excellent.

Their involvement with their users, particularly through the gear set roundtable is superb. And I can't say I can't speak more highly of them as a vendor.

So, anyway, thank you very much. That's my journey. You know?

Went from, no hands on kind of guy to very hands on, in a Salesforce oriented career. And for me, it's been great. Thank you very much. Amy, take it away with questions.

Awesome. Thanks so much, Eric. Yep. So we do have loads of questions that have come up through, here.

The first one is from Lauren who asks, you moved mentioning from using change sets to the Deltz tools you spoke about like gear set. What was the biggest improvement you noticed once you made that shift?

Right. So gear set had two big advantages, which were one of which is their secret sauce. So the first advantage was the compare screen lets you see what you were trying to deploy versus what was already deployed in the target org or Initially, for me, it was orgs. Later would be version control.

You change that so don't let you see what's in the target environment at all. I mean, you just pick and choose from your source org and you know check a bunch of boxes and then click deploy and sort of hope for the best.

The second advantage GearSet had is the secret sauce which was the problem analyzer.

And this meant that GearSet could detect if you were missing things from your deployment package. Change sets did not do that at all so you could deploy stuff with change sets and come back with a bunch of validation errors and then you have to sort of you know then select more items in your source org and then run the whole process again. Gear set would short circuit that validation error step by telling you that you in fact had forgotten things before you ever got to the validation attempt.

I hope that answers the question.

Yeah. That's absolutely a great answer.

Cosmi, I'm just replying to your question in the chat. Eric, you mentioned about regression tests. How do we learn how to do regression tests properly? I've popped a link in the chat to an article from DevOps Launchpad there. Eric, do you have any expertise or advice on, tackling regression tests or getting started? Where where to learn, what to do, or, like, common pitfalls you might come up against? Any advice there?

Okay. So it's a huge topic.

Obviously, the the first place to start would be Trailhead, which sort of gets you into, what a test method is, test isolation practice is, meaning don't ever, whatever you do, do not use see all data equals true annotation on your test method. I mean, that's that's what it's called a code smell bad crack. Anyway, well, I so what the biggest, thing you can do to make regression testing easier is to design your software in good architectural elements that are testable on their own.

And that is where the Apex Design Patterns to me that book I showed in earlier in the slide deck was revelatory because it makes you architect your Salesforce system in a way that is inherently unit testable in in an efficient effective way.

So, anyway, I could go on, but, those would be my main, takeaways.

Awesome. No. Great advice.

So going back to talking a bit more, career wise, Simon asks, what would you say to someone who's work who's working solo on a small team and wants to bring in DevOps Okay.

So there's two parts to that. One is whether you're using version control or not.

So if you're and regardless, I'd recommend using a vendor solution, even though it costs money.

The efficiency gained by being able to see what you're deploying versus what's in the target environment makes you makes it so you'll avoid mistakes. And then the vendor tools, you know, like the gear set problem analyzer, will, you know automatically detect mistakes that you're gonna make and this all will save you time and saving you time means saving you money because you're gonna get stuff into production more quickly with fewer errors.

If you don't have version control you can still use vendor products like your set just so you don't get quite the same advantages but you can still set up you know, an environment where you move things from dev to integration to staging to production. Just that the steps tend to be more manual involved.

I'd you know, get a if you aren't using Gear Set now, get a trial and, you know, start start using it. Carve off maybe the work that you're doing yourself and use Gear Set and then show others and then get them to get licenses and, you know, you're off to the races.

Yeah. Absolutely fantastic advice.

We've got so so many, like, really big topic questions coming in. We've got a couple minutes left.

I know some of these topics you could go on for hours, Eric, but we've had a question from Ria, which I think is a really nice one, who asks, what's the best what's best practice to avoid merge conflicts and code over, overwritten code issues?

I think we've already answered it a bit in your previous answer right with version control.

Well, it's part of it comes down to sort of architecture. So the fewer the fewer large containers you have, and I use the word container to mean something that has lots of elements inside it, that are being worked on by multiple people, the fewer merge conflicts you're going to have.

So enormous Apex classes with tons of methods in them are gonna be inherently merge conflict, prone.

Large flows that aren't broken down into subflows that can be managed independently could we're gonna have merge conflicts.

Lightning pages is a bit sort of more of a problem.

You know you're gonna have a lightning you know you only have one lightning page for your account object and everyone's busy touching it you're gonna have merge conflicts but a way around that is to use the gear set precision deployment feature and only deploy those elements that that that you specifically are working on rather than things that other people are working on as well.

And, again, a big topic, but architecture is sort of the right answer.

Yeah. No. Hundred percent. I've also I popped another, link in there, Ria to a gear set blog. It's a great article on how to avoid, and resolve merge conflicts, and it also talks about how to do that with the CICD pipeline, as well. So that might be a great resource for you there.

We are coming up to the hour now. Sorry, half past.

We, Cosmee's asked in the in the q and a, can we get a list of books, that were shown in the presentation, please? I will follow that up for you, in an email going out tomorrow. We will be sending everyone, a recording of today's session so you can catch up, and I'll pop, any resources we've spoken about today in today's presentation in there for you to follow-up and explore. But, unfortunately, that is all we have time for today. Eric, you've done an absolutely fantastic job answering everyone's super difficult, questions today, and and thanks to the audience for getting involved.

We we absolutely love to see it.

Just a reminder, if you aren't currently a DevOps Launchpad, user, you can sign up for a bunch of, Salesforce Salesforce specific DevOps courses and certifications, all completely free, and they will help towards your training and learning of DevOps. There's also some courses, in there where you can actually, sign up for a free trial of GearSet, and you can work alongside the free trial and get to grips with the tool and all of the, features and fun things that Eric's been talking about today. You can try that for absolutely free. So worth checking out. Just put the link in the chat.

Yeah. That that's, that's that. So thanks so much everyone for joining us. As I say, keep an eye out for the follow-up email in your inboxes around this time tomorrow.

And once again, a huge thank you to Eric for presenting today's session. We hope you all found it super insightful, and we hope to see you again very soon. So thanks again, Eric, and thanks everyone else.

Bye.

Take care.