The business case for Salesforce DevOps

Share with

Description

With more and more companies looking to get the most out of their Salesforce investment, DevOps is the key to unlocking a raft of benefits from faster delivery to more reliable releases. Building a seamless DevOps process is a vital step to long-term productivity and added value for end users, and a successful Salesforce implementation.

Catch up on this webinar with Jack Weatherly, Sales Director EMEA at Gearset, where he talks through the benefits of a comprehensive Salesforce DevOps solution. He’ll show you why taking full advantage of DevOps can improve product delivery, boost customer success, and increase business reliability.

Learn more:

Relevant videos:

Transcript

Okay. I think we're more or less, ready to go.

So, yeah, we'll, we'll get started.

Obviously, we've got some time today, to just talk about the business case, for Salesforce DevOps, and why it's important to, embrace DevOps as part of a DevOps transformation.

This is taking place within your organization and and pretty much, in every organization.

So, yeah, speaking today, is just gonna be me. My name is Jack Weatherly. I'm lead account executive at, at Gearset. You may have been expecting Kevin, our CEO and cofounder, to join the call as well. Unfortunately, he's, he's had something else come up, as things do, I guess, when you're, CEO.

I'm not running you through this today.

As any questions pop up, please do pop them in the, the chat. I'll try and keep an eye on that and answer things as we go. It looks like we've got quite a small, number of attendees today, which is which is actually a good thing, to be honest, in lots of cases.

He's really can dig into some questions, and some scenarios and use cases for you.

Just a bit about my background. I started at Gearset, yeah, about three and a half years ago, when Gearset was made up of probably about nine people, I think it was.

Really built out the, sales team since then.

Don't worry too much, though.

The sales, role that we have really is probably more in line with a a presales engineer or technical engineer that you might see elsewhere. So very much more on that technical side, for today as well.

So very briefly, just about our gear sets. So appreciate lots of people, on the call today will be familiar with gear sets. Some of you might not.

So gear set in brief, is a is a release management tool for Salesforce.

We spun out of actually a larger DevOps company, that work on other platforms. About five years ago now, they adopted Salesforce.

They saw that, you know, being in that DevOps industry, an ecosystem, the the solutions out of the box weren't tailored to their requirements, shall I say. Things like change that's not quite delivering the value that they needed.

That turned into a project, internally. That internal project obviously had some some good results and good progress, and they turned that into a a spin off business.

And that's how we got to GSA as it is today.

So we offer essentially a full suite, of DevOps solutions.

So ranging from metadata migration and compare, data migration, data backup, and and obviously some other things, in between.

We work with, some of the largest companies in the world, really to just improve that DevOps experience overall.

Typically, people do use changes around to begin with, and then move through that process, picking up gear set and other tools and processes along the way.

We normally see a sort of, a speed of those releases, sort of being increased by about ten times eight to ten times. So taking things down from a day to an hour, is is quite a common scenario.

As a whole, though, you know, we cover, really every part of DevOps. So you should just need to, essentially, pick up Gayside as a one stop shop for all those requirements.

So there's a few key concepts that we'll talk about today. I appreciate these are very basic to begin with. Everybody's going to be familiar with them, but it's worth talking about them, sort of how they fit into this project.

DevOps, it's pretty obvious one, as I said, but, but really it is that idea of combining and bringing together the admins and devs to actually build that configuration, that customization on the Salesforce platform and get them to work really closely with the people who are responsible for the, deployment of those changes. In lots of organizations, that'll actually be the same people, in which case you're pretty inherently, tied into that DevOps model. But in lots of larger teams, you will have admins and devs and dedicated release managers. And bringing those people together is really what this process is about.

Digital transformation is, I guess, is the is the larger umbrella that this sits under.

The adoption of, you know, digital technology to transform services and businesses, typically, in our case, you know, replacing, manual processes. I'm pretty sure, you know, we're using Salesforce, non digital doesn't really apply. There's manual processes that sit on top of Salesforce, replacing those with automated processes. And to be honest, as Salesforce grows within your business, probably are going to replacing, some non digital, processes as well. So truly the umbrella that that the DevOps and and what we're talking about today sits under.

Agile development is really the framework, I guess, for lots of the benefits and lots of the, the ways of working that we'll talk about.

Really, the idea of agile is to break up large projects into significantly smaller pieces of work and then tackling those one by one and delivering to them to the customer, in those smaller pieces. So continually involving, sorry, improving, and releasing changes.

