An introduction to Salesforce DevOps

Share with

Description

Discover the five core pillars of DevOps and how they combine to supercharge your Salesforce release management in this Introduction to Salesforce DevOps. You’ll gain an overview of Salesforce strategy, version control, testing, automation and backup.

Gearset’s Jed Ingram led this session at DevOps Dreamin’ Seattle ‘22, the largest Salesforce DevOps event.

Learn more:

Related videos:

Transcript

Welcome, everybody, to DevOps Stream in Seattle.

So before we jump into our Yeah.

Before we jump into our first session, I just want to thank everybody for taking the time to join us here today.

I know this is a busy old time of the year for everybody. We've got Thanksgiving just around the corner. We've got the holidays coming up. So to take the time out of your day and come to join us here is really well appreciated.

And did you know this is our third DevOps streaming event this year?

Yeah, third. And it's gone by very, very quickly. But we started off in Chicago earlier in the year, and if anyone was there they got to witness a great talk by Charlie Isaacs on I think it was the Internet of Things, and he did an incredible handstand on stage. I was thinking about trying to pull that off, but I don't think I do as well as him, so I'm going to avoid that one.

And then we went to London more recently, and we have an incredible panel there speaking about mental health and burnout in the ecosystem, which was really insightful. And now we're at Seattle, and we've got an incredible lineup of speakers over the next couple of days. Talking about a range of different things, we've got centers of excellence. I think that's one of Ian's panel.

We've also got DevOps ROI, which is going to be really interesting. We've got a couple of other really good talks. So I'll definitely have a look at the agendas. I think they should be on the table.

Plan the next couple of days to make sure you get the most of the time here.

Alongside this, we've got some incredible workshops. We've got one next door, and then we've got two I think it's upstairs talking about a range of different things from pipelines to CPQ. So I definitely recommend checking that out. Out. I think the most important thing is for everyone to have fun, get to know the community a little bit better, make sure you speak to as many people as you can, learn as much about Salesforce DevOps over the next couple of days, and just have a really good time. So with that, I'm going to kick off with our first session of the day with an introduction to Salesforce DevOps.

So what it is and why your team needs it.

I'm not going to go into a very long intro here, but just to introduce myself very quickly, my name's Jed Ingram. I've been at Gear Set now for the past three years, and I've worked in the Salesforce ecosystem about the same at the time. But I've been fortunate enough to speak to probably lots of you in the room and lots of other people around their Salesforce DevOps process, understanding where they're right now and where they'd like to get to in the future, and then guiding them on best practices and the best way to get there. But if we haven't met yet, it's really nice to meet you all. If you fancy coming to say hi later on or tomorrow, then please do so.

But to start us off, how did we get here?

So before we get into what Salesforce DevOps is today on the platform, we need to rewind a little bit and just think about where we've come from. So some of you may remember building on the force dot com platform.

Delivering changes here meant using something like change sets or the AMP migration tool, which are quite primitive tools.

Very labor intensive, often error prone, and sometimes a little bit of a painful experience to move the changes to where you want to push them to.

But fast forward to today, and Salesforce is a much more sophisticated platform. The platform is under constant development with new awesome capabilities being added daily, which understandably everyone wants to leverage, and more complex customizations are now possible as well.

So with this, there's growth in complexity and scope of configuration.

We're essentially asking more of our admins, our release managers, our devs, as those older tools and processes and practices are becoming a little bit less effective.

So if you're still following this methodology, you're likely spending more time managing and coordinating features and releases, not delivering improvements as quickly.

And there's a greater likelihood of introducing a bug in production, and reacting quickly to that bug is much more difficult. And ultimately, your company's probably not getting the most out of their Salesforce investment.

And with that, over the last five or so years, I'd say, there's been a real shift in the ecosystem and the tools and practices of DevOps to fulfill the growing need to make it easier to deploy those complex changes, and deploy them safely as well.

And Salesforce have, of course, responded well with improvements to its native tools like DX and more recently, DevOps Center. And then we've got GearSet as well, which was founded because we experienced the pain firsthand of managing these complex releases.

We wanted to bring our expertise in the DevOps world to the Salesforce ecosystem.

So why is Salesforce DevOps more important than ever?

Simply put, it's the new standard for release management and brings Salesforce closer to DevOps practices across the wider tech space.

With it, it also brings a bunch of benefits.

First off, the developer experience is better. You get predictable and safer releases, which means less time spent firefighting, less stress, and more importantly, you get to spend more time on the fun stuff developing.

And by removing this friction from releasing, there's much less frustration in making these changes as well.

And you can also deliver value quickly.

Implementing that new feature adds value. The whole point is to get that feature into the hands of your users as quickly as possible. The longer the feature takes and sits around collecting that dust, the longer it takes to realize that value.

But it's not only more efficient, you'll also get quicker feedback about what works well and what doesn't work so well, and you can iterate towards that better solution.

I think it was our CPO who said this initially, and it stuck with me, but the tight feedback cycle is just invaluable here.

The quality of what you deliver also improves as you have more opportunities to find and fix bugs before they make it live.

