Description
Top teams aren’t lucky — they’ve mastered the DevOps lifecycle. Catch up on this session from Dreamforce 2025 to discover how to plan smarter, release faster, and scale without chaos.
Speaker:
Laurence Boyce, Sales Engineer
Transcript
Hi, everyone. I'm really excited to be here looking at this topic with you. As a quick instruction, I'm Lawrence, one of the SEs at Gearset. And for any folks not familiar with Gearset, we're the leading DevOps platform for Salesforce.
So for any folks not familiar with Gearset, as I mentioned, we're the leading DevOps platform platform for Salesforce. We support over three thousand teams globally ranging from small businesses to large enterprises. And for them, we've delivered over thirty five million deployments.
And they really enjoy working with us, proven by our ninety eight percent customer satisfaction score, something we're really proud of. So let's jump into it. It's worth saying that the term DevOps isn't always used consistently, so don't worry if you're a little unclear on it. DevOps isn't a process or a tool. It's a methodology, a way of working. And the whole point of DevOps is pretty simple. It's about increasing your team's ability to deliver new features and solve critical issues quickly and to do it with confidence.
So it's no surprise that the teams who really embrace DevOps best practices are the ones achieving some pretty impressive outcomes.
They release to production far more frequently. They see shorter lead times for making changes and deploying new features.
They ship better quality code, which means fewer bugs and fewer service disruptions. And if something does go wrong, they can restore service much faster. And that's the promise of DevOps, faster, safer, more reliable delivery of value to your users. So how do we go about achieving this?
Well, let's look at the DevOps life cycle. Many of you will be familiar with this kind of diagram. But for those of you who haven't seen this before, this is showing you the complete DevOps process. Every single stage from plan through to understanding how production is performing. And don't worry if it looks a little intimidating as to some degree, you all do all of this already. At least something a bit like this diagram.
You plan, you build, you validate, and you get your changes live. You maintain your environments, and you get feedback that feeds back into the planning.
But you might be thinking, okay. Great. But why should I care about this life cycle?
Well, here are a few reasons. Firstly, it gives you a complete road map, not just showing you what to deliver, but how to build, validate, operate, and observe in a way that works for Salesforce.
It helps you catch issues early. Shifting left is a term commonly used for this during planning or validation while they're cheaper and much less painful to fix. There's nothing worse than discovering an issue during a release or even worse in production.
It gives you and the whole team visibility. You know, not just what's going on, but not only we need to build this feature, but how will it behave in production? Will performance degrade? Or are end users finding bugs that I don't know about?
And you should care about the life cycle because teams who do this well release more often with less downtime. It builds confidence throughout the business, both within your team and also with end users or key stakeholders.
Plus, as your team scales as well as your processes, the life cycle helps you see where your gaps are. Maybe you're testing or monitoring a week. Maybe release processes are fragile. You can pick the next area to improve systematically rather than just fixing what hurts most right now.
I won't go through every detail of this diagram right now. If you'd like to unpack it further, of course, come and speak with the Gearset team or contact us via Gearset dot com.
Okay. So we've covered Gearset, DevOps, and the life cycle. It's time to take a look at how the best teams are leveraging Gearset to do DevOps right right now.
So firstly, to set a little bit of context for anyone who's not seen Gearset before. Gearset Pipelines, just one part of the Gearset platform, provides a visual, automated, CICD workflow for deploying user stories through a git based release process, providing one single interface for all team members irrespective of their skill set or experience.
Straight away, you'll notice a couple of things. Blue boxes represent a user's dev org, and the green boxes represent the CICD jobs that will support the automated deployment processes.
And you'll also notice these gray boxes. These are long term projects where you can create a pipeline in a pipeline. So you can develop longer term work without needing to push those changes to production immediately, especially beneficial, for example, if you're doing a multi quarter RCA or agent force rollout as this allows you to deliver it without freezing parallel development.
So we're gonna have a look at the DevOps life cycle in the form of three personas. We have Dave, who is the Salesforce admin developer. We have Sandra, who is the release manager. And we also have Eamon, who is the platform owner and engineering manager.
Now, of course, they all have their very different roles, requirements, and responsibilities when it comes to the software development process.
So we're gonna use these three personas and their day to day work to explore the life cycle in more detail.
So let's hop into Dave's shoes and see how his life looks. So for all intents and purposes, I'm now Dave, the admin and developer.
There's no single right place to start in the DevOps life cycle. But for today, let's begin at the plan stage.
A new work item has just landed on my plate, so my planning starts here. As you'll see, I've been asked to build a new sales discounting process for industry changes.
Before I write a single line of code, I need to understand what already exists in my org that relates to the account industry change process.
Here's where I use Gearset's org intelligence, and I can simply ask, when an account industry changes, what happens?
Now this is gonna scan across my entire org and help me understand how this process takes place today.
Without this, before even building anything, I'd have to spend a heap of time understanding my org and using a variety of tooling.
So this helps me get clear, deep insights before ever making a change, removing the guesswork, and getting the complete picture about areas of the org that I might not be familiar with as I might not have any prior knowledge or experience.
So what we'll see here is Gearset is scanning across my org to get deep org context.
And what we're showing is when an account industry changes, there is a flow that handles this event.
By selecting the flow, I instantly see the relationships of the flow detailed clearly, its dependencies and references, of course, to understand before modifying this flow. I'll also get a visual summary, which helps me contextualize the flow further.
Taking this one step further then, perhaps I'm not entirely sure still what this is doing, or I'm moved to the Salesforce team. I can simply generate a summary to explain the item, providing me all the context and information I need before I jump into action to implement the discounting process.
This can, of course, support me as well with internal documentation, perhaps hosted in Confluence or on other sites to ensure any legacy metadata is documented appropriately.
From here then, I've got all the necessary information I need start working on implementing the required change.
I can even go back into Jira, copy my acceptance criteria, and paste into Org Intelligence and ask how how I should safely implement these required changes.
This is where we'll see the power of combining deep org awareness with Gearset's expert understanding of Salesforce metadata.
Great. Now that Org Intelligence has planned this out for me, I can go ahead with confidence to implement these changes, safe in the knowledge that I'm not gonna be impacting any process unexpectedly.
So this means that in the plan stage of the DevOps life cycle, before Gearset, a lack of visibility resulted in long planning cycles, fear of breaking things, and creating tech debt.
Whereas with Gearset's Org Intelligence, I get instant clarity into my Salesforce org, mapping dependencies and history so I can design, plan, and build changes with confidence and speed.
So let's fast forward then to the point where we're about to deploy this change into the pipeline. For your sake, I won't build these changes live. Like any decent demo, I've done that ahead of time.
When creating a new user story, I simply select the environment where I've built my change and select new feature.
Gears enables me to tie this to my ADO or Jira work item upfront. So this will create a feature branch in Git as the container for my changes. And this will then be tied throughout the pipeline to the story that I've been working on.
All of my metadata will then be pulled into the comparison view, sorted by when it was edited.
And immediately, you'll see something quite interesting here.
Gearset's flow navigator helps me understand what changes I made in my flow that I'm about to deploy. The flow version lets me verify that I'm comparing the version where I made the changes, not looking at our teammates.
And additionally, we'll also notice here that Gearset is multilayered. So within this flow, Gearset has identified a dependency, an Apex class and some custom fields, and a few other items. So I can ensure that I bring these along to make sure my deployment succeeds.
But perhaps I was rushing or didn't quite know what this meant. I can proceed from here.
And here's another example of where Gearset's built in intelligence helps me succeed.
As soon as I scan the package, Gearset looks for the most common failure points or deployment issues called problem analyzers.
These draw on a deep understanding of Salesforce orgs where things typically go wrong based on knowledge of over thirty five million deployments.
In this case, it's flagged several additional dependencies that I had missed. So instead of a frustrating back and forth, I can select everything in one go, get it right first time, and avoid nasty side effects later.
From here, I simply move forward. I'll get a preview of what is going to be deployed, and then I can simply commit these onto my feature branch.
This will then take me back into Gearset on the original screen from a pipeline perspective that we saw earlier on.
Of course, following a commit, the next stage is to open a pull request. And, of course, this can be done via Gearset two.
Over fifty percent of pull requests lack descriptions, and those that do have an average of fifty characters, which can lead to misunderstandings and increase the time needed for reviews. So AI is built into this stage, providing a clear summary and impact risk analysis and even testing recommendations.
This also gives phenomenal context on the change for excellent audit history in case we need to circle back on these PRs at any point in the future.
Alongside that, I can log any pre and post deployment steps right here. And this gives a centralized checklist so nothing gets missed, and everyone on the team is aligned. Once the pull request is opened, it kicks off a series of quality gates and checks and will take me back into Gearset Pipelines.
So from my perspective, as Dave, the admin and developer, I'm most likely done. And now I'm ready to go back and work on my next Jira ticket.
So at this point, it's worth taking a quick step back to see where we're at in that DevOps life cycle.
Org Intelligence supported Dave in the plan stage by understanding the current state of the org and the build stage with tailored suggestions for how the Jira work item should be carried out in the safest possible manner.
Then Dave used Gearset Pipelines to simply cherry pick these items and commit them to a feature branch before opening a pull request for review.
So from Dave's perspective as an admin and developer, there's three main benefits.
Org intelligence, removing the guesswork, giving a full picture of the environment to make confident changes.
Impact analysis showed Dave how the changes will affect the org before deployment, so less time is spent troubleshooting.
And it's a process that empowers Dave to follow DevOps best practices of frequent commits to feature branches while working on their stories, which promotes a culture of rapid development.
So DevOps done right in the plan and build phases is about getting the right knowledge and tools in the hands of the right people at the right time. Streamlining this key part for software development life cycle, empowering faster innovation and delivery while maintaining stability.
So now we're gonna switch switch personas. We're now gonna be Sandra, the release manager in the team. So please now assume that I am that Sandra persona.
Gearset appreciates each customer is on their own DevOps journey with different pipelines configurations. So pipelines is totally configurable to match the required environment structure.
Additionally, many teams like us aim for a continuous delivery process. Gearset enables me to tailor the exact automatic propagation policies that I like. Meaning, once testing is complete, we auto promote stories through QA to UAT as quickly as possible as soon as that review has passed.
This automation greatly streamlines my work as a release manager, removing the need to manually promote stories. Instead, they'll be deployed as soon as they've been approved and back synced to sandboxes early too.
Here against QA, you'll see my PRs, including the one that Dave has opened. Gearset has a sophisticated merge conflict resolution engine, which eliminates thirty to fifty percent of all conflicts by understanding the function of metadata, not just the lines of code. For example, when two separate permission changes clash on a profile, a normal git merge will flag a conflict.
However, Gearset identifies them as independent and safely auto resolves the file. This is deterministic logic, not guesswork, saving my team from fixing conflicts, conflicts that aren't actually conflict.
However, when real conflicts arise, Gearset won't try and auto resolve these with guessing. The conflict is open to the user to specify how these should be handled. And, critically, it'll remember how the merge conflict is solved when promoting to higher environments.
But as we can see here, Dave's change doesn't have any conflicts, but it does have a guardrail in place due to these pre and post deployment steps that must be completed before proceeding.
Additionally, of course, a peer review is an essential part of the software development pipeline, and Gearset will honor the exact configuration I have set up in my version control system, such as branch protection rules and code owner assignments.
Additionally, one of the most important part in the gear set process is an automated code review.
So here when a PR is opened, a code review scan will run, and this elevates a simple peer review check into a strategic quality gate.
This scan analyzes every change against best practices and the well architected framework to catch vulnerabilities, flag bottlenecks, and enforce standards for high quality code, helping our team avoid embedding technical debt or risking a security breach.
I can tailor the gates to be hard warnings or hard blockers or just warnings, and the owner can dig into the report to see the exact problem and even get a deterministic auto fix to save time in the remediation.
These reviews cover all Salesforce metadata, including flows. So for those familiar with other scanning tools, this is a Salesforce bespoke equivalent, scanning all metadata with a much tighter integration with the CICD tool and auto fix logic.
My settings have blocked this change, so it's kicked back for the to the owner for remediation, which must be completed before the deployment.
This team also ensures our team shift left and test regularly throughout the life cycle, catching potential vulnerabilities earlier in the life cycle while they're quicker and cheaper to resolve.
Now, of course, this also aligns with many of the new guidelines in Salesforce's updated well architected framework.
So following this fix by Dave and my get approval, this will trigger the automatic promotion through the pipeline honoring the continuous delivery rules that we saw earlier.
Of course, though, we should also talk about other areas of testing.
Gearset's in house UI test builder provides an easy, accessible way to automate testing, especially for teams currently relying on manual tests.
It offers a lower barrier to entry without being a heavyweight complex tool.
Dave and the admin team were able to plug this in on day one, easily integrate it into our process, and it required minimal prior experience.
All that was required to build a test was to simply feed Gearset a prompt.
The prompt is simply the job that we're testing for, and the AI took took this prompt and translated it into the exact user steps by generating a test script in the background.
The real intelligence here is that Gearset captures the UI as it goes through the script in real time, passes, interprets, and contextualizes the information, then creates the next step based on that understanding. So more broadly, this means the issue of the Salesforce UI moving due to updates or changes that we've made is not gonna cause my scripts to break every time requiring manual intervention. It's proactive. It gets ahead of any issues.
So for myself as a release manager, the time saving is immense. And Dave and the team estimated this would have taken them several hours to write by hand.
As we mentioned, the real intelligence is the AI understand my org's context and makes tests resilient to minor UI changes that would break hard hard coded scripts.
And once these tests are saved, it's reusable against any of our other orgs for a clear pass or fail result. And from the testing dashboard, I can see that history and can run tests when required, ensuring those tests pass before promotion of my stories.
Of course, if I had a third party testing tool such as AxleQ, Provar, Eggplant, or Test Sigma, I can integrate that with external services too with those results fed back into the pipeline like I see here.
A release into production will often contain multiple stories. And as you'll see here, I've got a couple of open pull requests. However, maybe only one has been approved for my next release.
By opening a release, I'll have Gearset simply merge releases, merge stories onto a common feature branch, and Gearset will compile and validate these as a whole release against production.
This means that as I add a second, third, fifth, tenth, etcetera, story into this release branch, this will give me the confidence that these will deploy successfully together as I wouldn't have had that by independent releases.
This is a major win for me as a release manager as this process then enables me to have the confidence that these will deploy when I either deploy now or deploy at the scheduled deployment time that I wish. The and, of course, this process aligns seamlessly with the deployment schedule that I'm working towards for the business.
And, of course, for those scheduled large deployments, as Gearset continue continually validates these packages, this provides me the confidence that they'll they'll deploy successfully at that scheduled time.
Additionally, I can see the data backup status directly in my pipeline, and this empowers me to take full control and proactively manage the risk of the release rather than simply relying on what's in place.
I can check the status of my backups at the exact moment I'm about to deploy and, with a single click, create a precise up to the minute recovery point for the objects I'm touching, ensuring I'm fully prepared for a seamless rollback and data recovery if needed.
This means I can confidently deploy without being haunted by the question of what's the risk here. By knowing that if something does go wrong, I can quickly restore to the exact state of the org before the deployment, not just from last night's backup.
Additionally, keeping dev sandboxes in sync with the latest code base is critical to avoid building on outdated files, which leads to conflicts and issues later. For our team, this was a time consuming and risky process, often causing work in progress to be overridden. Due to this, Dave's team often abandoned this altogether or ended up drowning in PRs with tens or even hundreds waiting to be backpropagated.
Because of this, we adopted Gearset's streamlined syncing solution in pipelines. It will track promotions to the main branch and present them as updates for users to easily deploy back into their dev sandbox.
It maintains the correct promotion order to avoid dependency issues and syncs multiple updates in a single action, eliminating the need for multiple PRs. And most critically, it will detect if any work in flight was gonna be affected.
It'll capture those changes and enable the team to safely merge the changes back into the sandbox, to prevent overridden work.
And, of course, this uses the exact same merge conflict resolution UI that we saw earlier.
And this is also brilliant for myself as a release manager to see which team members are keeping up with the updates and who's falling behind.
Now let's take a step out again and see where we're at in that DevOps life cycle.
We just covered the validate and release phases, which will soon bring us to the final stages of the life cycle, operate and observe.
But from Sandra's perspective, DevOps done right with Gearset is about standardizing the release process, bridging the gap between developers, admins, and other teams with a defined process all team members can confidently follow.
DevOps done right with Gearset is around a single source of truth to gain full visibility into deployments with a clear documented record for compliance and control.
And DevOps done right enables teams to deliver changes faster with less risk by all by leveraging an automated deployment process, reducing human error and ensuring they can confidently release without breaking production. And even if something untoward does occur, Gearset's backup and restore solution is there when required.
So what about that third persona? Aamon, the platform owner. Well, let's jump into Aamon's shoes and see how Gearset supports from a platform owner perspective. So I am now Aamon.
As a platform owner, having a bird's eye view of the health of my Salesforce org is mission critical. To this end, Gearset's observability solution enables me to have this single pane of glass, providing key insights such as email sent versus my limits, platform events, and my storage usage, perhaps suggesting I should implement an archiving strategy.
But in the next month, we are planning to implement Marketo as an integration. So it's essential for me to know how much API usage is happening on a day to day basis to know if we're gonna hit any issues.
Straight away, I see this chart, which highlights to me exactly where we're at on that daily cadence so I can ensure I have suitable headroom for our upcoming integration.
Alongside this, of course, a key part of my role as a platform owner is to ensure we're continually improving the quality of Salesforce over time, delighting our users. So on the left hand side, this graph shows me how many Apex exceptions and flow errors are being hit daily or over a certain time window, as well as comparing this to the previous period. This means that I can see we're on the right track and improving the health over time.
Even though these charts are looking wholly positive, I'm still getting grumbles every Monday from the sales and finance team that the org isn't reliable.
So with gear sets, flow error, and Apex exception monitoring capability, I can get right into the stats and gain visibility into what's happening.
By zooming on the graph, I can isolate exactly which flows are causing the serious issues. Immediately, I'm I'm able to see this one here. The weekly invoice for finance flow is not firing.
Of course, this is causing serious impact to the business, so I'm able to use Gearset's observability capabilities to see exactly where the issue is in the flow and create a Jira ticket directly from observability to restart the software development life cycle process. But, also, I can use the Gearset agent to summarize, identify the root cause, but suggest the possible fixes for that error so that I can add those into that Jira ticket for the team to remediate.
And, of course, this is a game changer for me.
Previously, I did not have this high level insight into any of these metrics, especially in a single view. Whereas now, I'm empowered with the right information to make decisions based on data as opposed to gut feel or guessing.
Of course, observability is also incredibly powerful for Sandra from a release manager perspective to check flows in Apex are working as expected before deployment. And to know if anything untoward does occur, the cause can be traced back easily to a specific deployment for remediation.
So if we zoom out again and think about the benefits from AIMEN's platform owner perspective, not just in the operate and observe stages, but when adopting the full DevOps life cycle.
By automating key processes and providing tools for dependency analysis and code quality checks, Gearset helps Aemon proactively prevent issues that can lead to system downtime. This ensures the platform is stable and reliable for users, reducing the time and resources spent firefighting.
Gearset provides the guardrails to ensure that all changes are safe and secure before they're deployed.
This minimizes the risk of introducing security vulnerabilities or breaking mission critical processes, ultimately lowering operational cost and protecting Aman's business.
And DevOps Done Right ensures Aman has a single unified control center of their entire Salesforce platform, including all changes, deployment histories, and dependencies across teams. And this level of control allows AIMEN to govern the platform effectively, ensuring all development aligns with business goals.
So let's summarize all that we've covered then.
DevOps done right is about replacing legacy ways of working, where changes are held back for long testing cycles. DevOps done right is about testing early and releasing frequently to build confidence in the quality of work and the reliability of the release process.
And DevOps done right is about seeing the whole DevOps life cycle as one and optimizing overall performance with the right tools.
High performing teams are doing more than just the release part. They need to have testing, observability, and the full life cycle. But this can be very daunting to know where to start, so it's worth noting a couple of things.
Everything is modular with Gearset, so you can dial up various parts based on what's most important at that time.
The whole is greater than the sum of the parts, and Gearset o offer totally free consultations to understand your current processes, ways of working, and to guide you on that journey.
Thank you, and please get in touch with the Gearset team if you'd like to discuss any of this further.
Goodbye.