It gives us loads of benefits. The biggest one is going to be flexibility. So we don't have to deliver everything in one go. We can start, get a few pieces out, and then move on to something else if our priorities change.

So this talk's gonna cover, a few topics here. The first one's just sort of creating, the vision, I guess, the plan, what you're actually going to be doing, and and really how do you get engagement within your organization for this idea of DevOps.

Next up, we'll look at targeting value nice and early. So no project in any company, is going to plan not to see value for any significant period of time. But, really, what we want to do here is is is DevOps is going to be a long term initiative and engagement, and we need to see value early on in that process to make sure that the business is happy, that our teams, admins, and devs are happy with with the progress that's being made, and that the buying continues to grow.

We will have a look briefly, at how Gearset, handles DevOps internally. Some interesting things that we do, some interesting stories there. So we'll touch on that, and then we'll go down, once we've seen our internal model, some of the things that you can do to really get started down this route as well.

So we'll get started here. I expect to run for about thirty, or forty minutes. We'll leave some good time at the end for questions.

As they pop up again, I'll I'll try and, grab those, and address them as well.

So as we said, at the beginning, we want to create that value, that vision, as as early on as possible. And by having a clear plan of how we're going to approach DevOps, we can make sure that that happens.

A really important first step to that is understanding your starting point.

This is, really the the foundations that we want to build off, and knowing where you actually sit at the moment is is really integral to that.

Most of the people that we work with really are in that sort of levels one up to about level three.

By the time people are in level four or five, they're very, very advanced, probably already using either gear set or another tool on the market.

And so we don't have too many of those conversations sort of new customers.

This is just an example, and really a a template for you to build off of, but it can be very helpful to to identify, you know, the the tools that you're using and maybe change sets.

Maybe you've got a backup, you know, how you work it with other people in the team collaborating to really identify actually what that starting point looks like.

The important thing to note is we're not going to try and get everybody from level one to level five.

That's absolutely not the case, or the goal with DevOps here.

We want to take everybody from their starting position up to what their business requires them to get to. Anything beyond that is essentially superfluous. It's going to be additional cost, additional time that that nobody needs.

So we just need to get to that level that delivers the optimum, business value.

Within that, we want to start targeting really quantifiable outcomes. So before we start the project at all, setting those measurable targets allows us to assess whether we're going down the right path. We talked about agile methodology before. This gives us something to track that against, to understand, how well we're doing and whether we need to make any changes.

So we had that example before of improving, the time it takes to do a release from eight hours down to an hour. That's a nice quantifiable, outcome that we can look for. Maybe to shorten our, release cadence sort of from once a month to once a week. These are things that we can easily identify, easily measure, and they can demonstrate that value for us quite well.

To releasing faster is, it's probably the biggest pain point that we get from anybody who comes to Gearset.

They use change sets. It takes them ages to actually do a release. And the problem with that is that the longer you spend doing the deployment, doing the release, the less time you're actually spending building config, writing code, and actually delivering that value, you know, that part of the job that, yeah, you're you're really paid to do, you know, delivering value to the business. So releasing faster is is a huge value add.

The next thing that we we sort of tend to hear about is improving deployment reliability.

When you're looking at the value of of DevOps, you don't just need to look at how long it takes you to release a single release. You really need to look at how long start to finish it takes you to move those components. So if you're talking about change steps, often they can be quite quick if the set of changes are small. But if you have validation errors, dependency problems, you have to build that package multiple times and keep trying, then that start to finish time gets quite long on average, and that's something that you can address with improved reliability.

Releasing more often, is, of course, a nice benefit as well.

Releasing more often is is neither here nor there in and of itself. The real benefit you get from releasing more often is that the amount of changes, config and code that you're pushing with each release is smaller. So each release in and of itself is less risky.

There's less change. There's fewer moving parts. And if something does go wrong, that makes it easier to identify what the problem was.

You also get some really nice benefits in terms of, sort of customer feedback as well that's more specific to a small set of changes rather than being, you know, just a general approval or disapproval of a whole host of changes, which is less actionable.

The last thing about releasing really often is that, and as contradictory as this may sound, is that your app is more stable from a UI perspective. It it doesn't change all that much. It things move ever so slightly on a regular basis, but you don't have wholesale change, which can confuse users, move things about the app, you know, once a quarter, let's say.

So it gives you that stability as well.

The last thing is decreasing costs, and that might be a goal.

