Description
New to Salesforce DevOps or looking to strengthen your foundational understanding? This session breaks down the complete DevOps lifecycle tailored specifically for the Salesforce platform. You’ll gain a clear understanding of how each stage connects, the key tools and best practices involved, and how to start building a robust DevOps pipeline that scales with your org.
Luke Harris – VP Customer Success, Gearset. Luke is VP, Customer Success at Gearset. He’s spent 15 years building operations at global software companies. During his career he’s worked in ERP, Finance, Marketing and now DevOps technology, and focuses on how humans and technology can solve real world challenges. He lives in the UK with his husband, daughter and more recipe books than he could ever cook from.
Transcript
Hello, everybody.
Is this going through a mic? Oh, that is a mic.
So I have no idea if there's one person I can see Jeremy and then like some people.
So if I don't make eye contact, I apologize, but these lights are bright.
Thanks for sticking around to hear the full view of the DevOps lifecycle and how that makes all the difference. I'm really looking forward to walking you through this today.
For those of you who I haven't met, I'm Luke Harris. That was me pre children.
Look at him. He looks so well rested, doesn't he?
I'm Luke Harris. I'm the VP of Customer Success at Gearset.
A little about me, I've been back in the Salesforce ecosystem for about about three years here at Gearset having first been in this space as a Salesforce admin back in two thousand and nine, which was the year that Salesforce launched Service Cloud and my dear dear friend Chatter, who I miss or will miss dearly.
Nowadays, I get to work with a hundred strong customer team and our three thousand customers globally many of whom I see in this room.
So I hope what that gives me is a little bit of a viewpoint and a little bit of permission if I could be so bold to share a few thoughts about how DevOps knits together.
I'm going to cover two simple questions about the DevOps lifecycle today.
What is it?
And why does it matter?
And then we're going to look at an example so that it's not all super abstract and theoretical.
So let's jump in.
So the DevOps life cycle isn't a gear set invention, of course, it's it's not even a Salesforce specific thing either.
The life cycle or infinity loop is a widely used visualization of the DevOps process for any platform. Now kind of today's talk is designed for folks who are perhaps at the early stages of understanding what DevOps might mean for them and their org, but hopefully there's something in here for everybody.
You'll sometimes see versions of this as a simple circle.
Sometimes it's an infinity loop most often and that shape reflects a couple of things. It's showing an iterative cycle that keeps running rapidly and continuously.
It's roughly the left and right bits of the loop represent the traditional development and operations stages and the loop combines those two things.
But as you can see, there's no one version of the DevOps lifecycle. These are just a few examples grabbed pretty much at random. I could do a pop quiz of like where people recognize these from but as I said, I can't see any of you so it'd be pretty productive.
But the idea is the same.
The number of stages and the names of those stages are pretty different.
So the question really is like which of these really captures, the essence of DevOps and which of these things makes most sense in a Salesforce context and that's really what we're talking about here today.
So, here's how we think about the DevOps lifecycle at Gearset. Now, we've made some choices, whilst we're not reinventing the wheel here, we've made some choices based upon our philosophy of DevOps and our experience as I mentioned of working with thousands of Salesforce teams of all shapes and sizes of different age production orgs of different focus areas.
So, let's run through that.
Plan, it's about determining what needs to be built. Tooling can help here but honestly, it's mainly about people.
It's so important to have great relationships with your end users for this to dig down to what they really need.
And at Gearset, we're really obsessed with the Job to be Done framework.
Bob Moesta is one of the architects of that framework is someone I've gone into many rabbit holes of the Internet seeing what he talks about and I'd highly recommend it for anyone thinking about how they can approach this this plan phase in their org.
Build is about creating or improving something whether working in Flow Builder, in Versus Code or something else.
If the rest of the life cycle is running well this is where you should get to spend most of your time in our experience. For those building in a DevOrc, a platform like Gearset makes it easy for anyone to be committing work to a feature branch at this point and you can already start to improve quality at this stage by bringing in code analysis to your editor and getting real time feedback.
Now I should call out that some lifestyle diagrams would have a test stage here, but in our experience and what we see from the most performant Salesforce orgs Testing doesn't just happen at this stage and this stage is about more than just testing.
Validation is about making sure the work is right, not just that it works.
And so it's important to have a culture of peer reviews, shared accountability for release quality. And you also need powerful tools to automate tasks, unit tests, UI tests, code analysis, which really massively help teams catch issues early both in code and config.
At the release stage, you want a streamlined pipeline. No friction, no bottlenecks, simplicity of clarity and observation but also the right level of gating and approvals to save more pain later.
The exact setup really varies by team in terms of environments and branching strategies.
But the fundamentals should be consistent.
Continuous integration, committing or combining work early, continuous delivery, shipping value to users as early as possible to tighten that feedback loop and this is only possible with lots of automation where steps are reliable and repeatable and that reliability and repeatability is very important.
Teams shouldn't dread releases.
Like, I will do a show of hands here, like how many people at some point in their career have like dreaded the lead up to a release and like hands over eyes, like done the button thing, right?
Pretty much every everybody.
And that's a horrid place to be.
It's not something that you want to carry into every release that you're doing.
Now, Operate is probably where I expect things to get a little less familiar for some folks here because Salesforce handles your infrastructure so some of the traditional ops related responsibilities don't necessarily apply but you are responsible for all your data and metadata, right?
Bugs or data loss can cause disruption for your business and this stage is all about keeping production running smoothly and reliably.
So backing up your org is essential to secure production and archiving obsolete data streamlines the performance of your org, right, as well as reducing those storage costs over time stopping them ballooning and eating into the budgets that you have.
Now more and more teams are adopting these tools and viewing them as part of DevOps and not separate concerns.
Now this observe stage is a new area for lots of teams and truly it has a relatively low adoption today, but we're certainly seeing some emergent trends that I wanted to share because I'm confident the picture will change because observability is such a powerful technique.
Too often teams find out about issues in production from their users telling them.
You think about the business users of the orgs that you're working in. Maybe sending a screenshot that takes back and forth to figure out what it's actually showing, where it is, what user it's appearing for, let alone fix. And observability is essentially automating that process and helping you catch the signal in the noise that's happening around it. You can monitor issues in production, triage them, and resolve issues before users report them.
Now this is also great for reducing technical debt in your org so you've got stable foundations for future development. We had a customer breakout morning today that a few of you are involved in and one of the topics that came up again and again was this notion of tech debt and what that means for engineering and technology orgs but also what the real world impact of that tech debt is for users and what we carry forward into the way that we're working with our business counterparts.
If I just step out of the theoretical for a moment and and talk about gearset if I may. We're building out a product in this area and we've launched flow error monitoring and there's more to come on that soon.
So that's a really quick tour of the stages of the DevOps lifecycle.
But around the outside, we've got some universally applicable aspects of the work that we all do security, testing, collaboration, and automation.
And if you think about if you think back to the point I made earlier around plan about how so much of that is a human endeavor, is working with our colleagues, when we think of these universal aspects of DevOps, some of this is deeply seated in technology and regulation and some of it is equally seated in human connection and understanding how we work and they're essential to have throughout the lifecycle. So security shouldn't just be about production, you keep production secure by baking in security practices through the whole lifecycle.
Similarly, testing shouldn't just be at the stage before release. You want to have relevant tests running throughout relevant to the important thing there. You don't want it to be cumbersome and overbearing, from the dev environment to production and including in production itself. And DevOps is all about collaboration between teams who interact with any point of this life cycle.
And the rapid iterative approach the life cycle represents is it just isn't possible without automation wherever repeatable processes are established and that I would urge folks often one of the early conversations that we'll have with people or I'll speak to folks who are thinking about planning their next six nine months is wanting to jump straight to automation of what's our approach for automation here going to be and actually the questions are always about what's the reliable repeatable process you already have in place that you know works, that meets the needs of your business and your users because without that you're automating something that may be effective.
So, you'll just more quickly and with less touches get outcomes that you don't want or don't need and I think that really matters and points a little bit to the collaboration piece that I've just talked about So I guess as well, it's a pretty self selecting group at DevOps Streaming.
But hopefully we're all interested in and in the pursuit of excellence when it comes to to DevOps and we're all happy to sit and talk about DevOps theory.
But if I try and move it from the abstract to the practical, It's about talking about why does this stuff matter? What's the real world impact of the DevOps lifecycle and why should our teams back home or in our businesses care?
Firstly, the life cycle is great to measure your DevOp processes against.
How does your team perform in each of these areas? What are the sticking points and what causes friction? And where have you got the right tools in place and where are the gaps?
This illustration shows a fairly typical Salesforce team right now. Let's say we're using Jira, GitHub, Gearset.
They're strong in the plan build and release phases and that's great. The release stage is a really impactful place to start with Salesforce because releases can be pretty painful. Show of hands showed us that earlier. Right? So we're getting a CICD pipeline built that's really tightly integrated with JIRA and GitHub and that's great.
But there's even more potential for improved performance.
The validate stage could be stronger with testing code and config analysis pulled earlier. So issues aren't always spotted right before release. The operate stage probably could be more robust, right, with backup and archiving in place in and whatever form that needs to take for your business to keep production secure and streamlined.
And the observed stage could be transformed with new tools so you can proactively find issues in production that need fixing.
So DevOps is all about continuous improvement, right? And there are there isn't this endless sprawl of stuff that you need to consider the lifecycle and it gives you that comprehensive view and if you cover all of this by means that make sense for your business you'll close the remaining gaps in the process where problems most likely arise or go unnoticed at the moment.
And another great thing about the lifecycle in our experience is it shows all the different stages that should form one cohesive process. You might find that someone is looking after a particular particular stage Maybe there's a security or data team looking after backups for example that operate the operate stage But is that team integrated with the development team or siloed away? DevOps at its core is about collaboration if we think about that wrapper and especially the collaboration between teams with different functions that should really share information processes and tooling with each other One more big reason for thinking about the life cycle and this one's all about the performance of the overall process and to do that optimizing for the whole life cycle reduces the cost of delivery, right, and to do that optimization you shouldn't mainly measure success by individual stages Instead you need to look at performance across the whole cycle each stage should make the subsequent stages easier and the key here is that principle of shift left.
Catching issues earlier in the development process.
If you think about it When do you want to catch a critical bug or error?
There we go.
This is what this illustration is showing if you spot a problem pretty early on at some point before the release, right? In a build or validate stage the cost is honestly pretty low, right? You might even be the only person to know that it's even happened. You haven't wasted much time or effort.
If it's caught in the release stage, it's a little more problematic.
Everyone can see your errors holding the release up until it's untangled or removed and you're back to the drawing board with a lot of time wasted if it's really critical.
Now if it's caught in that operation operate stage like I like it's in production. It's the it's the worst case scenario, obviously. This is where end users and the wider business are impacted fixing it becomes a priority that pushes out other work.
This is probably where your boss gets pressure about how it happens.
So to improve performance you really want to invest in processes that shift left and be wary of heavy testing processes at the late stage because that hurts your velocity and when we talk about speed of the whole thing bringing that pain forward catches security performance and integration issues as early as humanly possible when a quick course correct is still pretty painless.
And notice that you can sort of keep shifting left back before a sprint begins with observability.
You're catching issues and feeding them into the planning phase.
In one sense, it's not the ideal place to find an issue because we're talking about production but we all know that those issues are there, right? And so it's great to be uncovering them and starting tackling technical debt something that again comes up lots in in conversations when we think about our planning and what we're doing. And we're not just shipping new work that's high quality you're improving the underlying and existing codebase and performance of your org as you do that. So I've talked a little bit about the lifecycle why it matters but it is still a little bit theoretical and I've really tried today not to talk about Gearset products to give something that's accessible to everybody no matter what the tool stack is that you are using. But if you forgive me for a couple of slides, I am going to talk about how we see teams doing it using GearSet and what that looks like in practice.
I'm actually going to start this scenario at the observed stage, right? My flow error monitoring job in Gear Set has flagged a flow that needs to be fixed as a priority.
Let's imagine it's a flow used by an agent that's really a vital part of our agent force rollout.
So with this insight, I'm going to plan out the changes I can make with this flow. I'll talk to the teammate and users to work out how we want the error handled then I'll head to Flow Builder and make those changes.
I want to commit those changes to a feature branch as I make them and normally moving flow between the environments is a bit of a nightmare. There are tons of dependencies, there's a versioning challenge, but for something built visually it's often really hard to visualize what changes are being committed.
And at this point I have to show you what we've done with Flow Navigator. If you haven't seen this before if you speak to anybody in yellow they'll give you some something more interactive.
This is how Gearset shows you the flow changes that you've made.
It looks like Flow Builder but we're highlighting the elements that have changed between the source and target environments for this commit or deployment and you can even switch between versions of the flow.
So now my changes are in Git and this means a bunch of testing and analysis fires off in the GearSet in GearSet for this validate stage.
Automated code reviews, for example, just doesn't check Apex but other metadata like flows as well. So before I've even merged my changes and started promoting them along the pipeline I'm already getting any warnings about security vulnerabilities or issues of quality and consistency.
And as I start promoting the work through the release pipeline that validation and testing continues.
So through the release process as my PRs are automatically created against the next environment I promote changes to I'm confident of finding out about issues at the earliest stage possible.
Ultimately, I ship the fixed flow to production and given all of that automation around ensuring quality the chances are very good that that flow performs perfectly.
But for the sake of this illustration, let's imagine something slipped through and in production the flow starts scrambling data wherever it runs.
Now thankfully, we can quickly roll back the metadata changes and restore the data because it's all backed up in Garset.
And so we can clean up production efficiency efficiently and fix the flow again.
Now there's obviously loads there that I can unpack in detail but I wanted to stick to my promise of just talking for a couple of minutes about Gearset and it illustrates something of what the DevOps lifecycle looks like in practice.
And as I wrap up I suppose there's just a few questions that I pose to you all as we finish.
These are going back to what matters for your team performance which is really think where are the gaps in your process and performance.
Perhaps seeing the lifecycle today has highlighted a process or tooling gap for your team.
Most likely it's the start of a conversation you should be having internally about how you can collaborate and fix that gap.
Who's involved in your DevOps process? Are any teams siloed?
Who's currently responsible for these different stages? What does communication look like? Is there any ambiguity gray area around ownership?
And then the third thing perhaps the most painful bit is be honest about where you usually catch issues.
What's the impact of that?
Do you approach releases with confidence or like back to that time where we put our hands up with fear of the release that's to come about it being routinely painful?
I'm going to leave things there for the whistle tops tour of DevOps Lifecycle. Thanks for taking the time out.
I'll be here for the next couple of days.
If you want to dive into any more of this in more detail, give me a shout.
But for now, I think you've got a break. I think some of you have got the agenda in front of you, but I think you've got a break for about twenty minutes.
So, coffee and refreshments are back in the main room, but thank you very much for your time. Appreciate it.
