Description
After struggling with unreliable deployments and tangled version control, Thumbtack needed a solution that could scale, improve collaboration, and accelerate their Salesforce releases.
Join Jesse Fusselman, Senior Manager of Business Applications at Thumbtack, and Andrew Cali, Solutions Engineer at Gearset, for a live case study on how Thumbtack revolutionized its DevOps pipeline.
Transcript
Thank you for taking some time out of your day to join us for this webinar.
Let's go ahead and get in. So as we see on the screen here, what we're all joined together to discuss is thumbtack's DevOps transformation.
And what we're gonna do as a part of that is we're gonna look at a live case study, and then we're going to do some q and a, both throughout as we go. But also at the end, we'll have a little bit of time as well.
Let's talk a little bit about who you have on the panelist side here.
You'll have me. I'm Andrew. I'm a sales engineer here at Gearset, solutions engineer at Gearset.
And I'm joined today by my friend, Jesse. Jesse is a senior manager. But, Jesse, why don't I throw it over to you to just give a light introduction to who you are?
Yeah. Thanks, Andrew.
So like he said, my name is Jesse Fosselman. I'm a senior manager of business applications at Thumbtack.
I've been in the Salesforce space for just over a decade back when Classic was the only user interface Lightning didn't exist yet.
And I've worked in quite a broad variety of settings. I've done really small scrappy startups, nonprofits to global multinational companies, and companies with multiple CRMs. So I've kind of gotten, you know, a peek at how a lot of different companies run their Salesforce org and the related DevOps practices that they all use.
Currently, the team I'm on, it's eleven or so large mixture of admins and developers.
And they work on Salesforce along with the other tools that our sales and support teams use, and one of those tools is GearSat, which we're here to talk about today.
Awesome.
Thanks, Jesse. Well, let's talk a little bit about what the plan is for today and to to really keep it simple. We're really here to pick Jesse's brain. We we all joined today, hopefully, wanting to understand a little bit of, you know, how Jesse is using Gear Set, him and the team, and and how they got here. So we're gonna talk a little bit about that journey as we go through.
What I will say before we get into our walk through with our live case study is just a couple things to say out front.
Questions as we go along are going to be best surfaced in the chat. And so we have another panelist with us as well. We have Ryan Nabuda here who is going to be, you know, administering the chat for us, helping to field any questions.
But when I say that, what I would say is for questions, let's put those in the q and a feature. You'll notice that on the bottom or in the actual call itself. And for the chat, let's put any comments in there as we go, whether it be feedback, whether it be anything as we go along. Feel free to use those in combination.
Q and a is going to be a little bit more visible for Ryan for questions, whereas the chat's going to be visible, for any of those comments.
With that, let's go ahead and get jumped in. So I'm going to stop sharing my screen, and let's head over into Gearset. Now for those of you who are joining us and seeing Gearset for the first time, we are an off platform DevOps solution.
As we get logged in, the first place that we are going to find ourselves is on the CICD pipeline tooling that Jesse and team are using today as a part of their gear set journey. What I'll do before we get jumped into our example that we're gonna kinda guide the live walk through with today is just a very quick overview for those of you who are new to the screen on what it is that we're looking at. So we're we're gonna start on the left side here. You're going to see a series of blue squares. These are going to represent our dev sandboxes, whereas we know a lot of our work beacons.
As we then move our eyes right, we start to see a series of these chained together green squares that ultimately lead up towards the final destination for our features, which is our production instance.
Now with with that out of the way, the first thing I would love to kinda get into here is, Jesse, I'll come your direction.
We understand that the team is using CICD pipelines with Gearset today, but help us understand a little bit of the journey that led you guys to where we're seeing now in more of that gear set CICD process.
Yeah. Absolutely. So, I'll go back several years. Roughly six, seven years ago, I started at Thumbtack.
At the time, we were doing change sets, which, you know, I think anyone's familiar with, has a lot of drawbacks to it. It's great. You can deploy your changes just natively in Salesforce. You don't even need another tool, but I think you risk, you you know, people overriding changes. You really have to collaborate super well with the rest of your rest of your team. Our pipelines were super basic.
And, you know, it was obvious that the most impactful thing we could do for our admins and developers was to find, you know, like, a DevOps tool. And when we started looking, Caputo really caught our eye. We switched from Change Sets to Caputo, and I'd say it was a massive improvement. I mean, if you're on Change Sets, almost anything is gonna be a massive improvement, I think.
But it it it did a lot of great for us. It helped us introduce an external repo.
We can now coordinate changes going live. We could do back deployments so much easier.
But I think there are also face some issues that kinda surfaced as we began using Capado.
I think at the root of it, some of it is that, you know, Capado is built in Salesforce. Like, Salesforce is a CRM tool and something we constantly have to tell our stakeholders at Thumbtack is it's not a do everything tool.
Just because we can build something in Salesforce doesn't mean that's where it should live. It should really be focused around your customers and, like, your company's use case.
And I think that's really where some of the limitations are introduced. We would routinely have deployment issues. So, with Capato and I guess I should go back a little. It's been a couple years since we transitioned from Capado to GearSat, so it could have evolved a little bit. So this is my experience from a couple years ago. But, when you try to deploy something, it doesn't do a great job at, highlighting dependencies and making sure you have everything you need in your deployment. And so we would go through all the steps of a deployment, get through validation, have it fail, and only at that point in time do we realize we have to go back, you know, fix our deployment.
And all all we get are kind of the cryptic error messages that Salesforce provides. So, I think some of those are a little bit easier than others, but, generally, it it required a quick Google search to figure out, like, what exactly was going wrong with this deployment.
You fix it. You revalidate. Hopefully, it goes through the second time.
But then there were also some issues with the tool itself. And I think something that really made it difficult for us was the support at Capado.
For us, it was via email, and it it took long enough to get answers from Caputo that we could just Google and find a solution in the hour it took to get a response from Caputo, and kinda solve things ourselves, which is good, you know, self learning.
But, it really slowed down our ability to push changes into production.
Gear set or excuse me. Yeah. When we transitioned from Copado to Gearset, it was really refreshing to have a DevOps tool that wasn't part of Salesforce.
It was external. It was very simple to set up, and, it really unlocked our ability to evolve our pipelines and, how our teams work. So we'll I think we'll get into this a little bit further on, but you can get really granular in what you're deploying. And it does a fantastic job of highlighting issues before you ever get to the validation stage to make sure you're going through this process once, and you're identifying everything that you need in that deployment on the very first go around.
And so instead of it being a kind of chore or hassle, it it just works. You know? And, it was really a breath of fresh air. It's changed our deployment times.
You know? Those have been drastically improved on our team. And then I think just as important is, like, our admin and developer user experience. That has also drastically gone up.
I think everyone on the team really appreciates the way Gear Set functions and the support we get from their teams, a lot more than what we had with Capato.
Sure.
Sure. No. Thank you for for explaining that, Jesse. It's it's so cool to hear a little bit about the journey and really what led you to hear.
And you're absolutely right. We're gonna dig into some of these ideas as we get through the remainder of our time together. What I'd love to do now hey. We're we're on the pipeline.
We you've taken us all the way to where we're at now. Tell us a little bit about the setup that you guys have. Of course, we're we're here. We're looking at, my instance of Gear Set, but help the group understand a little how you guys have all this oriented with your own pipeline.
Yeah. We have, really a very basic pipeline.
And, I don't think everyone will agree with how we have it set up, but I also really I like the mantra, like, keep it simple, stupid, kiss. And it's really worked out great for us the way Gearset allows us to work.
And so instead of having a whole bunch of chains of sandboxes, we have shared development sandboxes, and then we have our UAT or staging environment, and then we have production.
We don't really have a hotfix. We can easily push things in gear set straight from but it's it's easy to do hot fixes without having a separate environment.
But at any given point in time, we have, you know, three or four admins and developers in one of our sandboxes actively developing things, and we never run into issues of people overriding each other's changes. And I think a large part of that is because of the granularity in which you can deploy and the ability to control the back deployments.
And it's just extremely flexible for our team to enable that kind of deployment and continuous integration, continuous deployment, mindset.
Yeah. No. That's great to hear, Jesse, and I appreciate you giving everyone a little context into, you know, how you guys are operating today, some of the ways that the UC Gear Set Hypling, helping to assist in some of the ideas that you've already shared.
At this point, Jesse, if there's no other comments, are are we kinda ready to maybe dig into a little bit of a walk through with our with an example here?
Yeah. Absolutely. Let's do it. Let's submit something through the pipeline.
Let's do it. Let's do it. So what I will do really quickly as we we go through the beginning parts of this is just provide a little bit of context. What we can all kind of imagine today is let's put ourselves in the shoes of of someone on Jesse's team. And what we'll imagine is that they've, you know, developed some changes, whether that be a field, whether that be a flow, whether that be Apex.
Well, they're now those changes are ready to be submitted into the pipeline.
In Gearset, the first step is then going to be identifying that sandbox and giving Gearset the first level of direction.
And in this case, we're going to instruct the tool that it's time to inject a new feature. Gearset's then gonna immediately respond to me, with a question.
Are you using Jira or Azure DevOps work items? And if so, what what user story are you, you know, basing this development work off of? This allows me to see any that are assigned to me as well as any others. We'll go ahead and use our webinar user story for the sake of today.
To this point, the gear set is then going to position for us an upfront comparison.
This comparison uses this the sandbox where our changes are as our source, and it's gonna use a newly created feature branch from our source of truth, our main branch, as the target.
We then go ahead and run through and go ahead and compare now.
Once we are into that comparison then, we really then see the a few different screen elements. First of all, we're able to see in our table here all of the metadata components that fall into the metadata types that we've gone ahead and retrieved.
For the sake of the beginning part of this now walk through, what I would love us to focus on is just a new custom field that we've gone ahead and built. Now as you probably are seeing here even on the screen, we then have this ability of dropping this down. And this is where we get into the first idea, which, Jesse, I'd love to hear a little bit of your perspective on how we're using these dependency trees today.
Yeah. Totally. I think, you know, going all the way back to change sets, there isn't a really good dependency branching. It's kinda like anything that could be related to what you're deploying, which is just an extensive list of everything in your org.
And so when you're trying to find specific dependencies, you know, I really appreciate how I feel like Gearset reads what you're trying to deploy, and it identifies whether or not everything related to that deployment exists in the next branch that you're going to.
And so it really intelligently does these drop ins to figure out, you know, this doesn't exist. Do you need to deploy this as well?
But then the filtering options are also great. It makes it really easy if somebody's working at a sandbox to just filter off of things that they've changed recently, when it was changed, what type of metadata it is. So it makes it really easy to just find exactly what you need to deploy and capture anything else related to that.
Yeah. That makes sense. But I guess worth calling out probably, Jesse, and, you know, I know that we're not just using this necessarily for dependency management.
You also talked to us a little before today about some of the ways in which we're using some of the precision deployment capability. Would you mind going into depth on that a little bit?
Yeah. Totally. So this is really what enables, multiple people to work from the same dev sandbox. So, if you're looking at the screen as he scrolls down, it he's looking at a page layout here, and you can see all of the changes that happened, in, like, a visual representation, which is nice. But instead of just moving that whole page layout over, you can pick the specific things that you were working on. So if you have two admins both changing a page, you know, you can go through and select just the things you did and migrate just those changes from that page.
So it, you know, it really prevents needing, I would say, multiple sandboxes, you know, a separate sandbox for every single admin or developer to work from.
And it makes it so that way, you know, all of our testing, all of our development is a little bit more concise and controlled.
And, you know, there's this isn't even the only visual here.
There's a couple of different types that I think are available.
Mhmm. Yeah.
Yeah. So, I mean, like, he just showed there's XML. So that's kind of like the historic viewed over to the yep.
Over to the right a little bit. There we go. So this is what you kinda see if you're looking in GitHub.
You know, I have several our more tenured admins or developers, they kinda prefer this view. But then more of our junior or green admins, they really like having the visual. It's just a lot easier to kind of see everything that's happening instead of trying to read everything.
And oftentimes and I'll we'll talk about this, I think, a little bit later when we get to the PR process, but these visuals accurately represent the changes happening. And so we'll take a screenshot of this, to, like, put on the PR, and we can talk about that when we get there. Yeah.
But just super helpful.
Perfect. And we did get a question that, I answered. But just to call it for the wider group here that Andrew selected that metadata to first go about by scrolling down and finding it, but there are other options of finding that. You can use the filter in the top right.
He could have typed in account dot d, and it would have found it. You can type the metadata API name in there as well. So, and then in that top panel, there is metadata type changed on, changed by. You can also filter those if you wanna select, unselect certain metadata types as well.
Absolutely. And, Jesse, you know, I know that this is a layout that we're taking a look at here, but are there other metadata types that you guys are using similar functionality on that you you are worth calling out?
Yeah. You know, flows I mean, I think Apex flows, pick lists all have, like, a visual representation to them. But if we could look at a flow Yeah.
That one's only been out a couple months, and my team was like, they were thrilled when this came out. They were like, oh my gosh. Have you guys seen that you can do this in CareSet with these flows?
If you could make make it a little bit yeah. Thank you.
And so with the flow, it literally pulls in the visual representation of your flow, but then it highlights the specific nodes that have changed. And so, it makes it super easy to nail down exactly what has changed in each of these. As he clicks in, you can see, the specific text values or anything, the formulas that may have changed.
But, again, this is fantastic when you're doing a PR, and you have somebody else reviewing your work. And now they have a visual representation and they don't have to, like, try to read the XML and GitHub to understand what's happening. They can look at this and be like, okay. You know, they changed the decision node. They changed the screen, the screen node.
And it just makes it really easy to quickly see and get on the same page with exactly what's happening, in the changes that are being deployed.
Right.
Now this isn't gonna be the only feature that CareSet has these visualizers for or really more so flow types of features. We have something brand new that we're calling flow error monitoring, which helps to better organize some of the flows and some of the errors more specifically that our flows have. We all probably are familiar with a loaded email inbox, but this helps to our customers to more, improve their observe ability, a topic for a different day.
Moving on then, what I'd love to maybe ask about next is, you know, the visualizers themselves. Jesse, it sounds like you guys are using you know, we saw the layout visualizer, but but are there others that that are worth calling out that have these more visualizations, kind of like we have here?
Yeah.
Pick list, lightning pages. We saw the layouts.
Actually, with lightning pages, you know, I was sitting next to one of my lead admins recently, and he was walking me through one of his deployments.
And it was really cool because he pulled up the lightning page, and he was reviewing the visualizer. And he recognized that he had missed a change from the deployment, and he was able to just go into the sandbox, make the change, refresh gear set, and just add that into the deployment within, like, two minutes. Like, it was so fast.
It it was really cool to see. I was like, man, I wish this existed when I was actively building things as an admin myself.
And I think there are more. I don't know that I've done a a an entire list of everything that GearSat does. I think there are a couple more.
Yeah. No. But it's important to hear, Jesse, about some of the ones that that your team finds value in, and so we appreciate you sharing some of that. Well, hey. We've got some changes that are selected here, and, you know, if we go back over to our field, I think we can probably move forward. But before we do from this screen, Jesse, is there anything else you wanted to call out that we're looking at here?
I don't think at this time.
I think we're good to go ahead and and commit. Cool. Well, with this then what what let's do, though, before we get to that commit is I'd love to leave these off because I think it'll tee up nicely a little discussion on some of the other things that we can leverage. So we'll imagine that maybe we leave some of these dependencies off that we know are gonna probably fail our deployment otherwise. But let's go ahead and move forward, and we can see some of that in action.
Now I'm gonna kinda just give an overview like I have, but this is Gearset's problem analysis feature here. Jesse, I guess, anything to call out quickly about, you know, how the team maybe sees this feature and some of the benefit that they might see from this.
Yeah.
Honestly, I feel like this is just a great catchall. I don't think we regularly get things that get popped here because it gear sets made it so easy, especially with the visualizers, to just get everything in the first program.
But this is a great way to catch anything that you do miss, add them right in. I mean, you can just click them and add them in. You don't have to really do anything else.
But if I compare this to, like, how we used Capado, we wouldn't know these things were missing until after it had validated. And if you're also running Apex tests, you know, depending on how clean or messy your org is or how big it is, like, that could be a thirty minute wait before you realize, oh my gosh. I missed the account discount rate filled. And now you have to go back in just to add that one field, whereas, you know, GearSat just recognized this as missing. It let you know. Maybe it's on purpose, probably not. And you can just add it in right here, and you keep moving on, and it doesn't slow you down at all.
Awesome. That's awesome. Good to know. Well well, let's get moved into then that commit.
I'm just conscious of time here. We've got about four minutes. But I I guess what I'd love to do is is we'll get to this predeployment summary. We see that Gear Sets laid everything out for us. We can take a look at that Jira user story, see that we've still got that connection existing, but we'll go ahead and and proceed forward with the commit into our feature branch.
And while this committing, we we do have a question from, Roberto. I was curious for Jesse.
How often do you refresh your dev sandboxes?
Yeah. We that's a great question. Currently, we do it twice a year. We just do it we kind of do planning around half years, and so we just refresh it, like, right in between launching a different half.
Our legal teams let us know that we have to make sure if there's, like, data disclosure requests that those can exist in our sandbox, and we don't have a robust process to handle that yet. So we're gonna be moving to a ninety day refresh cycle, but not not because we need it. I mean, we do for the data disclosure piece. But, otherwise, the sandbox is, are saying in sync enough that we really I mean, half a year, we aren't feeling like we need to do it. We just do because we wanna prevent issues from coming up.
But, yeah, half a year moving to ninety days, but unrelated to, like, really keeping the sandboxes in sync.
Yeah.
And I guess at this point, we can we can talk a little bit about that pull request creation, which immediately follows our commit, which Kirsten will allow us to do that here.
Jesse, is is this where you mentioned a minute ago a little bit about that screenshot. Is this where we're we're putting those screenshots today?
Yeah. Absolutely. Not on this page in Gear Set. We'll put a little description here.
They'll go into GitHub at this point and just post that, screenshot into the GitHub PR. Gotcha.
But, yeah, right then is right when it happens.
Gotcha.
Cool. And as we can see now that we've opened that poll request, what we've got is now it's fallen into the list, and here it is undergoing a series of checks. In the in the effort or in the, we have about a couple minutes left. So let's fast forward a little bit up till the production releases if we want to. And and I guess, Jesse, you know, as a kinda wrap up to this whole kinda end to end process, tell us a little bit about, you know, some of the impact and usage of the releases in in Gear Set.
Yeah. Totally.
We we don't use, like, a scheduled release cadence.
We're very much continuous.
We'll have releases that happen at eight PM in order to support teams that we have in the Philippines. Sure. But we still like to monitor those ourselves. And so the admin who releases it will generally stay online, just make sure things are working properly.
But the flexibility is there, and it's great.
We do back deployments.
Just ad hoc any admin at any point in time will review the back deployment before pushing it into a lower org.
But and, you know, I think Andrew was gonna get to this. There are scheduled releases. So you can just queue everything up to go into production at a certain set time.
And I think due to our size, we just haven't gotten to that point where we really need that yet, but maybe some, you know, at some point.
Yeah. No. Absolutely. Absolutely. Well, we've got about a minute remaining.
We had a few other things that, of course, we could have dove into, today, Jesse. I guess maybe the last one that I would call out just because you did mention it towards the beginning, and that's a little bit of that experience that you guys have had so far with with CareSet support. Is there anything final that you wanted to mention on that, or are we happy to to wrap up?
Yeah. Actually, I'd love to talk about it for just a second.
And, really, I'd say three things. Like, our onboarding experience surprised us. Like, we had our gear set, pipeline set up in two weeks. You know? We took two weeks, and we were pushing things through to production. It was really fast, surprisingly so.
And then the support itself is really great. I recently pulled our team to just see, like, hey. What kind of things are you reaching out to Gearset support on? And, you know, it's a whole gamut. It's only a couple items in the last six months. I think three different things.
But, you know, as an example, one of them was unsupported metadata. You know, they reached out to Gearset. They're like, hey. I can't find this thing in the metadata.
And GearSat was like, yeah. That's not a supported item, from the Salesforce side, so we can't deploy that through GearSat. And it saved them all the time of needing to, you know, start searching and figuring out, like, how come I can't deploy this through, GearSat?
And the last thing, you know, we have a CSM, Jane Key, and I have to give her a shout out right now. Out of all the tools we work with, she is our favorite CSM.
She's just really on top of making sure that our experience with Gearset is great. She's super friendly. She's not trying to push extra features on us, or upsell us on anything.
And, it's clear that she really listens. You know? We've brought up things with, managed package deployments, and we're like, man, it would be great if we could do this in Gearset.
And, like, three weeks later, she had us on a call with, PM and an engineer at Gear Set, and they're like, hey. Tell us about your experience with managed packages. We wanna try to build something similar to this. Like, what kind of things would be super helpful for you? What would you be looking for?
And it was refreshing to, you know, get that opportunity. That's not the only one we've had either. I think it's you know, they're constantly listening and evolving the platform.
Every every other month, there's some sort of cool new feature that's been launched, that the team finds really valuable and useful. And so it's great to have a product that's constantly evolving based on what their customers are telling them.
But, yeah, another shout out to Chunky. She's super great.
Yes. I know from experience, she is great, but it's good to hear your guys' experience with her is similar to to ours.
Well, I know we're a couple minutes over. What I'd love to maybe switch us into before we wrap up, we'll head back over to our deck real quick. And, really, I think, you know, we'll stay on for a little bit. So if there's additional questions that anyone has, we're gonna be floating around. Jesse, I know that we'll we'll stick on for just a minute here.
This is going to be Jesse's, I believe this is a link to Jesse's LinkedIn, so you'll be able to connect with Jesse on LinkedIn if you'd like. But, like I said, we'll we'll just hang out here for a couple minutes and, field any final questions. But, Jesse, from Gearset, thank you very much for for your time today. I hope that everyone that joined found this very helpful just to hear a lot about their journey.
So thank you, Jesse.
Absolutely. Thanks for having me. And totally any feel free to reach out. If anyone has questions and they don't want Gearset listening in, like, I'll I'll do my best to answer them with with my experience, but, you know, the team at Gear Set is pretty great.
Right. We we did, I did the best I could with answering some chats. I'll I'm gonna get back to Roberto on on one, but, he did ask.
Andrew, I think it'd be great if you pulled up in your pipeline chat about this for anybody still remaining on about how we handle back deployments. It's much different than, how a lot of others will do it where they're comparing the back to play changes to a branch versus how we handle it. So I thought you could just kinda showcase that in thirty seconds.
Yeah. Definitely.
Gearset, we've taken a lot of feedback on back promotions, and we've developed a feature here that allows teams to effectively back promote. Jesse, I know your team has started to use some of this as well from our understanding.
But what a lot of the feedback came around was, hey. Too many clicks to use back promotion. So we've developed a one click back promotion feature. The other is ordering. You know, sometimes it can be very difficult to know what things need to be back promoted first and then what things need to follow. Gear set's gonna automatically order these for us from oldest to newest so so that we don't forget any of those dependencies.
Final thing then is going to be the second step here, which may be the most important thing is there's a lot of blindness when it comes to back promoting changes. When when we back promote, we don't know if we're gonna overwrite something that's potentially in progress.
This helps us to avoid that by gear set identifying things that would otherwise be overwritten and allow us to intervene to make sure that doesn't happen.
I say all of that, but, Jesse, I guess, any comments on some of what we have here with the back promotions, or do you feel like I kinda covered what you would otherwise have maybe said?
Yeah. I think you covered it. You know, your set does highlight, like, merge conflicts really well, and then they let you make the decision as to how you wanna handle those.
But it it works well enough. Any of our admins or developers come back, promote anything at any time, and we rarely see any issues. I I can't think of one actually of having someone's work overwritten.
It could be how we have our pipeline set up. It could be GearSat. It could be both. I'm not sure.
Yeah. Absolutely. Well, Ryan, any any final questions here, or are we we feeling ready to kinda wrap things up?
I think that'll I think that'll do it.
Alright. Very nice. Well, for one final time from Gearset, Jesse, thank you so much for your time today, and and thank you to all the attendees that are still on for for joining us. Like I said, we hope that you got something out of this.
And, you know, if you had any questions, you can reach out to Gearset directly. But we also strongly encourage reaching out to Jesse to learn anything more that you might wanna know about his journey. I know he's gonna be available for that. So any final comments, Jesse?
That's it.
Thanks so much for having me.
Of course. Alright. Thanks, everybody.