At the end of the day, you know, every organization, time is money. If you're spending time, you know, there's, you know, people hours on these deployments, that that's going to cost you. Whether it's a direct cost or an opportunity cost that you're missing out on something else that you could have worked on.

It's it's going to play a part in decreasing those costs, improving that efficiency there, may lead to, you know, an increased budget and more scope to pick up more projects, all sorts of benefits and and opportunities to to work on other things.

So identifying key goals, is something you'll want to look at next. So outcomes are really the end, sort of that that finish line, if you were. We want to, you know, deliver value to our customers faster. It's an outcome. A goal is something sort of shorter term. You have lots of them, and they'll build up towards that outcome as a whole.

That's where we see this idea of DevOps agendas. Lots of goals along the way.

This is a model that we actually use internally for people management, you know, talking about progression, you know, improving skill sets and knowledge, when setting goals, but it actually applies perfectly here as well to this scenario. So the goals we want to set for ourselves need to be specific. We need to know exactly what we're working towards. They need to be measurable. Touched on that a second ago. You need to be able to understand that progress easily and clearly.

They need to be attainable.

This is something that for goals specifically becomes really important.

Whereas, the outcomes, probably a bit less wish bit less specific and targeted, these need to be really attainable. Relevant is really quite obvious and time based as well. This again is is where the idea of being agile comes in. Time framing these individual goals to assess whether we're reaching them or not, whether we're on track, and whether we need to change those goals to find something, that we can deliver in a shorter period of time to get that value sooner.

Questions come in here, that sort of quick and easy to answer is is what would be a good, or normal pace to release, once a day, once a week, once a month? This depends entirely on your organization, your requirements, that that sort of sit behind that, and your customer base as well. So we'll see in the second case that releases twice a day, because we find that that's best for us. It's really quick and really easy.

If you're in an exceptionally heavily regulated industry, you might have to go through all sorts of approvals for every single release. So when we look at those industries, we tend to see longer release cycles.

That's generally a hindrance and something we want to avoid if we don't need to. So I'd always say to bring that in as as short as you can without it becoming a burden, essentially. So, if you think about maybe once a week, once a fortnight, that's usually a good target for how often you want to release.

Confirming the value is something else you want to put into your your planning stage here. So we want to be able to have a process in place which allows us to confirm that what we're doing is actually offering value to the business.

DevOps is going to be an investment, usually in time within the business. We need to know that we are staying on track.

Obviously, the goals are helpful there. You do need to be open to changing and shifting things up. So if those goals that you're reaching aren't actually delivering any tangible value to you, then you might need to change up those goals. Be open to changing the metrics as well. If you're finding that they're not particularly measurable or it's hard to measure them, you know, month to month, you can change those up.

This process of reviewing goals and metrics, I generally recommend to happen every two to four weeks, really just to make sure you're on track. If you go too soon, you probably haven't made too much progress. If you go too long, there is a risk that you go down the wrong avenue.

And, again, going straight to level five, you know, going immediately for an outcome instead of those short term goals is going to lead to a sort of disconnect where the goals and metrics aren't delivering the value that you need.

Another question here about, our release process, just about whether there's a service interruption, when we deploy.

Interesting story. So when we when we released, I guess initially five years ago, there was.

And that was one of our really important, outcomes that we needed to get to to change that as part of our DevOps journey.

So nowadays, there there's no disruption at all, and we'll see how we actually achieve that, later on as well.

So when you have a bit of a plan, in place, you need to start, essentially approaching this DevOps engagement, I guess, commitment, by targeting value really nice and early on. We talk about this with short term goals. We'll see it a bit more in detail here.

When we look at getting the ball rolling, starting the process, really considering what our first options are, what we want to do.

You want to bring your biggest challenges to to the forefront, put a target on the back. And that's what we did with, with disruptions for our deployments. We knew that was something that we needed to address.

And you have to really review whether your goals that you set out for yourself, whether they address that in a time frame that you're happy with.

Once you've actually gotten that biggest challenge identified and in place, then you want to break it down into some smaller pieces.

So tackling areas which deliver the most immediate value for you, the team, the end users, the customer can be useful. So in Salesforce, it might be, you know, a new integration, pulling in data from an external system that the the sales team have been dying for for ages. Just updating some actual date profiles so people can get access to what they need. It really could be anything.

For us, it was determining in what order we wanted our services to be automatically continued after release.

