Description
Thousands of open branches. Tricky merge conflicts. Missing dependencies. Unanswered support tickets. If these Copado pains sound familiar, this webinar is for you. Watch the recording to discover how Gearset solves the problems Copado can’t.
Book a consultation: https://gearset.com/book-a-demo/
Transcript
Appreciate everyone joining. Today, we wanted to just talk candidly about some of the common pain points that teams run into when they're using Copado and walk through how Gearset approaches some of those problems differently. So our goal today is really just to show you a clear, simpler way to do DevOps. A quick look at what we're going to, where we're gonna be headed.
We'll do some introductions to who you have on this side of the call, give you a quick snapshot as to who Gearset is for those of you who are, newer to our our technology, and then share what some customers who have switched have actually experienced when they moved from Copado to Gearset. And we'll jump into a live demo, so that's gonna take up the bulk of our time. Any questions, like I said, drop them in the chat as we go. We'll cover them at the end, or if they're easy to answer, we'll we'll go ahead and do that in the chat.
So I'm Taylor. I am an enterprise Account Executive on the Gearset Sales team. I'm joined by Alister McGrath, one of our lead Sales Engineers. We've both worked at Gearset about four and a half years.
In particular, we've worked with dozens of enterprise customers who have made the switch from Copado to Gearset, in that time and, in particular, over the last, like, twelve to eighteen months. Alistair will be driving the technical demo later, so you'll get some of those answers straight from someone who lives in the product every day. And feel free to reach out to us after the the demo today at the emails on the screen if you have any questions. Bit of context as to who we are.
So Gearset is the fastest growing vendor in the space in terms of Salesforce DevOps. We have thirty five percent customer growth in 2025, over three thousand customers, growing about ten percent of the Fortune, five hundred with us. And what we're proudest of, honestly, is that ninety eight percent customer happiness score. We've got top ratings across g two, the AppExchange, on Gartner.
I've worked in software for a long time, and to have a customer satisfaction score that high is is pretty remarkable. And it goes to show the way that we build our product, but also the partnership that we show for our customers. So one of the key things I wanna slow down on this slide is there's some core architectural differences with Gearset and Copado. With Copado, it's a Salesforce managed package that orchestrates your deployments, and Salesforce records drive that logic.
So Git is technically integrated, but it's not the one in control. And a lot of our customers feel the pain of this, that Copado sits between Salesforce and Git and has its own kind of black box layer. So that looks like day to day kind of hidden states and ghost commits and confusing merge conflicts. These are the exact frustrations that we hear from a lot of our, customers who move off of Copado.
And if you're hearing something similar or that resonates, then, you know, just know that you're not alone. With Gearset, we really flip that, and that's intentional. So Git is the single system of truth, and we layer Salesforce awareness and and intelligence on top of that. It means one source of truth instead of two, fewer hidden states, cleaner history, and outcomes that you can actually rely on.
But what does that architecture actually buy you day to day? Well, first, you get predictable CI/CD because the Git history tells you exactly what we'll deploy, and why, on every single release. There's no surprises as to what's going into your releases. Second, you get much simpler debugging.
We often hear about just confusing and and lengthy times to debug, Copado challenges. When something breaks, you check Gearset. You're gonna see the exact same thing that you'd expect to. You're not reverse engineering a black box that is difficult to figure out what happened.
Third, you catch risks earlier because dependency and flow issues get surfaced before you actually make a commit rather than having already broken something by the time you get to you get to deploy. And fourth, you rely on much less tool specific tribal knowledge. That's one of the big things we hear from Copado customers. We have, you know, one or two people who have had to learn Copado pretty intricately.
Whenever something breaks, we have to go to those people. Your team then is dependent on them in order to make deployments work. So when you add all of that up, the enterprise outcome is is pretty real. It's pretty tangible.
With Gearset, you get more predictable deployments, a faster root cause analysis, lower operational risk, and a safer long term DevOps strategy. Now beyond the architecture, this really comes down to the experience of working with us. You get fast time to value, because there's not a heavy implementation lift. You simply connect your orgs and your repository and get started.
We'll show that today. There's not a ton of heavy customizations to manage. No maintenance windows that you'd have to maintain, lest you don't get support on lower versions because in Gearset, you're always on the latest version every time you log on. It's accessible to admins and developers from day one.
And when you need help, you're gonna be talking to real humans every single time. Customer support is actually our second largest function at Gearset above be right behind our product team. And that's what we mean when we talk about DevOps done right. It's the DevOps done right advantage, and it's really how we partner with our customers.
I would not ask you just to take our word for it as the vendor, though. These are some of the the feedback that we've received from teams who have made that switch. We've heard from teams that Copado's all or nothing approach hurt their lead times and hurt their ability to deliver as quickly back to the business as they wanted to. One of our principal release managers that that we've spoken to found so much basic functionality missing in Copado that his team used a Gearset trial just to unblock their releases.
And one of our customers at Thumbtack described delays over, you know, multiple days, that were bleeding into their really tight timelines, and it was becoming really painful to push to production. But these are the same patterns that we hear from tons of Copado customers and patterns that we break once we get into Gearset. So that's kinda the why behind making the switch. We wanna show you the how.
Alistair's gonna take you into a live demo, rather than me just working off of slides today. If you have any questions in the chat, feel free to keep them coming, and we'll go ahead and answer as we go. Cool. And with that, I'll go ahead and start sharing my screen.
You should see this Gearset pipeline that one. We can go ahead and dive right in. Like Taylor said, any questions that come up, please pop those in the chat at any time. We can make sure to keep up with those.
But from my perspective, I wanna start a little higher level to speak a bit about where Gearset is situated, what it takes to set things up, and how that feeds into the process moving forward. So we'll look at the day in the life for a developer or an admin working in Gearset to promote the change through the pipeline. Now like Taylor said, Gearset itself is entirely off platform. The only thing to install in any orgs is a connected app to handle things like OAuth connections.
Those OAuth connections then can be done on an individual or a service user basis, both to the orgs that you connect to Gearset and to the source control repos. What that means is Gearset effectively sits on top of those instances, can pull the levers of the CI/CD process, making sure that we're staying as true to form as possible to true DevOps processes. So using Git first and having that, main branch as our source of truth throughout the process. After that, though, things do become very flexible.
So you can have varied release cadences, varied levels of feature isolation, varied project streams depending on how regularly those things are being pushed towards production. So people can work from either individual developer sandboxes or shared ones, or you could even isolate sections of the pipeline for different longer term projects, things like data config rollout. Gearset also manages environment sync then. So on a per environment basis, I can regularly push back deployments down to my developer sandboxes or update any of my full or partial sandboxes in flight, ad hoc.
But this makes it really easy at the start of the process then to make sure I'm building off of the latest work since Gearset automatically tracks changes that reach that source of truth, that main branch. So as a user, I don't have to manage, let's say, dozens of back deployed pull requests. I just choose a point in time up to which I'd like to pull those updates, and then Gearset updates them all at once, bundling together that large set of metadata. This is also the first of several places where we'll see Gearset's conflict engine at play.
This is gonna be a lot more precise than what Copado has since we aren't just gonna blanket overwrite things, and we also won't assume resolutions where that may damage functionality. If there is a genuine line by line conflict, I can resolve moving forwards or backwards as we are here with this dev sandbox update. But overall, you'll tend to see far fewer conflicts than you would in something like Copado Since for cases like semantic reordering, if multiple people are changing a declarative item, let's say a profile or a layout, Gearset's able to stitch those changes together without issue, something we'll see on the forwarding process.
Once my environment's up to date then, I can start on that feature. When I follow the new feature flow, I can immediately associate it with tickets from Jira, Azure, or Salesforce. But if I wanna push forward a change that's not associated to a user story, I'm not mandated to create one. I could create a branch ad hoc.
For now, though, I'll go ahead and grab one of these tickets assigned to me, and then I'm able to start the comparison. This comparison process then will deploy changes from my developer sandbox onto that newly created feature branch. And it is worth mentioning that Gearset is fully interoperable. So if I wanted to do this commit process through Versus Code, it doesn't mandate that I follow this through Gearset.
I could open pull requests and make commits, even solve merge conflicts from an external system, and have Gearset CI pick up on that throughout the process. But if I make these changes through Gearset directly, I am gonna have a lot of added benefits, generally shifting issues as far left in the process as possible so that I, as an admin or developer, can solve them before handing it off to a release manager. As these components download into the comparison then, I can grab them all at the top here, seeing the kinds of difference they have, information from the audit trail as presented from the metadata API.
And then in many cases, I'll have a rendered visual telling me exactly what changes I can expect within my selection. So rather than digging through messy XML for a flow, I can instead see the line by line changes within individual elements. That way, it's far less ambiguous when I'm pushing forward, further reducing the chance of pulling through unwanted changes. For many different metadata types too, we'll have additional workarounds.
Like with this flow, I'm not mandated to use the latest version. If multiple people have been working on this in a shared environment, I can effectively go back in time and grab an older version. That way, if someone else has made a change, I don't accidentally pull through that work. I'll just check the box next to this metadata type, and now I don't have to remember what else this connects to.
I can just open this relationship tree to see other relevant items. So dependencies to a new field that I've produced, a new Apex class, checking the boxes along the way to make sure I have a fully fledged out package. This too is gonna make sure that I'm not leaving things behind since now I'm reminded, oh, that custom field also has dependency. I should probably include it in my package.
And I also wanna make sure this is visible so I can see it ties to layouts. When I grab that set of layout changes, there's benefit within this comparison here where I don't have to push every single thing related to this change. Taking a look at the preview, there's a whole bunch of other fields being updated not related to my user story. I'll just deselect them, making sure not to push them forward in the process, again, reducing the chance of conflicts down the line.
We typically see that teams who move from Copado to Gearset see a significantly fewer, up to fifty percent less merge conflicts in the pipeline because of this granular technology. And that applies to many different components too. So things like profiles and permission sets have that same kind of visibility and granularity, allowing me to only update one line of field level security instead of pulling through that whole monolithic profile. Those relationship trees are also bidirectional.
So if I'm doing a profile rework of, let's say, transitioning to permission sets, I can see all those different subcomponents broken out from that side going as far as pulling in data components beyond metadata. This allows me to move things like CPQ or OmniStudio, manage package components, even changing the API version within these comparisons, all just adding to the flexibility of the deployments I make through the tool. Once I have built out that selection then, Gearset's immediately going to start making suggestions around making sure this package is fit to deploy. So here, it's suggesting that I add these components that I neglected to include previously.
And if I continue to charge forward without choosing to include those, there's a more rigorous problem analysis on the next step, running over seventy checks in the background that, overall, help Gears have maintained a ninety nine percent deployment success rate across all of our users. Here, it's caught my missing dependencies. It's also caught some issues with my permissions. And now that I fixed this, I can proceed with the confidence that this is going to succeed in validation and not give a headache to my release manager down the line.
On the final step of the process, then we can start thinking about things like post deployment steps. So adding my commit message, updating my Jira ticket without leaving Gearset. Once that's done, we'll add a comment to that ticket and maintain that link throughout the entire pipeline process. Finally, once committed, we're brought full circle to the pipeline itself where I can continue working on this feature branch.
Even after I've opened my pull request, I can continue making forward fixing changes even if it's been deployed to multiple environments. The CI job will then do the work in the background to update that in flight piece of work, making sure those changes don't miss any environments. Upon pull request creation, then I can save some more time, having AI generate a description of what's included on my pull request, adding consistency and thoroughness to everyone's pull requests. And I can also tackle any other manual or automatic post deployment steps.
So if I need to do something like a data load, I can make sure that this is actually completed. And I'll have visibility on the Jira side as well for these steps that I'm including. For automated steps, I could grab that flow that's within my package and choose to activate it once it does reach that final environment. So in production, now I don't have to go in and do this.
It'll just be turned on once deployed. I could also choose to include any additional tests to run, but the CI jobs themselves will be dynamically looking at the contents contents of each pull request and making sure to run the necessary tests. Now that that pull request is opened, I can carry it forward to my later environments. And depending on my CI settings, I could have GearsUp automatically deploy this through every stage so long as it passes my various quality gates.
Anytime an issue does come up, though, I'll be able to solve that in several ways, either rolling it back, fixing it forward, or solving that validation manually. But this is where things become even more customizable. I can include any kinds of quality gates I choose to. So, of course, we'll have those manual pre and post deployment steps.
We'll check for conflicts against the target branch. We'll run the Salesforce validation, including those dynamically run tests. I could also trigger UI testing or static code analysis through Gearset, either using the PMD library or our own, code review tool, looking at the Salesforce well architected, framework in order to ensure best practices. On the Git side of things, any status checks that I have enabled in the Git system are pulled through automatically.
It also includes the assignment and enforcement of reviews, again, making sure that we rely on those best in class products, to follow that service driven process. One thing to note about the validation queues, this comes up with a lot of our enterprise customers where they have, you know, two hundred to three hundred PRs queuing at a time per sprint, and oftentimes that in Copado can take days to run. The nice thing about Gearset is we've made the product decision to run the queuing of validations on our side instead of letting the, like, Salesforce kind of manage the queue, the the what which, PRs are aware within the queue.
So if you have PRs that are more important that need to be validated first to be promoted, those are some that's something that you now have visibility into and can change on your side. Gives you a lot more transparency and flexibility as to what needs to be delivered into your next sandbox or production first. And that queue is done in it, so I can fast track certain things or hold things back if I choose to. Later on, I can even bundle these features together.
So when I do get to that point of releasing into production, I don't have to do it one by one. I could instead continuously validate a larger release, bundling together any number of features then, all of which are being continuously validated, and then what I can release on a scheduled basis. So no need to stay up after hours. I can have this go once everyone's offline, send a message to my Slack or Teams channel, and kick start the environment sync process again, back deploying those latest changes into any environments that have missed it.
One final thing I'll call out too. As people are pushing changes to the pipeline, if any sort of issue arises, like Taylor said, we do have excellent support available. On the other end of the support chat, there are a number of customer support engineers who typically get responses back in less than five minutes. minutes.
There's no bots on the other end of this unless you choose. Otherwise, you can speak with a subject matter expert who can, as necessary, escalate that issue to make sure you have a resolution, either guiding you to docs, hopping on a screen share, or even bringing it to engineering in critical cases. Outside of that, though, that largely covers the end to end process. I realized that was a relatively whirlwind demo, but I'd be happy to answer any questions or dive deeper, as necessary.
If there are any questions, we can put them in the chat. Otherwise, we may be able to give you all a few minutes. It is worth noting too. This is only a small slice of Gearset's platform.
Taylor mentioned that we are a full platform for DevOps, but that includes a data suite. I mentioned the code reviews and testing side of things, but you can see sandboxes move around configuration data as well as run backup and archive jobs. Not enough time to get into all that today, but, again, worth calling out that it's fully encompassing on the DevOps side of things.