If something does go wrong, and something probably will go wrong at some point, you'll be better placed to recover. You can identify bugs quicker, and then you can roll back by changes easily.

And DevOps isn't just about doing quicker deployments for the sake of it either. It enables you to get the most out of your Salesforce platform investment and increases the ROI, ultimately making the whole business more successful.

And the Gainset, we're fortunate enough to speak to thousands of people in the local community. And from what we hear, the most common thing is that people are put off by the term DevOps.

They assume it's too complex for their current team, size, shape of that team, or it's not appropriate for their Salesforce setup, or even the business they operate in.

But we just don't think that's true. Regardless of the make up, the size, the shape of your team, or what you're working on, there are definitely DevOps patterns and practices that can benefit your business goals.

So how is DevOps Salesforce unique?

There are lots of different definitions in the ecosystem for what DevOps means, and you'll find lots of different viewpoints if you Google the term. For sure, DevOps is about automation. It's about combining dev and ops teams. But these are just a little bit too specific for me. I think the most encompassing definition that I can think of is DevOps is a way to continuously deliver high quality software by bringing dev and ops specialists together under a common business goal.

But Salesforce is a unique platform. It takes a lot of the complexity you might usually have to deal with, things like managing infrastructure, scalability, site reliability, security.

And that list probably goes on a little bit further than that.

But this is all great. This is good, because you get to do the fun stuff, you get to do the development, and you get somebody else to manage all the rest.

And because Salesforce is a unique platform, the implementation of DevOps on Salesforce can look a little bit different. And that's what we're going to explore over the next couple of slides.

So with that, let's walk through what Gearset sees as the five pillars of DevOps.

You'll probably be familiar with each of them five terms there, but it's not always clear how they can relate back to DevOps, or how you and your business will benefit from them.

As we run through each of these, I want you to consider what you have in place at the moment, how it's benefiting you, what's put you off adopting some of these things, what's blocking you from adopting, and then what issues are causing you the most pain and frustration, and how would each of these benefit you and the team around you.

So let's start off with strategy.

I'd probably say the most important and arguably the trickiest to navigate.

So at GIZIP we speak to lots of different people, and we help them with lots of different processes.

And consistently, the teams that have the best time adopting DevOps are those where every team member is brought in.

Words we hear often and over and over again are collaboration, clarity, and understanding.

So we believe DevOps is something that should be accessible to your whole team, no matter the size or the shape of that team. It's only when everyone on the team appreciates the value that it works really, really well. Building this culture of empowerment isn't always easy. It can mean defining roles and responsibilities that didn't previously exist.

It could mean upscaling people on the team. It could even mean bringing new people to the team that didn't exist. And even then, it might require a slight change in mindset. And it might even cause some friction, at least in the short term.

As we found out from our recent state of Salesforce DevOps survey, a key theme throughout was the cultural challenges that came with adopting DevOps. Many teams were struggling to get buy in from external stakeholders across the business.

So obviously, improving your release process is really, really great, but staying focused and getting investment from your leaders can be a little bit more difficult.

And it probably depends on your organization as well.

So you can essentially have the best tools in the world. But without a clear strategy for implementation, a culture that includes the whole team, it will be much harder to find success with DevOps.

So next up we have backup.

So Salesforce data or metadata can be lost or corrupted at any time through human error, malicious attacks, integration bugs, and we probably hear a couple more every single day.

It's worth spending time to mitigate this risk. There's no way to remove the risk entirely. It happens to teams big and small, older and newer.

And it's probably best to think about this as when this will happen to you rather than if.

It's absolutely critical to have a backup and restore solution in place, but what's the benefit of this in terms of DevOps?

So when you experience a data loss in your Salesforce org, your priority is to minimize disruption to the business by recovering as quickly and accurately as possible.

As we spent a lot of time discussing already, being able to quickly and confidently make changes is DevOps.

And then when you're recovering from any incident, you can follow best practices and restore via your usual release process that's well defined and well understood by the whole team. The alternative is risking further damage to production.

Instead of one problem, you now have two by making a bad deployment.

If you get chance, there's a chap called Alex Walters floating around. He's an expert in all things backup and restore. I definitely recommend taking a couple of minutes and chatting to Alex about this.

Version control is probably the most fundamental technical component of any DevOps strategy, as there are many, many benefits that come with it. To start, it gives you a source of truth for your configuration.

This is probably a term that will come up a few times over the next couple of days, and I'm sure most of you are aware. If you're not, consider this as this is how things should be.

But wait, isn't that my production org?

Sort of. Version controlling your source of truth is preferable because it's much more robust, as every single change made is tracked, and you can't just permanently delete or corrupt your configuration, which is a little bit of a risk if you just rely on what's in your production org. And because every change is tracked, you can review changes before they're made live, which means you get more eyes on your code. It reduces the likelihood of knowledge getting silent, and it helps spot bugs early.

You can also easily coordinate multiple contributors. I won't go into the weeds about different branching strategies here. But in brief, individual developers can contribute new work in isolated feature branches. And then once a feature is finished, these changes can be merged into the main branch to be shared with more people.