You know, our data, our data deployments, our metadata deployments, our metadata comparisons, they're all separate. So after a release, we needed to decide, well, which one do we want to resume first, which is the bite sized piece that we tackle. And for us, the most important thing was the metadata deployments at the time, so that's the piece that we tackled first.

Getting these wins early on demonstrates a lot of value, internally.

It can cement executive buy in to the project, which can really help get things off the ground, especially in larger organizations.

Also, confirm to team's engagement as well. Really make sure that they're happy to to give it their role.

We really don't want to be going into this with a team that's hesitant, holding back, still wants to be, you know, working on change that's, and and not changing the way they work. So early value, and early wins is important.

When we start looking at what we actually want to address first, we'll quickly identify there's always going to be compromises in in what we're approaching.

And before we actually start that engagement, that process of doing all these things, we just need to know what those pros and cons are, very much more so the the cons at this point. We we've understood the pros. Those fall into our goals, our outcomes. This is why we're here.

Reducing our error risks, releasing fixes or updates more quickly, CI, delivering value sooner, backups, deployment success rate. These are all the things we've already addressed.

What we need to highlight, though, is there will be some cons associated with those. So there might be some teething pains in your release process. Maybe change sets aren't super efficient at the moment, but they get the release out on time.

As you start changing, maybe there'll be some teething pains and you'll have a release that goes out late.

There'll be some additional process complexity.

You know, adding new tools, new processes, that might be seen as a as a compromise.

Maybe some financial investment into more people, additional tools.

There might be some skills or knowledge that's required to actually get this off the ground.

At the end of the day, just committing more people and time might actually cost you something in terms of opportunity cost, you know, features that can't be developed right now because you're working on your DevOps process.

All of these, you know, quite clearly, in the vast, vast majority of cases will outweigh or be outweighed by the the the pros, the advantages of doing this.

But you have to be aware of them. You have to address them before you can really move forwards.

So let's say pick your battles wisely, especially when that executive buy in is still fragile. You know, choose the path of least resistance. If there are massive disadvantages, you know, you need to do two weeks of training with an entire team.

Maybe start somewhere else with somebody on the team who's more engaged, who's more interested in in pursuing this just out of interest rather than because you're pushing the change.

And make sure that you you mitigate, you know, any cons that do pop up. You might find that your immediate requirements for the value you have to deliver come with some really heavy, consequences.

So just address those with additional resources, documentation, training, enablement, all of those things.

We talked about it with aiming for level five. Don't try and implement a perfect solution from day one.

That won't give you space to change or address compromises.

I'm sorry. Or to make compromises to address the cons either, and it probably will lead to, delivery interruption or to poor poor adoption within the team.

It's an interesting old diagram. I appreciate there's very little scientific value to this, but the idea when we start kicking off a DevOps process is we want it to be evolution, not revolution.

Each of these lines really representing the engagement and the commitment from the team and the business. If we come in with strong ideas, huge changes from day one, we get this massive spike of information and then all of this hesitation, this lack of engagement, this friction within the team, and probably a slower adoption after that because we're fighting an uphill battle again.

With the evolution, this slow change over time, we're giving value in nice small increments, and we're building on that engagement.

Pretty simple. And as I said, there's very little scientific value in this, but I did quite like the illustration.

The other thing we might want to understand early on before we actually start a process is some of the additional value points that DevOps can deliver, just so we don't miss the boat on them, essentially.

A few things here that are really important, to to capitalize on, you know, as we start making changes, and it might not always be really obvious given the goals and outcomes that we've set ourselves. They can be sort of secondary benefits.

The first one is short feedback cycles. So make sure that as we're pushing these small, slices of features that we get that feedback from the customers or the end users in lots of cases, as soon as possible.

Addressing that feedback when it comes in relating to specific changes allows us to undo things early on if if the engines aren't happy or to double down and be really agile, and sort of aggressively, you know, add to those features that get the best feedback. So that's one thing to really engage with and to make sure that we get the most value from.

Scalability is going to be something as well that may well, in lots of cases, be a primary objective.

But if it isn't, it is something that you're building towards that can be very useful for the team.

It stops you hitting any kind of roadblocks as that team grows.

For almost everybody here, I'm sure Salesforce is is not getting any smaller in terms of its footprint in your organization.

And that means that your team, isn't gonna be getting any smaller either. So that scalability is really, really important, and it can save you from significant pains down the line.

