Description
Many Salesforce teams built their own release process, and for good reasons. Scripts, the Salesforce CLI and CI tools like GitHub Actions gave them control and flexibility, and for a while it worked well.
But AI is helping teams write more changes, faster, and it’s not just developers. Admins and partners are shipping more too, so more change reaches production from more people. Writing the change is now the easy part. Checking it is the bottleneck.
In this session, Nicole Bazarova (Senior Solutions Engineer) and Sunil Soni (DevOps Architect) look at where custom pipelines start to strain under that load. They cover pull request review that turns into a skim, sandboxes drifting out of sync, long-term projects running alongside daily releases, and what happens when a bad change reaches production. They also show how to follow an AI-written change through a pipeline that checks it at every stage, because AI can suggest, but your pipeline should decide what ships.
Transcript
Hello, everyone, and welcome to our discussion today. I'm Nicole Bezarova, a senior solutions engineer here at Gearset. And I spend most of my week with Salesforce teams just like yourselves looking at how changes actually get through a range of pipelines all the way to production. Today, we're gonna show you the Gearset product live along the way. We'll get to your questions at the end, so please do drop them in the chat if you have questions at any point.
The session is also being recorded, so you will get the recording in your inbox in the next day or two. Now I'm joined by my colleague, Sunil Soni, one of our DevOps architects here at Gearset. And Sunil designs release pipelines for some of the most complex Salesforce teams that we work with. So he's here to get into the technical detail with me.
Thanks, Nicole. Hey, everyone, and thanks for joining the webinar.
Perfect. And we also have Ellis in the chat who will be answering any questions that come up live along the way. We'll also surface a few of those for the q and a as well.
So let's start. Now, Sunil and I have worked on hundreds of customer DevOps transformations, and the question that I used to get asked the most about two years ago was, how can I deploy deploy faster with a DevOps pipeline? And now, it's very much become a different question. How can I deploy more safely with AI development?
But the key here is that DevOps pipelines and AI development are inextricably linked. You cannot improve the safety of AI development without considering the underlying DevOps pipeline. And we're really seeing this play out in real time because in our state of Salesforce DevOps 2026 research, we found that 84% of Salesforce teams were using AI to build Salesforce changes, but only 40 were confident in the accuracy and security of what AI actually produces. And that's a really big gap between how much teams use AI and how much they trust it.
So here's what we wanna talk about today. We all know that AI is helping teams write more Salesforce changes much faster. More changes from more people means it's harder and harder to govern what reaches production. And when governance slips, errors are unfortunately always close behind.
And a lot of teams that we talk to are now running a much higher volume of changes through the pipeline, which they themselves built years ago for a much slower pace of change, and they're starting to notice the cracks, which is exactly what we're going to look at today. Where these custom pipelines start to break and what you can do about it.
Now, first, let's start with a little bit of interaction so that we have a few people's perspectives here. We're gonna ask a quick question to basically understand. What is the biggest issue that is facing your pipeline right now? Is it that AI is creating more changes than you can safely ship?
Is it developers becoming bottlenecks which admins have to wait on to deploy anything? Do you only have a couple of people that really know how the scripts or the full process works? Or is a release basically breaking very, very often? So just go ahead and answer that in the chat.
We can see the answers come through and then we'll be able to discuss that in the context of what Sunil and I are seeing with the teams that we work with. And if it's anything else, by the way, if you've got one that doesn't match one of these, just pop it in the chat as well.
Oh, it's actually quite a close race. I'm seeing quite a few different answers come through.
Okay. Alright. We've got one that's starting to come out as a clear winner.
Okay.
So it looks like the top answer right now is that AI is creating more changes than we can safely govern.
Now, Sunil, I guess from your experience, does this match what you see with customers?
It does, Nicole. AI will generate changes faster than we can effectively govern them. Even without AI, managing Salesforce metadata changes is already challenging, and AI will only amplify that complexity.
This means more pull requests that need to go through code reviews, security checks, and validation processes, placing even greater demands on existing governance workflows.
Yeah. That makes sense. And I guess, Sunil, you were also at the GitHub Universe, I think, twenty twenty six conference last week. Right? So that's obviously a place where there's a lot of developers eager to learn and ask questions. Was there anything in particular that stood out to you at that conference?
Oh, yeah, Nicole. I had the privilege of attending GitHub Universe twenty twenty six out in San Francisco, and there was one theme that kept coming up over the few days. Basically, cogeneration is the easy part. Verification is the new bottleneck. So as we all know, AI can write code in seconds, but we wanna make sure that code is correct, secure, maintainable, and safe to deploy. That still takes real effort, and that's the part most custom pipelines were not built for.
So AI helps save time, but we must use that time to understand the business rationale behind what is being built so we can verify it properly.
And that's really what we're going to dig into today. Where that verification work sits in a custom pipeline, and what it takes to make sure that it keeps up with the pace of AI changes.
So on that, let's just start with a quick discussion on the volume because there are two things that I think that we need to consider here. How much change there is and where it comes from. Because it's no surprise, obviously, to everybody that developers have been using AI tools to write Apex, Lightning Web Components tests in a fraction of a second, which is obviously great, but partners and contractors are also doing the same thing, and they're all now delivering much much larger pieces of code, much faster than they were even six months ago. But where it's interesting is it's not just developers. Now, admins are starting to pill... Pick up this powerful tool as well, and they're starting to use it to generate flows and configuration. So it's not just more changes, it's more people making larger changes across the board.
That's exactly right, Nicole. And those changes are of a different shape.
What we're seeing is that AI written changes are often larger. They touch more metadata at once and are written by tools that really don't know the context of your org. So you get more change from more sources with less human understanding behind each one. One of the things about Salesforce, and I've worked as a solution architect, is that there's often more than one way to solve a problem. And with AI, the approach can vary depending on the tool you're using, which AI tool you're using, which means different tools may recommend different solutions to achieve the same outcome.
Yeah. I think that is definitely very prevalent for Salesforce development, very customizable. But something that we see in almost every conversation is that teams are very, very happy for AI to write code, open pull requests, deploy to sandboxes, but moving that development to production is where they really start to draw the line.
You're right again, Nicole. This is where the stakes are higher and your changes come to life. So it's when metadata actually meets real world data, and functionality is put in the hands of end users. The question is what sits on that line?
In a lot of custom pipelines, the answer is a script that validates and deploys, a person who reviews the pull request. That worked when reviewers had the time to examine every little change in detail. But as the change volume doubles or triples and shared metadata becomes even more complex, review shift from thorough assessments to quick scans. They just wanna get it out of the way.
So every new org multiplies setup. Every AI written PR multiplies approval review. That's the verification bottleneck in practice, and it's where governance really slips.
Yeah. And I think that that's really interesting because when we think about it, reviews are just one of these areas of pain. The... On the screen, you can see that there's some of the other common issues that we really hear about when talking with customers. But, Sunil, in your experience, what's usually the biggest area that custom pipelines do struggle with?
I would have to say the merge conflicts, because Salesforce XML is often nondeterministically retrieved, and multiple people can independently be working on a larger shared file. So teams are forced to waste time resolving conflicts that actually coexist in Salesforce. So some teams are able to solve this, manifest conflict after several rounds of engineering.
Again, that engineering time is the cost.
Yeah. It all adds up every conflict, every profile reordering. But I guess, Sunil, it sounds like this might just be a developer problem because I don't hear a lot about admins when we're talking about poor request reviews, when we're talking about conflicts. What's your thoughts on that?
Oh, it's not just developers. Admins feel it too, especially when it comes to conflicts with permissions.
But because a lot of the custom pipelines were built for developers, admin changes either need to wait for a dev, which causes a bottleneck, or admin changes bypass Git entirely. So they do it through a chainset or a manual change in production where the next deployment quietly overwrites them. It's important whether you are an admin or developer, and this is critical that we all follow the same methodology. At Gearset, we have change monitoring capability that helps determine any changes that are occurring outside of your pipeline.
Yeah. Because I think having mixed deployment methods really makes the audit side super fun.
You're right. An auditor often asks who changed what and who approved it, and the answer is somewhere between git, a Slack thread, and someone's memory.
Yeah. So I guess, potentially provocative question, Sunil, but are these sorts of problems a sign that the pipeline itself was badly built?
No. And I wanna be clear on that. It was built for a different volume. The scripts don't get worse. The load on them gets heavier, and you really get to choose when it shows. It could be a Salesforce release, an acquisition, an audit, or some org consolidation, or a data scare.
Yeah. And if any of these issues that we're showing you on the screen resonate with you, feel free to drop them in the chat. We can discuss them further in the q and a, especially to see how tools like Gearset resolve some of these because we can clearly see that there's a lot of different pressure points. So what we're gonna do now is actually take a look at what's underneath.
And this diagram, shows us what sits below the surface of an in house custom pipeline. It's a lot for teams to think about building and maintaining. So Sunil, when a team tells you, you know, we've built our own pipeline, what have they actually usually built?
So what they've usually built are something... Is something that can commit, validate, and deploy. So GitHub actions workflow or set of scripts that takes a branch and pushes it to an org. In my experience, that part takes only a few weeks to get working, and it demos very well.
It is the most... It is the part that most teams build first, and they get off the ground pretty quickly. The hard part is where all the customization and the maintenance lifts. It's underneath. So GitHub Actions runs whatever commands you give it. So all of that Salesforce knowledge, it actually has to live in the scripts that your team writes and maintains.
Yeah. And if you're a team, I suppose, that's just built a custom pipeline, you're not gonna necessarily see these issues straight away. Right? But I guess, Sunil, what are the first cracks that typically begin to show in a custom pipeline?
There's a few giveaways. You deploy a field without an object or a permission it depends on, and the deployment fails. Or worse, it goes through, but it is not visible in the org. So profiles and permissions sets are commonly difficult to deploy cleanly. And if you run, let's say, CPQ or Revenue Cloud, which is common these days, a lot of the configuration lives in records, not metadata. So keeping the data consistent across environments is a project in itself, and plenty of teams end up rebuilding it by hand in every new sandbox.
So in a lot of custom pipelines, when something goes wrong, the first person to find out is a user, usually the next morning. Then someone has to do a lot of work, what changed.
So they do the digging through Git history, Slack threads, and asking whoever was around that day.
To undo it, the usual fix is to deploy the old branch, but that means wiping out an entire release when only one component was hitting an issue. And if data was affected, you're hoping that the backup worked. So in an ideal world, you'll get notified within minutes whether that is a failed deployment or a change nobody expected. You will see exactly what changed, who made it, who approved it.
You would roll back in a few clicks, deletions included. If data's involved, you would restore from a backup that you actually know works. And all of the log...
All of it is logged as it happens. So you don't have to build anything new for the auditor.
So let me just get this straight because are we saying that with the volume of change that AI is creating, no matter how many gates you actually have in place, something will break eventually.
Yes.
So I guess I guess the goal then shifts away from no errors ever.
Instead, it becomes catching those errors and undoing them as quickly as possible.
Exactly. So recovery time is the number that matters, and it is the part of the pipeline that, people rarely build first.
So I suppose why don't more custom pipelines have all of these safety nets that we've talked about?
Because every one of those safety nets is something your team has to build, like a script, and keep working. So alerts, a history of who changed what, rollback that understands deletions, a backup you've actually tested, the audit trail. Each one is a script or a job that somebody owns. So to to be fair, the teams that build their own free tools cover a lot of the basics. So if you're using SFDX, Git Delta, Code Analyzer, GitHub Environment approvals, you've already solved for those deltas, the scanning, and the approvals. But what's left is the detection and recovery side, and that's the hard part.
Yeah. And I suppose that's also the part that doesn't just automatically stay up to date with Salesforce. Right?
Yeah. As you know, every Salesforce release can add or change metadata type, so the scripts need updating and retesting. Every CLI or API version change does the same. When something fails at six in the morning, someone's on call to work out why. And most teams, that falls on one or two people who built it. That is a key person risk sitting right inside your release process.
Yeah. And the more change, of course, that AI brings, the more that small key person group has to absorb. Now, if you're listening and you're thinking, hey, this sounds a lot like our pipeline, you're not alone. Because if any of this is resonating, that's the whole purpose for this webinar. Feel free to write any questions you have about how to overcome these problems, how Gearset solves them. Write them in the chat and we'll get to them at the end.
So we've now looked at how the rate of change we're seeing with AI affects the maintenance burden of these custom pipelines. But now I wanna look at the final and the most complex part, which is the release itself, the things that aren't included when we consider that straight line from dev to production.
On this screen, you can see three of the use cases that most of us will recognize, and this will be really where a custom pipeline becomes even more fragile, however you've built it. So Sunil, do you wanna kick us off from the top?
Yeah. Let's start with the back propagation. So as you know, whenever a change reach...
Reaches production, including hotfixes, environment behind it needs that change too. So we're talking about UAT. We're talking about QA and all of the developer sandbox. If they don't get it, there's Drift.
Then the next change is tested against an environment that does not match production. It fails or worse, passes in testing and then breaks in production.
Yeah. Yeah. That's very common, I think, for a lot a lot of us. But how did DIY teams typically handle that backpropagation problem today?
It's usually a script that someone has to maintain, and someone has to also notice when it doesn't run. So with more changes going out, it falls behind faster. Then we have these longer running projects, projects alongside your BAU release. So let's say that you're rolling out Revenue Cloud over a six month period while the business still needs fixes every week.
The project work can't block the daily releases, but it has to stay up to date with...
Or you have a huge merge at the end. So scripting this means managing extra branches, keeping them in sync, and then resolving conflicts by hand. Most teams either avoid long term projects or dread the merge. And my experience with Salesforce, there's going to be a longer term project or initiative.
And then there's the the layered module or multi org release. We're starting to see this, along large enterprise clients. So multinational orgs often split their metadata into packages or modules that depend on each other, a core layer then regional units on top of it. They have to deploy in the right order, and a change to the core module has to flow up to everything that depends on it.
So getting that script right is real engineering work. So it also has to be kept up with the org changes.
Yeah. And I think these are three really good examples where all of these are something that AI development is going to exacerbate the problems with. Right?
Exactly. So you're gonna see more changes, more drift with these longer term projects, more conflicts, more ordering problems.
And earlier, we said that teams are happy for AI to write code and open pull requests, but production is where they draw that line. And our research backs this up. 42% of teams actually want no AI involved at the release stage at all.
That's the right instinct. AI is generally useful across the pipeline. It could write the change, review it, and even suggest a fix, but the decision about what ships has to be something you can trust and repeat. A general AI reviewer can give you a different answer each time you run it, and it doesn't see your live org, and it doesn't know the context of it. So, naturally, it cannot be that final gate. The final gate is the deterministic check, a named approver and a full log. AI can suggest your pipeline decides.
Plenty of you will already have a gate and approver. The real question is what the gate can see and verify against.
Yeah.
And I guess for those teams who've built their own custom pipeline, Sunil, what have you probably... Well, I suppose... No. When... For those teams that have built their own custom pipeline, what have they already built, and where are the gaps?
So you'll see on this left side, most most teams have already built this left hand column. There's free tools that do it very well.
The gaps are right here in the middle. So you have permissions and dependencies between metadata, sandboxes don't match production, environments falling out of sync, and really no clean way to roll back when something breaks.
We've seen all of these today. So the right hand column is what Gearset does to close that gap, And the gaps that Gearset fills makes a huge difference. Remember that 40% statistic that we talked about at the beginning where teams being confident in the AI changes we mentioned at the start? Well, in that same research, teams with every stage of the DevOps life cycle covered from planning to operations were nearly three times as likely to be confident in the security of AI generated changes as teams with gaps.
So what we're gonna do now is see what each stage can look like with the with the demo. So I'm gonna pass it off to Nicole to to walk through a quick demo of the gaps being filled with Gearset.
Thanks, Sunil. And what we're gonna do is we're gonna follow both a human and an AI ridden change through Gearset, mapping those to the rows we just talked about, you know, the pull request, the deployment, getting environments back in sync, and of course, what happens when something inevitably breaks.
So as you can see, here is my Gearset pipeline, which is a visual representation of my environments, and this does include longer running projects that have had their own subpipe subpipeline. Like Sunil said, the key with those longer projects is making sure that they are kept in sync with releases to production so that when they are ready, they can be smoothly released into the main pipeline.
But like Sunil also talked about, what's really important is that each environment has inbuilt quality gates running on deterministic checks, flowing all the way from the developer sandboxes up to production.
So we can see on the pipelines, there are numbers representing the number of features waiting to go into each environment, and these, of course, will include both changes made old school by, you know, traditional developers and admins, VAs, as well as AI driven development. But all development must pass the exact same checks.
That being said, it also does need to be flexible enough to handle urgent real life scenarios. So if we take a case that, you know, we hopefully will all never encounter, but we probably will, let's say something is broken in production and we have an urgent hotfix that we need to deploy in. We don't need to worry about reviewers being free, about QA testing resources being available, about the developers who run the scripts being online, we simply open our pull request against production using a UI that's accessible to the entire team. Now, as soon as this pull request is opened, the checks are automatically run. So we're validating this against production. We're running only relevant unit tests. We're checking for merge conflicts, but we're automatically resolving those that are not genuine and are just a waste of time.
And we're also automatically checking for any development standard issues. Now in our case, we can see immediately that the deployment would have failed, and this has stopped us from merging in a broken branch into Git that would, of course, completely break this pipeline. My automated review is also caught in this case that I'm not following the organization's standards. So in this case, missing a custom field description, which should, of course, affect my org in the long run, the debt piling up some data hygiene as well. So I'm going to go into the sandbox, and I'm going to fix this development directly in their hotfix environment, and then I'm going to update my branch and my pull request waiting against production.
With Gearset, we can commit more changes directly to that branch, and we can add in those missing components. So we can bring in any missing flows, any missing dependencies that we need to make sure that we include, ensuring that we have the correct components for our deployment and validation to succeed to production, including permissions as well.
Now as soon as we update the branch, Gearset is going to revalidate and rerun all of our gates. For this case, I've gonna save you thirty seconds of waiting for a validation and I've prepared the exact same components on a second branch. We can see now that the validations is succeeding, that there are no issues found in this pull request, and we can now go ahead and actually promote this and merge it into main, release it to production, but only after first making sure that we run a backup so that if there are further issues, we can restore both the metadata and the data back to how it was.
So we're gonna go ahead and merge this into production, release it directly here.
But there's an issue here. We've had the flexibility to deploy to production, but this hotfix isn't in these lower sandboxes. And like Sunil said, that's one of the core issues with a custom pipeline. How do we make sure that we keep our environments in sync? We'll see that Gearset automatically takes care of that, opening backwards promotions to the lower environments, including even all of your developer sandboxes to make sure that they all have the latest metadata from production.
But as the pace of change increases with AI development, we've discussed so does the importance of proactive monitoring to be able to react quickly to live issues because they are going to happen. So being able to monitor not only what has been released and when, but actually the overall health of production as well. And this is where Gearset can notify you directly of any critical errors that you've got and show you all of those top errors happening in production, their overall incidence rate, who's being impacted, and allow you to actually triage those directly, which here, Gearset's AI triages the issue by first scanning your entire production org's metadata to be able to understand how things link together, as well as looking at your deployment history to be able to understand what changed to cause this spike in these areas, to make sure that we really understand the context this area is happening in.
And this, for those of you who haven't seen it before, is our agent cam, which is embedded across the entire Gearset platform, not just addressing production issues. It can, of course, be handed net new tickets, help you understand existing processes, fix failing tests, all of those things. But once it understands the issue, it's going to be able to actually propose a fix for you.
But just like a member of your team, this fix isn't just going to be applied and sent straight to production. We want to make sure that we have the chance to review it, that we have the chance to see what it has actually developed, and if we're happy, we then can go ahead and open up a pull request for this change. At which point, Gearset is going to feed it into the same quality gates that we've seen already. We're making sure that the same standards are applied, that it's validating successfully, that the unit tests are passing, that our development standards are being respected.
And if there are any issues here, Gearset is able to fix them automatically before we even promote that pull request and turn it into further rework for our team. Because Gearset knows not just the nuances of Salesforce in general, but also your org and your deployment history.
And we can now see that this pull request is going to be targeting our very first environment in our pipeline, still hitting all of those gates that we've discussed, that they've already run, they've already passed. And so it doesn't matter if it's an admin, a developer, a partner, an SI, or an AI creating development, they all have to follow the same gates. They all have to follow the same standards.
And just to wrap up with one more thing Sunil kind of mentioned is there is a big upkeep to making sure that your scripts have the latest metadata, that they keep up to date with the latest releases, particularly for those of us working with Agentforce, Data 360 components. With Gearset, we are an off platform solution, which means that we are keeping up to date with all of those as and when Salesforce releases them. So anytime there's an API change or there's an update to Agentforce, which happens more often than the API changes, those will all be applied automatically, ensuring that you are using the latest available functionality in Salesforce, including any security patches that have come through as well, with no maintenance required from your team.
So to summarize, it's been a quick whistle stop demo, but we've been able to see how a custom pipeline would require different aspects to stick together in order to support those long term projects, those hotfix flows, the deterministic quality gates that run, that solve your merge conflicts, that keep your environments in sync, and that also monitor production for those inevitable production issues, which we can then, of course, hand over to AI to quickly resolve.
So with that, we're now going to stop sharing and actually talk about a customer story and what happened when a team's homegrown pipeline met a sudden jump in volume.
So we've got here Ping Identity, one of Gearset's customers, where essentially they were using a homegrown pipeline built entirely on the Salesforce CLI. And when a merger doubled the size of the team, it couldn't scale. So they moved to Gearset and went from deployments that took days to shipping continuously.
And their senior DevOps engineer, Andrew Cutter, put it quite simply, but we would have a much larger DevOps overhead without Gearset.
Which raises the obvious question, What does keeping up with a custom pipeline actually cost? Because when teams compare buying with building, Sunil, what do they usually miss?
It's usually the the license cost is visible. So the maintenance cost usually isn't because it's spread across people's time, so it never shows up on an invoice. And the biggest part of it now is verification. So how much time it takes to review, failed appointments, rollbacks.
So as AI increases the volume, the cost grows with it.
And I suppose what what about those teams who say, you know, we already pay for GitHub Enterprise. Why do we need to pay for a DevOps tool on top of that? Isn't it just paying twice?
Well, that's a very fair point, and it's often why teams build in the first place. So one well run team that we spoke to keeps maintenance generally low by design. Most of their effort goes into the new features. The question for them isn't maintenance. Maintenance. It's whether they have that capacity that scales with AI volume and org count growth. So you gotta ask yourself what your best engineer would be building if they weren't focused on deployment features.
Yeah. That that's a that's a good way of putting it. And I guess to help everybody who's attending this webinar think about your own setup a little bit more here, we've put together this checklist, and of course, I'm not gonna read this all out. But Sunil, which one, in your experience, do teams typically underestimate the most?
And we've been coming back to this a lot, and you showed this in the demo. But managing rollbacks and keeping those environments in sync so developers are working on the latest and greatest code, that requires a significant amount of effort. So, ultimately, developers need to be working against the latest code code base in order to avoid conflicts and inconsistencies. So this is especially critical after deployment or a hotfix when all of the environments need to be aligned so processes are ready for the next sprint.
Yeah. And I think, I'm seeing a few questions come through in the chat of kind of, well, how come AI can't help us with, you know, keeping those kind of processes in place? And it definitely can help speed up the development of those back deployment mechanisms, but what you really need in those cases is not AI running to try to bring those changes down, right? So now you need to have something that knows for a fact that these components are missing or not present in an environment. That's why we keep saying this word deterministic, I think, in these cases.
But I think one of the questions that kind of comes out all the time when we discuss this is people wondering, okay, so if we're buying a tool, are we completely ripping and replacing everything that we've developed so far?
So it doesn't mean that we're starting all over. So the Git branches and the pull request, they'll stay where they are. What we typically see is teams replace the Salesforce deployment pipeline first. They'll keep the GitHub action jobs that still earned their place, like the code scanning and retire the rest of the scripts over time. So we know moving to Gearset Pipelines is a big change for many teams, and we don't expect customers to make that transition overnight, especially with critical projects underway. One example of a customer that's taking more of this phased approach because their q four is their busiest time of the year. So we understand that change management is important, and we want teams to transition at a pace that works for them.
Yeah. Absolutely. And I think when we really consider DevOps, it's not just the deployment process. It has lots of different stages, and teams don't need to mature every single stage at the exact same time.
In fact, that's the opposite of what we would typically recommend. The priority is really about finding your team's current priority bottlenecks in that DevOps life cycle and then identifying their root cause. Unblocking that is where we focus the first stage as we scale up. But I think this feels like a pretty good time to get to to the questions that we've got to discuss maybe what a transition to a tool might look like or just the upkeep of your current process and how you can go about doing that.
So I think there's there's...
If you have any questions, please pop them in the chat now. I think there's been a couple come through, that we're gonna go through in a little bit more detail. I think Alice Alice has answered a couple of them but just so we the chance to talk through them properly. So Sunil, I'm seeing one from Angelo that kind of talks about, well, we're talking about the rate of changes made by devs increasing with the use of AI, but what about the idea that DevOps engineers also use AI to maintain and enhance their custom pipelines quicker and more efficiently?
Yeah. So when it comes to, the...
There's... There are key items that we have to consider here. So we wanna talk about the deltas between the repo and the org deep knowledge of the environment. These are the things that we wanna take into consideration when we're building out our pipeline, some new initiatives that are coming through, as far as long term projects or any new, initiatives like rolling from CPQ to, Revenue Cloud.
And I think the second part of that question as well, and I'm seeing Ellis is also answering this in real time. The second part that Angelo had, the maintenance will also be sped up with AI. So wouldn't having Gearset restrict restrict the usage of AI for the creation and the maintenance of the pipeline? And I think here, maybe, Sunil, it's it's good to be clear that Gearset, in some ways, is actually going to replace the majority of that maintenance for that pipeline. So maybe if we we dig into that a little bit more.
Yeah. With the new tools like CAM and Agent, along with the org intelligence tools, we're able to basically look into the org and verify things are working as expected.
Yeah. Exactly. And I think that that's kind of the key is there's AI tools that can be used for development, and then there's AI tools that can be used for maintenance. So if you are using AI as a DevOps engineer to up keep the pipeline, that's still time that's being taken away from developing actual functionality for the business. And that's where at Gearset, we have our own team of, I think it's about 100, a 100 engineers that their sole purpose is to create pipelines specifically for Salesforce that, you know, are aware of merge conflicts, that can resolve those intelligently, that can do those rollbacks, Delta deployments. So of course, Angelo, you can use AI to build these pipelines. It's just the opportunity cost of what your team would be doing if they weren't maintaining them.
Yeah. Maintenance, especially when we have complex scenarios and use cases, like moving towards larger term projects.
Absolutely.
Okay. Then we've got...
No. I don't think that's a question from Chris, but we just got our licenses this month in the process of planning and preparing our migration. Very excited, but also nervous how this transition goes. I think nerves are are a normal part of any DevOps transformation and that's really where people like Sunil are so invaluable because they're here to share their expertise on the things that they've seen work well and what doesn't.
And the most important thing is that we do consider that pace of change. It's not about overhauling your entire process overnight. It's about figuring out how can we make sure that not only is the tool in place, that the people are ready to use it because DevOps is very much people process as well. So Sunil, I don't know if you have any nice words to say to Chris to encourage them on their their journey here.
Yeah. Absolutely. And we we have a great onboarding team that will get your team up to speed. The key thing before jumping into any implementation is to ensure that we have a proper branching strategy in play, you know, making sure everyone is comfortable going into that implementation. And that's what the DevOps architects do to help you solidify that branching strategy before you implement, so you build with confidence.
Yeah. Absolutely.
One more question then coming in from Nicholas saying, can you expand on how CAM, that's Gearset's AI, development agent... Oh, sorry. The chat just moved. How CAM adheres to Salesforce best practices, but also to your team's design standards or preferences? Sunil, you mentioned there might be many ways to solve the same problem, so he's curious to know how Gearset approaches this.
So oftentimes from a CAM perspective, we're taking input from, like, the architecture... Well architected site from a best practices perspective. So Cam's taking that input in order to help generate the output. But at the end of the day, what is generated with AI still needs that human interface in order to review and and push through the pipeline.
Yeah. And I think that it's important when we talk about, you know, is the tool ripping and replacing? If you've already worked with agents, you know, you've created some MD files, is that something that you can carry over? Absolutely.
Because CAM not only will read, you know, the org and the structure that you've already got in terms of your repository and how you've worked in the past, it will apply, like Sunil said, the Well Architected Framework, but it will also respect those standards. So those MD files that you might have, you know, spent hours on trying to find naming conventions, when it should default to Apex or Flows, CAM can of course respect those things because the beauty of the Salesforce ecosystem is how customizable it is, which means that there is no one correct answer for everybody. It's all of those working in tandem, and then like Sunil said, having that human review is paramount, making sure that there is somebody signing off.
Because as we've seen, there is responsibility with the things that AI creates, and it will sit with your team as the developers.
And, Nicole, there is one question is around how it is different from a general AI code reviewer. How is this different from that? How would you answer that?
Yeah. That's a that's a great question. So in in the demo, we showed a little bit about Gearset's automatic code review. One of the biggest differences between a general code reviewer is that it's built for many, many languages.
It's not just built for Salesforce, and Salesforce is a very, very particular beast. So when reviewing Salesforce metadata, it's not enough to look at files in isolation like we do with PMD, where it's just looking at the Apex class by itself. That doesn't take into context how it interacts with the rest of the org. So Gearset's Code Reviewer does two things that are very different.
The first is that it looks across all metadata. It's not just code. We're talking about every piece of development. Layouts, flows, Lightning Web Components, everything that can be touched will be reviewed.
That's, of course, important for AI development. The second is that we don't look at these files in isolation. We do traverse method calls. We figure out how things are interacting with each other to actually know is this a real vulnerability or is this just a false positive?
So I think a lot of the teams that we talked to have used PMD in the past and have been a little bit, hesitant because of the amount of false positives that they get. So really, Gearset's Code Reviewer is there for the full breadth but also for the depth because we only focus on Salesforce. We can really make sure we're keeping up with every new metadata type that Salesforce throws at us as well.
Perfect. So I think we are coming now to the end, of our webinar. So I do wanna thank you all for joining this webinar with us today, and Sunil, a big special thanks for you as well. Expertise is absolutely invaluable. Ellis, thank you so much for for fielding the chat. We will be sharing the recording with everybody, but thank you so much for your participation.
Thanks a lot.
Have a good one.