This will allow you to develop features in the same org in parallel, helping avoid overwriting each other's work and treading on one another's toes. It'll also help with auditing, as you'll be able to see what's changed and why. It aids with debugging.

This thing was working yesterday, but today it's not. You can look at what's changed since then and understand what's gone wrong.

And finally, you can annotate your development work, giving a complete history of every change your team has made to the org.

So next up we have testing, and testing is an integral part of development as DevOps is all about managing your entire development and release cycle, which does mean incorporating testing into your release process.

Testing comes in many, many different forms. All teams have to do unit testing, as Salesforce enforces this. Some teams use UI testing, and then there's also static code analysis testing.

This is an automated process to check your code quality, which guides you towards good code hygiene, and you can spot functional issues or style violations.

And then of course, there are pre prod environments like QA or UAT that you might do some automated or manual testing in. So I think the phrase to remember here is testing early and often is key.

So that might look like testing your change in isolation, testing that your change combined with other people's changes work, testing that your users are happy with this feature in UAT.

Then monitoring production regularly, checking for unexpected or unauthorized changes.

And aside from being good security best practice, be mindful that unexpected changes could break stuff, so regularly running your unit tests in production is really valuable.

And then testing at several points might sound like a big time sink at first, but you're really investing your time. Spending time now could save you a lot of time further down the line.

The further a change gets through your release pipeline, the more confidence that you have that it's safe. So by the time you're about to deploy it, you've removed as much risk as possible.

So finally, we have automation.

And there are plenty of ways you can use automation in a DevOps process, but I'm going to focus on the big one, CICD. So continuous integration, continuous delivery.

CI is all about bringing together different work streams.

It automates the process of checking that different work items function correctly, can be combined safely, can be deployed successfully, and then you get feedback as early as possible when something's broken.

And then CD, Continuous Delivery, is about releasing frequent small changes to users by automating either some or all of that release pipeline.

This reduces manual steps, frees up time, and also reduces the chance of human error.

So combining CI and CD reduces the pain and risk from deploying changes to multiple environments.

The smaller and simpler a release is, the less stuff that it affects, the easier it is to reason with, and the safer it is to do so.

The reason for this is because it's harder to introduce a bug.

But if you do introduce one, it's easier to spot as there's a smaller surface area to consider when tracking it down.

It also makes you more agile, as you can easily roll back mistakes or unwanted changes. You're able to respond quickly to incidents and reduce downtime and disruption.

And finally, it promotes a real user driven approach to development, as you can get faster feedback from your team and end users, which helps you iterate to a better solution.

So automation is the key to achieving a fast flowing release pipeline. There's a session going on, I think it's next door, from Richard and Mark that will be talking about this in a little bit more detail and what's possible with release pipelines.

So with all of that, what's next on your DevOps journey? This is a fairly common question that we get asked. So we've put together this maturity model that some of you might have seen before.

And all teams will fall somewhere along this model.

This gives you a really good way to benchmark where you're at now and where you'd like to get to in the future.

So over on the left is beginner.

Basically no DevOps process. Teams here are often either making changes directly in production, or doing infrequent and large scale releases.

Moving up the scale, you can adopt version control for some of your metadata.

The goal here is to gain familiarity and confidence with version control. You start to appreciate the benefits of it over time, and you'll be able to pull more and more metadata in.

And then with enough metadata, you can let version control become your source of truth.

You can build this out even further then by focusing on automation, which will push you towards doing small, frequent releases.

And then finally, you can integrate backups closely in your DevOps process, enabling you to quickly and effectively respond to an incident.

One big misconception here, though, is that when you're adopting DevOps, you have to do all of this in one go.

Go from beginner all the way to the end in just one hit is just not true.

What's worse is that attempting this will probably make your team much less likely to adopt a successful DevOps process.

The teams operating successfully at the mature end of this scale didn't get there overnight.

And I can talk a little bit about gear set here as an example.

We've got a really, really mature DevOps process, but we've been iterating on that over the past six years. And we're still iterating, and we're still finding improvements.

In the same way that delivering great software means making small, incremental improvements over time, becoming a team with a mature DevOps strategy means unlocking the benefits in increments.

Okay, so any changes to a team's existing process can take time and focus. This is a short term disadvantage that you need to accept to get to those long term advantages and benefits. You're better off spreading and minimizing the cost of this disadvantage over a longer period.

So I think the best thing that your team can do is take small steps at a time. Think of something that you're not doing today that you'd like to do in the future, and just take that away and start implementing.

Because after all, DevOps is a journey.

So hopefully, that's given you a really good overview into what Salesforce DevOps means to us. As mentioned at the start, there's lots of good talks and lots of good speakers lined up over the next two days to dive into these things in a lot more detail.

And hopefully, you'll come away with a better understanding of what is possible.

But before I go, I'd like to mention that once you've soaked up all of your knowledge here at DevOps Streaming, you can head over to DevOps Launchpad dot com, and you can continue that learning.

It's a free fun platform that's fairly interactive that we've put together for anyone in the Salesforce community to expand their DevOps knowledge. So check it out for sure. But I just want to say thank you all again for taking the time to join us, and have a wonderful time here. Thank you.