The last one here is is one that is quite often overlooked actually, especially by teams who want to get to that perfect solution straight away. And this is the upskilling, of the team that's involved.

DevOps, you know, as a whole is is a is a whole set of skills, whole set of knowledge and information.

And the team that really gets to build on this, gets to pick up all information.

It's really powerful, in terms of retention within the team, but it's also a powerful lever for for business success. You know? You've got an entire team now with significantly better skills, more engagement, and you're probably going to get better delivery, and results from that as well. So not always, sort of tracked, I guess. It's unlikely to be a goal or a or a targeted outcome, but it can have big business benefits, down the line as well.

Last thing that's really important just to have in mind as well is protecting the value that you end up implementing. So backup is really important. We can go through this entire process, but if you lose it, and start, you know, have to start again, we're not gonna be in a good place.

You know, you you ensure your home, your car, all of these things. And as a business, you you want to do that with this investment, into DevOps and for the the metadata and data that comes with it.

You need to back up both metadata and data. It is really important. Losing any or all of either of those can have huge consequences, so just make sure that you're covering both of those.

And the other piece of backup, which is probably more interesting for this conversation, to be honest, is that having those backups that you trust or a store process that you believe in means you can be more aggressive with the changes that you make. You know, you know how to roll back and undo changes very quickly, very efficiently.

And with that comes the confidence then to make aggressive changes, to push at the speed that the business probably wants you to. And that's probably the most important part that comes from, you know, having backup in place.

Slow learning though, I think this was from one of the, sort of Salesforce Reddits, basically.

But just how easy it is to lose data.

Somebody tried to load up some records.

Essentially, they made a quick mistake. They tried to delete those, you know, those few records, and ended up deleting, a whole host more from the org.

The bit that made this really bad was actually that they didn't notice for about two or three weeks.

And then they really had some problems getting that data back.

So it is easy to do.

Just keep this in mind. It's probably something you want to consider early on. It's just protecting this investment you might be making.

So, we can move on to a bit of an internal case study now to see how how Gearset handles all these things really and guess this answers some of those questions that came up in a bit more detail as well. If you take a quick sip of water, and we can jump into this one.

So, yeah, we're about five years into our, DevOps journey, and, and we'll show you a little bit about the changes that have happened internally over that time. So back in twenty fifteen, the entirety of our release process was manual, essentially. And, and, yeah, we we check the logs actively to see how busy the app was. Did we have a customer or two making changes, running comparisons, deployments?

And if we did, we would actively wait, to do our release.

By them finish, it could be two, three hours if they had a big project going. Obviously, they're watching the logs until they went quiet, and then we'd very quickly try and get all of these manual processes done to release, the app before the next customer logged on. Very much manual, and a real pain having to wait, you know, between, between jobs running.

Everything in terms of pre and post deployment checks were all manual as well. So it took, you know, probably a few hours in terms of the actual manual processes, but then it could have taken a few hours on top of that just waiting for the app to be quiet as well.

I probably feel quite familiar. People have to sort of do deployments in the evenings or over the weekend, you know, when Salesforce is quieter as well.

So we targeted some confirable outcomes here, and this was really our our set of our kind of goals that we wanted to work towards. So uptime was crucial. This was a non nonnegotiable one. We had to allow our customers to keep using the tool while we were releasing updates. That's something we really had to work on, and that was our our primary goal, essentially, the first thing we addressed.

After that, we came to scalability. We knew we'd have to be able to release more often without it becoming a time sink.

Very conscious, you know, working in the DevOps space that this was something we wanted to, to prioritize.

We also wanted to get feedback to be brought in quickly as well. So, as a relatively new tool at the time, we weren't one hundred percent sure of the market, needs, market requirements. So getting that tool, feedback in very, very quickly and then iterating immediately from that was a big priority as well.

And the final thing was ease of use. We wanted, you know, rock solid automation in place, to allow the entire team to be responsible for those releases, really the the core of DevOps there, but to make this as easy as possible. So it didn't need to be senior engineers. It could be anybody that's just joined the team. They'd be able to handle a release. No problem.

So the metrics that we actually defined, as really our goals, those measurable goals, was, the number of releases we could do, number of features that we could release, and how long it took us to do, a deployment.

So if we jump forward to twenty twenty, we've done about five hundred and thirty releases, so far this year. So very regular. Indeed, just just over, two a day two a working day on average.

We've released and shipped about three thousand eight hundred, pull requests. About two hundred and fifty in there that didn't get released. We sort of aborted, and that's what agile development's all about. But, yeah, three thousand eight hundred pull requests shipped.

And that's from a team of probably about, thirty to forty developers.

And the deployment duration, the actual process is a single click, a single script that we kick off. It takes about fifteen minutes, to run-in its entirety.

It's just one click and doesn't really need monitoring, so that's quite nice.

We do have a project going on at the moment to reduce that to five minutes as our goal.

And that's what we measured so far and sort of the the improvements that we've made.

When we look at this list, you can see that for us, the goal was very clearly the speed, the velocity, the agility, and that's essentially the only thing we were tracking internally. That was our primary, outcome that we were aiming for.

We do monitor other things. How often we ship bugs, how often we need to do rollbacks, a few other things. But in reality, for us, speed is the most important.

We spoke before about other industries, financial, health care, you know, those sort of heavily regulated industries. In those industries, I suspect that your outcomes are going to be much more targeted towards reliability, review, and compliance. Those are going to be the goals of your DevOps process, and that's absolutely fine.

As long as you have that, you know, set out clearly, from the beginning, then you'll be on the right track.

There's a whole blog post that you can find, on our website, which covers in-depth our our process. So just want to, to dig into if you're interested.

The full process that we have, you know, I guess, full development process, not just a release, is more or less listed here.

Essentially five steps for the development and code review. It's a manual process. We use GitHub.

So the the the red traffic light as it were indicating that is a manual process for us.

Reviewing everything manually is, is obviously important. It's essentially our code quality stage more or less.

We have automated testing and deployments out to staging. We use continuous integration there. So that piece is automated. We've got the, the green light.

For us, testing is fine to do manually. The app isn't massive.

We can test the primary function of it relatively quickly and relatively easily.

The interesting piece here, though, is that it may make sense for you to automate that. It doesn't for us at the moment. It might do in the future, but it could for you. So consider something like Provar or Selenium, and you can get the automation here just about addressing those requirements for us. It's not huge. Currently still a manual process, and it isn't part of our goals or outcomes at the moment to change that.

We got our prechecks which happen. That is automated. That checks that everything has been manually tested, essentially.

And then the release is automated as well. Just that one script to run. It's all orchestrated by human eighties, so it's nice and quick.

The real lesson and goal, I guess, from this is that we don't automate everything. You can have manual pieces that fit into an automated process where it doesn't make sense to invest in that automation, where it just won't save you that much time.

This is a little diagram. I won't spend too much time on it just so, we stay on track time wise. But, this is actually how we manage to release the app with no, no downtime whatsoever. Essentially, we run two versions of Gearset, with a load balancer that distributes our users. We push everybody onto one instance of Gearset. We update the other as you can see here, and then we move all of our users onto the updated version.

A really nice symbol system. Unfortunately, it's basically impossible to do on the Salesforce platform.

So for for you guys, it isn't a solution you can implement.

There's just a sort of point that's interesting how GearSet operates. We're we're one of the few tools that isn't built on the Salesforce platform.

You know, other tools will be, you know, installed into your org as a managed package. We don't do that so that we can do this, so that we can deliver quickly.

I think it's a neat, neat solution, and it's been working very well for us.

So we went through all this process. All this development commitment and time, what was the actual tangible value that we got for our customers?

And that's why we, you know, do this really at the end of the day. So take a second to assess the value that we delivered. The first one is that we can roll back immediately. We use that, load balance, so we shift everybody back to the old version.

So if there is any kind of bug or problem, we can do that very quick rollback. It means there's no downtime.

Customer, requests, you know, for features or bugs can be delivered the same day, especially bugs, small bugs. You know, we can deliver fixes exceptionally quickly.

And the lead time on features is essentially, you know, half a day at most waiting for the next release. That's very important.

Mentioned before that releasing often means that your UI changes very incrementally and very steadily. You almost don't notice the changes.

They're not disruptive at all. It's like, watching a a loaf of bread prove, is my analogy. You know, it gradually grows and grows and grows, but you never notice it changing, come back an hour later and it's doubled in size. That's really how this, you know, works for us.

The other thing that's really important is that we can add support for Salesforce's API versions, on the dev release. There's no lead time for that kind of support, and it keeps us, you know, immediately relevant based on Salesforce's newest releases.

These are all, you know, genuine value points that our DevOps has provided for our customers, and they're things that you can, you know, think about and focus to deliver to your end users as well.

So, we've got now to that important part, the implementation, the game plan to sort of set this up and for you to use, sort of use, you know, DevOps process internally.

How are we going to go about it?

So education, is sort of the first great foundation.

Obviously, down that route, you know, attending webinars and so on, we've launched our, DevOps Launchpad, which is, essentially, set of courses very similar to Trailhead really, with courses specifically around DevOps. It's completely free.

Don't need to be a guest or customer or anything like that. So just jump up to the website, sign up, and you can do the courses, get the badges. As I said, very similar to Trailhead, but specifically focused around DevOps.

The other thing I'd recommend doing before you do anything live in production with consequences is to sign up for free trials of all of these tools that that give you that option. So you can create a Gearset account, a GitHub repo, get some Jira stories and tickets set up.

Provar, I believe, for test automation, offer a free trial. You can set up DevOrgs in Salesforce in a few minutes as well. So all of these moving parts, you can set up free accounts.

None of your organization's metadata or data, and you can try all of this, set up a full automated CICD workflow with some dummy data, and gather that knowledge and experience before you try anything.

Next up, I'd recommend you target those short term wins. We talked about delivering value early on before.

The first thing I would recommend, almost to everybody, is reducing that deployment time, the actual amount of time it takes you to do a release without changing your workflow at all. So if you use change sets, just drop in a tool like gear set instead of change sets and don't change anything else and just assess that improvement. It's really easy to do. It doesn't upset or disrupt anyone.

Not really that much to learn or change. It very easily gets you moving forwards and working. So we've got the compare and deploy sort of UI here. Selecting components, you get shown dependencies, clear visibility of what's changing. You hit next, and you deploy. It's very, very quick and easy.

Saves you time, and nothing else changes. I've just gone, as you can actually see here, from dev to staging.

So just like I was doing, a change set, but faster.

The next thing that's really good to do is improve internal communication. We saw that DevOps is all about relationship between development, and operations.

Things like Slack integrations, deployment reports, email alerts, Jira is a great tool to use, sort of issue tracking software. Implementing that kind of process early on will make it much, much easier to get things going and to have good results, along the way.

You see some of the notification options that we've got here with email, text, Slack, Microsoft Teams, and Chatter.

They just make it easier for those teams to work together, to collaborate, and actually build a process that works for everybody, again, with that feedback loop internally.

As we said before, give yourself that rollback option. There's going to be some changes.

Look at some workflows, all sorts of things that that could disrupt day to day. Give yourself a backup option. Make sure you're covered, and then you can get going confidently, making big changes knowing that you can undo those if you need to. Get some of those jobs set up. Make sure they're running every day, and you'll be all set. So these are changes that implement as a first step when a customer is really under pressure.

And in those scenarios, wholesale changes are impractical, and they're probably a bit irresponsible as well, especially with larger teams. You don't have to change too much.

Really, my favorite thing to do is is put in just a tool with no workflow changes at all. The reason I do this and the reason I think this works is that you end up in a, which comes first, the chicken or the egg scenario. Lots of teams, they don't know how to do better DevOps with the tooling they have. They don't know which tool they need for the DevOps they'd like to do, and you're kind of immobilized by that.

We put the tool in place first. You start to understand some of the benefits that you're going to get from it, and then it lines up.

CICD or adopting Git becomes really easy, and then you can build on those foundations.

And that's where we start to look at the long term. So we're gonna start targeting sort of be that visionary that a company needs to drive this forward.

I'd look at implementing additional tooling. It's gonna be really helpful. Source control is the biggest one. If you're not using source control yet, it's something I really recommend looking into, understanding, building the knowledge on.

It really will be the core of DevOps. It's more important than gear set, I would probably say, for the vast majority of people. So that's huge. Really consider getting that involved.

Jira mentioned before, there's loads of other issue tracking software that you can use.

Data migration, sandbox sealing, making sure that those dev environments are in sync, would be important.

Once you've got tooling and solutions in place, consider scalability. And this comes down to workflows and source control, essentially.

We've done other talks, spoke at Dreamforce about choosing the right, the right actual branching strategy for a growing team. So I think that's on YouTube somewhere. It's probably a good segue to follow on with afterwards.

But making sure you have the right workflow to address an additional ten users to pop up sorry. Ten admins or devs to pop up tomorrow.

What would you do? How would you implement that? How would you build in a parallel dev stream as well?

If you suddenly, you know, adopt, service cloud, haven't been using it yet, then, then how do you actually handle that?

And, and planning for that's important.

Also, you must be conscious if there are any major changes coming to Salesforce and your Salesforce instance on the horizon. So have you acquired anybody? Are you about to get acquired? Is there going to be an, you know, an org badge somewhere?

I said before, adopting a new cloud could really put a spanner in the works, and this is where we start to change. If we loop back to the beginning, we start to change goals, or we start to, adjust metrics when these things appear. You know, you've probably been going down one route. You've been making good progress.

All of a sudden, you're merging with another org. That becomes your priority.

Shift the outcome, change the goals, address the metrics to make sure that we can verify that we're delivering value on the business requirements, and then we can move forwards adding in step by step, the required, processes that we need.

Thinking about workflows, it can get complicated. It's something that gears that can help with, by all means. So if this is the scenario or the situation that you've got to, as I said, there is the the Dreamforce talk, which I think is on YouTube.

But, you know, we can help with this as well. We drop these plans. You know? We've got some standard workflows to work for most people, but we work with teams as well to really design the workflows that will suit their requirements.

These will change over time, obviously, but don't be afraid to draw out these diagrams, engage with us, and discuss these. We can really help put in in place something that'll that'll work for you.

That kinda takes us to the point where you should be able to jump in and sort of enjoy the perks of DevOps.

So as a quick recap, I'll start off with a vision, understanding where we're going by qualifying your starting point, targeting really specific outcomes and goals, and then reconsidering and reevaluating those goals and the value that they drive regularly.

Then we address the value. So for the business, what are some easy wins that we can get from the get go to confirm that we are indeed taking this in a route that makes sense for that business?

Address any downsides, those, considerations before you start just to make sure they don't offset the value entirely. If they do, then hold off. You know, there there's no requirement to move this forward now. If the value isn't there or the downsides are too great, just postpone.

Embrace hidden benefits. Things like upskilling the team, really important. Make sure those are included in your sort of value considerations and propositions, and then protect your investment as well with those backups.

And then for the implementation itself, get learning, start testing, you know, test things out in those trial environments, target the short term initially, talk about just drop in changes, individual changes, let them settle, see what avenues open up, and then slowly add more functionality.

Of course, as we're doing that, we're building towards a bigger picture. Start working out, workflows that are going to work for you, branching strategies and source control, any other additional changes or considerations that you need to make or put in place, as you move forwards.

All of this, of course, under that sort of scope of, you know, the agile methodology just to make sure that at any point in time, if the feedback changes or the outcomes change or the situations change, that all of this, we start again and we'll go back to the vision, and we work through it essentially.

So, yeah, thank you very much for your time. If there's any questions, let's see if we'll stay on to take those.

Before you go, at the end of the day, and connect with me and Kevin on LinkedIn. If you've got any questions at all, we're more than happy to discuss.

Email over any questions, your specific scenarios, you know, that you're in. You know, send those over, and we can really dive into a discussion and create a free free trial on GIS as well, to try it out, have a look, see if there's any part of that DevOps process that we can, help for you.

There was one more question in the chat which came up at the beginning, a bit of a longer one. So I'll just take a moment to read that, make sure I address it, before we run out of time today as well. If there's any more, file them into the chat, and I'll pick those up as we go through it as well.

So a question from from Kurt at the beginning, and, you know, feel free to add in context. But I think the question here is I'm working with, other teams, other consultants.

It's not possible to have a gear set license that bounces between, between different clients.

And, therefore, it can be tricky essentially to manage those different organizations.

This is a situation that we're sort of well aware of, and we actually have a feature which we use internally, which allows you to move your team your user across all of those teams. And we use that for support and managing, sales teams, you know, demo teams.

That will probably get released at some point, and that'll make this a lot easier for you.

At the moment, the the vast majority of our partners who who work with lots of different, organizations will create additional accounts, for sort of short term trials essentially to work with those partners.

If they are running long term projects on multiple teams, you know, talk to us. We'll see what we can do for you. You know, we may be able to duplicate a license or something for you just so you can, you know, work more easily across those those teams.

Hopefully, that answered your question. As I said, I think, to be honest, there's some new functionality coming out, to move to move teams, which would be the most useful for you there. So keep an eye out in the change log, and that should help.

Yeah. I'll, I'll stay on for a few more minutes, just to pick up any any last questions.

But, again, I really appreciate everybody's time. And, yeah, have a good, have a good day, afternoon, morning, wherever you are.