Version control: Building the foundations of a successful DevOps process

Share with

Description

What are the foundations of a successful DevOps process? Jason Mann, VP of Customer Success at Gearset, has many years of experience empowering customers to harness the full potential of Salesforce DevOps. He’ll give you his key insights into the benefits of Git-based version control and show you how a source-driven process unlocks a whole new world of DevOps goodness for Salesforce teams.

Learn more:

Related videos:

Transcript

Alright. So hello, everyone. Welcome to our session today on version control, building the foundations of a successful DevOps process.

So let's start with, a bit of introduction myself before we get into it. So I'm Jason and VP of customer success here at Gear Sets. I've spent the last six years deeply immersed in the Salesforce ecosystem, helping companies around the world adopt modern development practices, when particular, unlocking the power of Salesforce DevOps.

And in this session, we're gonna be taking a look at one of the key tools that forms the foundation of any DevOps process, version control. We'll do a brief dive into what version control is and its key benefits. We'll look at why version control is so important when building a scalable DevOps process, and we'll explore how to tackle the most common hurdles to successfully adopting it, including stepping through a branching strategy.

And I wanna start first by defining what I actually mean by DevOps.

And Salesforce removes a lot of the complexity you might find in DevOps in other platforms from managing infrastructure, scalability, hosting, even tests. Traditionally, they're the responsibility of ops personnel and their chosen tools, but this is all handled by the platform itself.

As a result, the remit of DevOps in Salesforce is a little more tightly defined, and it boils down to any part of that develop release cycle which is manual but could be automated. And this whole process is usually run by the developers and admins maintaining Salesforce rather than a dedicated DevOps team. And that focus on automation is important because we're gonna come back to that a little bit later.

And DevOps is a relatively new concept in the world of Salesforce. Traditionally, you had release management, which was focused on getting each deployment out of the door, but lacked that vision of automation, repeatability, and ownership that DevOps really encompasses. And many teams didn't include version control in their workflow.

Version control itself is not a new concept, and many of you, I'm sure, will have heard of it before and likely used it too. This has been one of the core tools underpinning software development in other platforms for some time now. But until recently, Salesforce teams were behind the curve when it came to adopting version control.

And that's primarily because the platform's unique clicks not code approach to all configuration and the ease and power of making changes without the need for complex dev tooling. And by democratizing Salesforce development in this way, enabled Salesforce enabled the millions of developers and admins to see faster ROI from their investments. But as a side effect, many of the tools and processes used by developers more generally haven't always been adopted quickly for Salesforce, and the ecosystem has often taken its own approach to development practices.

Now over the past few years, as the Salesforce platform has continued to mature and offer more complex functionality, it's it's become apparent that version control is an increasingly key tool for every Salesforce team. And we've seen the transition to source driven workflows become way more common. From our state of Salesforce DevOps twenty twenty one reports that surveyed more than five hundred Salesforce professionals, we we know that an increasing number of Salesforce teams have already incorporated version control into their process in some fashion now.

Before we explore why version control is so crucial to Salesforce DevOps, let's just run through a quick reminder of what it actually is.

Now, fundamentally, version control just provides a structure for tracking changes to files over time. Those files could be text documents. They could be source code. They could be videos, or they could be your Salesforce metadata. It doesn't really matter.

But what it gives you is a complete history of any change to any file at any time by anyone and a much greater level of insight than you'd get with Salesforce natively.

There are many flavors of version control out there, but the de facto standard for Salesforce is Git. And Git provides teams with the ability to separate out multiple streams of development and avoid stepping on each other's toes by making changes in isolated branches instead of in shared sandboxes.

Git also provides a shared source of truth for all code changes. Each repository tends to have a main or master branch, which holds the current production ready versions of all files.

By having everyone work from this single starting point and tracking all changes across the code base, it's easy for teams to have a shared understanding of what's approved and reduce the chances of code duplication.

And finally, Git provides a structured way to review and integrate changes back together before release and deal with any conflicts that might arise.

Now all of these features individually aren't huge, but together, they provide a big step up over the native change management process and a stronger way to control each team member's changes as they make their way through to production.

And let's visualize this so we can recap a little bit of that terminology before we dive into it in more detail. So in version control, you have all of your project files, which in this case is your Salesforce metadata, your profiles, your Apex, your custom objects, whatever it may be. They live inside the repository or repo, which tracks their change history.

Although, technically, everybody on the team will have a copy of this repository on their machines, there's normally a centrally hosted version of it too. And this acts as the source of truth in the repository, usually in some kind of Git hosting platform like GitHub, GitLab, Bitbucket, or Azure DevOps.

When you decide to then make changes to your metadata or begin working on a new feature, you create a separate branch, often called a feature branch, off of that main or master branch. And And this feature branch will include a copy of all of the files present in the original branch so you can make modifications to them independently from the work others are doing.

At various logical steps in your work, it's then good practice to commit the changes back into your branch, saving a snapshot of your work in the repository.

Each branch then becomes groups of related changes that together will form the final feature you're working on. And when your work is finally done, you create a pull request to merge your front future branch back into the main branch. A pull request is just a mechanism for code review and approval as well as automating the process of combining files before those changes can then be released to downstream orgs and finally out into production.

So then taking this a step further, we have here a basic feature branch model, which is one of the many branching strategies that you can use when working with version control.

In this model, as on the previous slides, a team member takes their changes within a feature branch that corresponds to a Salesforce development org, such as a dev sandbox.

After committing their work, they then create a pull request to merge their change back into master, ready for testing and release to production.

And here's where Git becomes so crucial for DevOps. Because as I mentioned before, DevOps for Salesforce focuses on deployment automation, and Salesforce orgs are moving targets. They have live configuration changes. You have platform updates. You have managed packages and end users tweaking settings all over the place. And while these are all really powerful features, it does cause problems when you want reliable regular deployments.

Now Git, by comparison, is static by nature. Branches provide ways to isolate new features, and changes can be approved and gated so they're released in a controlled way. It's a big shift from native in org practices.

And the other thing you need for automation is a way to actually automate things, and there's no native deployment automation, here within Salesforce itself.

Git provides a really handy framework that many other tools, such as GearSet, Jenkins, TeamCity, could hook into to provide that automation that you need. You can even set it up so that as soon as you commit a change or open a pull request, your CI tool will begin validating those changes and testing them against your downstream orgs so they're ready to go in no time.

And what this means in practice is that teams using Git have greater control over their changes.

That control allows them to move down the path of automated deployments, providing a repeatable and faster way to shift changes between their orgs.

Faster deployments then allows for more frequent deployments, which in turn encourages teams to ship fewer changes at once. And the smaller number of changes in any release, the easier it is to test and the lower the risk of actually releasing it. And if things do go wrong, it's much easier to revert a small number of changes than a month's worth of configuration.

By adopting this rapid cadence, teams naturally move into the habit of quick iterations and regular feedback, and these tighter loop loops result in better quality releases with features that are more relevant to your end users, which is what it's all about.

And then through branching, you can scale this process to teams of any size and with any number of development, testing, and preproduction environments. And this is a really tried and tested approach. Almost every big tech company out there, from Amazon to Microsoft to Google, they're using version control at the heart of their development practices and it's been proven to work at massive scale.

So, hopefully, you can start to see how all of this can rapidly build to a whole lot of improvements in a deployment pipeline compared to using traditional in org development.

So with all those benefits, it's clear why so many teams are starting to adopt version control. But with any change comes challenge, and the flexibility that makes version control so powerful is also the source of complexity that can make it difficult to adopt.

At GearSet, we've spoken to thousands of teams, and we see two recurring themes to their challenges when going down this route, which I really want to address.

Firstly, there's a people challenge. Getting teams on board and working effectively with version control is a change management process in itself.

And secondly, teams often struggle to find the right Git branching strategy.

So for any change to be effective, the new way needs to have some demonstrable benefits. Otherwise, people will just go back to the familiar approach that they know. And for teams who have been solely working with Salesforce, Git can be a big change. It's a whole new tool with its own terminology and process, and it forces you to get closer to the underlying XML that defines your orgs than many people have typically done before, and that can be a bit scary.

As a result, team members not familiar with Git might struggle with that learning curve at the start. But getting to grips version control doesn't mean you have to be familiar with the command line interface, and you don't need to spend time learning tricky Git commands.

Most actions, and most Git providers offer UI based tools for performing the most common things you need to do. And using something like Gearset, for example, you can deploy your changes to and from your version control system in the same way that you deploy changes between Salesforce orgs. Reducing this barrier to entry is a really key part of getting buy in for the team.

Now switching wholesale to a completely new workflow at once might be pretty difficult, so running a pilot or building a center of excellence to champion the new way of working can be a great way to help tackle some of this challenge.

It's also really important to keep things as simple as you can. It can be really tempting when you're getting started to try and replicate your current release flow in great detail or try and think about every possible edge case that you might want to cover. But if you're not careful, this can lead you down a path of creating an incredibly complex process that's really difficult for people to get their heads around.

So whatever workflow you decide, it's important to make sure that your team starts seeing benefits from the get go to build confidence that it's worth the disruption to change the existing process and move on to the new way.

Now the second challenge I spoke about there was picking a branching strategy, and that's really, really fundamentally a key part of how you work with Git. The wrong strategy can really hamper your adoption, so it's really important to give this some consideration.

Now branching strategies range a lot in complexity.

The more complex your strategy, the more likely it can closely represent your workflow before version control, but more complex models will take longer for newer and less technical members of the team to get their heads around, and they often have a higher maintenance burden. And at the worst end of the scale, they can actually even slow down your whole release cycle as people get mired in process.

So in general, less complexity is usually better.

The size of your team can also determine which strategy is best for you. Larger teams, for example, are more likely to have a larger variety of roles who need to rank interact with the workflow at the various stages. They might also have many environments to manage with different use cases for each, which in turn may require a little more complexity in the branching strategy to match it. Conversely, smaller teams can often benefit from picking the simplest approach and just getting going, adapting it in the future as they need.

As already mentioned, one of the most important benefits of using version control is that you can increase your release cadence. But often, there can be business reasons that dictate a particular release cycle. For example, you might have regulatory sign off or limited maintenance windows so you don't impact your end users. And if this is the case, you may need to alter your branching strategy to accommodate these stages of approval required.

Switching to version control is also an opportunity to reshape your current way of working. I've already mentioned that getting buying from your team is crucial, but how your environments are currently set up might also impact your chance of your choice of branching strategy.

For example, you might have a whole set of testing and development environments that need to be included in your new workflow or a long running side project that needs to be kept up to date. You may even take this opportunity to switch things up and try something completely new.

And finally, not everyone needs or wants the same goal. What works well for a three person team may not work for three hundred, So you need to have a really good understanding of what challenges you're trying to solve as a business, why you're actually looking to implement this, and what good looks like for you when you're picking your strategy. So So at Kia set, we help teams adopt best practices when getting started with version control and with all the considerations there I just mentioned. One of the most common questions we face is how do we decide on the best workflow for us? And while I do wanna stress that there is no one size fits all approach, I did wanna share a model that we found appeals to a lot of Salesforce teams.

So let's run through it.

It's broadly similar to the feature branch model we looked at earlier, but it's slightly more complex to include a number of different testing and staging environments, in this case, our QA and staging sandboxes, with each org having a long loop branching git mapped to it. So let's assume that our team is gonna work in sprints, and let's step through this process step by step.

To kick things off, a release branch is created at the start of the sprint based off the master or main branch.

Feature branches are then created by each person in turn as they begin working on each part of the user story.

Changes are then built in individual dev sandboxes and periodically committed back to the feature branch.

And when that feature is ready for QA, a pull request is opened to merge the feature branch into the QA integration branch.

Now after merging any change into QA integration, that branch is then deployed wholesale to the QA sandbox, where it can be tested and signed off by the QA team, which is a process that often involves the original developer as well.

Once this is complete, a PR is opened to merge the feature branch onto the stage integration branch.

And, again, after merging any change to stage integration, that branch is then deployed to the staging sandbox that it's mapped to, where it can be tested and signed off for final release to production, potentially with some UAT there, interim users for good measure.

And once that change is then approved at stage, the feature branch is merged into the release branch.

This process then repeats for every change being made during the sprint with each approved feature collecting in that release branch over the course of the sprint.

At the end of the sprint, all the changes in the release branch are then deployed to production and set live for your end users.

And once you've verified your new work on production and things are working as expected, the release branch is merged back into master or main, so the master is once up is once again up to date with everything in production.

You then wanna go through a final process of tidy up to merge your main branch back into your integration punches if any road changes have not followed this process to avoid drift between your branches developing over time.

The sprint then ends, and you begin the cycle all over again.

So an initial question might be, why do we actually recommend this model? There's a few reasons, really. The first one is it provides fine grain control over which changes get through to each environment with quality gates and approvals at each stage.

It also allows for easy separation of changes at their various stages of development. You avoid commingling untested changes with those ready for release, for example, which can be a limitation of the feature branch model, which means that if you spot a bug or have to roll back one change, it can be done quickly and easily.

Similarly, if a hotfix needs to be pushed through the pipeline faster than other changes, this can be done fairly straightforwardly by manually merging that hotfix's branch into the success of environment branches in turn.

It's also just a fairly natural flow for people to get their heads around with branches being mapped to orgs, which really helps with some other option and change management.

And finally, it just scales well, and it's a really good mix of complexity and speed. With this model, it's really easy to support a sprint based approach, or you can even slow it down for a more controlled release cycle, and we've seen this model used by global teams to great effect.

Now although it is a really good model, there are, of course, many, many other models beyond this, and we don't, of course, just blindly recommend this approach to every single team who comes to us. We try and keep things as simple as possible wherever we can. For many smaller teams, the feature branch model works really well, and that's actually what we use internally at tier set two. But we found that lots of teams really want to be able to push changes completely independently through that release pipeline, usually just things like stringent testing requirements at each stage. And for larger teams, this model can be a really good starting point. If you need even more control, then the next step is often to move to something like Gitflow.

That adds an additional layer of complexity and control, but it gives you some benefits as well. And if you'd like to talk about any more of these, then feel free to reach out to myself or any of the guests at team afterwards, and we can bore you with all the details of every different Git branching model and why it might be suitable for you or not.

Now one thing I do wanna highlight at this point is a really common pitfall that many teams need to Git fall into, and that is bad branch management.

When you're getting started, it's really tempting to let feature branches tend to live for a long time or scope them with perhaps whole user stories worth of work or maybe even several user stories or just not delete them when you're done with them, and none of these are good.

You should always aim to keep your branches as short and as well contained as possible. Limit them to the absolute minimum amount of work that you can ship that produces some value to your end users. Get it built, get it tested, get it shipped, and then close the branch and delete it. This not only encourages you to embrace that ship small, ship fast mentality of DevOps, it also helps you avoid a few maintenance headaches down the line.

Some of which being that the longer a branch stays around and the more changes changes it collects, the greater the chances that you're gonna run into merge conflicts or find that the world has changed underneath your feet when you've been working in isolation.

Over time, stale branches can also build up in a repository if you don't delete them, and that can make it really hard to find the things you need and could lead to confusion over which changes should be worked on.

So wherever you can, just keep branches as short lived and as tightly defined as you can. So for example, at Gear Sets, we chunk peep slices of work into features that should last no more than about a week. This practice is one of the reasons why we can ship multiple updates to Gearset a day.

Now simply deciding to adopt it and picking a branching strategy is not the whole journey. Embedding a new way of working can be a challenge, so let's take a quick look at how you can use Gearset to make it easier for your whole team to actually get on board with version control.

And I'm gonna do this by jumping back into this workflow and talk through a few places where Gearset can help.

Firstly, Gearset integrates seamlessly into any Git system, allowing you to create branches in a few clicks, commit changes, open pull requests right from within Gearset's intuitive UI without the need for complex Git commands or to go to the CLI.

Any place where you're moving metadata between Salesforce and Git, you're gonna need a tool, and Gearset's gonna be there to power it for you. And that immediately removes a layer of complexity when working with Git. That means less new tooling for your team to learn.

Secondly, Gear Set can automatically validate changes when a pull request is opened and feed the results right back into your version control system.

This allows you to catch broken code and bugs really early when they're easy to fix and before they actually get released into your live orgs, potentially saving loads of testing time and avoiding breaking other people's work. It's also, of course, much easier to back out a broken feature that you haven't shipped than to disentangle it from a live org.

Thirdly, upon merging a change into a branch, GearSec can then automatically deploy those changes out to a Salesforce org through continuous integration jobs. And this is where the speed of automation really starts to kick in. Your changes can be in your QA or your staging sandbox within minutes approving a PR without any complex automation scripts to maintain.

Similarly, Gifs that supports continuously validating changes from the release branch against your production environment, tracking errors and code coverage issues, and building a quick deploy package so the final promotion production is always fast and successful.

You can even run some PMD powered static code analysis to check the quality of your code throughout this whole process.

And finally, using Gearset's automated metadata monitoring, you can continually check production for in org changes that may have sidestepped this process. In reality, no one ever follows a process to the line.

So whether it be a quick fix in the org or something deployed through a chainset, you can get notified when things change. You can view those differences really easily side by side, and then you can track them back down into Git with just a couple of clicks. And if you wanna go even further, GearSoft can even perform full org data backup as well so you have complete control of your Salesforce metadata and your data too.

Now these are just a few of the ways that GearSoft can help, help you adopt your Salesforce DevOps process.

But don't just take my word for it. As you might expect, I am a little biased. So I wanted to talk you through two examples of companies seeing great success with version control and DevOps through GearSet.

The team at Intercom, the conversational relationship platform, they wanted a DevOps process that didn't just cater to developers over their admins. They were looking for something really user friendly that would empower everyone on their team, and Gearset's seamless GitHub integration here was a real deal maker for them. After getting set up in almost no time, they now have a highly efficient automated process that lets them focus on continually building and shipping new features.

The team at McKesson, the global pharmaceutical and health care company, has built a modern DevOps process work for you using GearSet. They now use our continuous integration capabilities to push configuration changes to production every four hours throughout the week, drastically increasing their release cadence.

And these are just two examples. If you want to see many more of these customer stories, just head to gearset dot com slash customers.

So in summary, we've talked about a few things today, about what Git is, the key benefits it provides, the single source of truth, parallel development, the audit trail, and a stable point of automation.

We've looked at how Git unlocks DevOps and why that's some big benefits. We looked at some of the most common hurdles to adopting Git and how to work around them, and how you can use gear sets and our recommended branching strategy to really hit the ground running.

Now each of these topics, in particular talking about different branching strategies, could be a thirty minute talk in itself. So we've only really scratched the surface in this session, but I hope it's given those of you who are interested in learning about version control a bit of guidance as to why and how to get started.

So with that, I'll say thank you very much for coming along. Hope you enjoy the rest of the summit. There are some really great sessions coming up, and I believe it's time to head to a few minutes of q and a.

Sure is. Thank you very much, Jason.

I think as Kevin said before in the in the keynote, you know, version control is a core part of your DevOps journey. So thanks very much, Jason, for for covering that. I have some questions for you. So, if you're ready, I'll give you the first one.

Let's do it.

Cool. So, what is the best way to efficiently push changes to the important shared files, such as record types, page layouts, workflows, translations, and permissions without pushing in progress work. We found with a linear strategy, one of the ones you displayed, is likely to have build failures in upwards environments when pushing one person's ready work and one person's in progress work?

So I guess a little bit. It depends on how much segregation you've got between those different branches in your different environments and also how granular you can actually get with the changes that you're tracking there. So one of the things that we try and do at Gear Set is break up some of the larger files, like, for example, profiles into the smaller components so they're much easier to pull apart and produce the chance of you stepping on each other's toes. Now there are some bits which are harder to work with and pull out in that way, But, generally, the more you can break it up and the more you can segregate things and the faster you can get those branches, mergers, and ships, the more likely you are to be able to avoid some of those build failures.

But I'm not gonna lie. It's not perfect. And in many ways, the way Salesforce metadata was designed wasn't really originally thought about in terms of working with source control. And some of the changes that Salesforce have made over the last few years with things like SFDX, breaking down some of those components into smaller chunks is such is aimed at addressing some of those problems.

But it is a little bit of a trial and error process. You have to iterate on what works for you. So start with a small number of components. Start to layer them in as you get more, used to that process, and then maybe look at different, branching strategies to add some more gating or some more separation between some of those areas. It's obviously a little bit difficult to go into the exact specifics, without kind of diving into the metadata, but it may be something that you drop me an email afterwards or chat to one of the team, and we can run through and see if we can figure out some ways of actually chunking those things up in a bit more detail and and getting you back from those build success rather than build failure.

Great. Thank you, Jason. I really like this question for new people's DevOps. Is it necessary to analyze the shape of your org before moving to to a DevOps culture? If so, could you please mention some points to take into account before making the move?

It's always a good idea to have a bit of an understanding as to your state of play before you get going. You know, do you have a a vast production org that's been around for fifteen years now that has hundreds of managed packages and a massive amount of data, or are you relatively new in your sales with implementation?

Obviously, the more complexity you've got, the more difficult it's gonna be to get everything into source control. It might take a little bit longer to get going, but you don't really need to have that stop you from getting started.

What we've seen with a lot of teams, especially when they're brand new to version control, is they sometimes make the mistake of trying to put everything in Git from day one, and then you can end up sort of hamstringing yourself by making things too complex too fast. So a good way, almost regardless of how complex your org is, is to start with something like a single component type. You know? Put your Apex into Git.

See if you can get that working. Get used to the branching model, the new ways of, of interacting with source control, and then start to layer more and more components on top of that. And there are some things that you don't necessarily have to put in. So for example, managed packages is a common one that people say, do I need to put them in Git or not?

And I guess the answer sometimes depends, but it depends on how much you're actually configuring those packages.

If they're relatively stable, leave them out. Leave that complexity to your Salesforce orgs and focus on the things that you're modifying more frequently, like your custom objects, your profiles, your visual force, your Apex. And don't worry too much about having a complex org that stops you from getting going with this.

Great. Thank you very much. So third question, how do you keep your dev environments that are being used to build features up to date on a large team? A simple policy that you must refresh before each build becomes unscalable when sandboxes can take one to two hours to refresh, and they will get queued on a large team.

So the general one of the ways you can do it is by having those constant releases which push really quickly. So as soon as you've merged a feature and it's gone into, let's say, the release branch or your your release candidate, whatever it may be, run a deployment through something like where you can just push the delta into that org, and you'll find actually the deployment time is usually not that fast, but not that slow even. You can often get changes pushed in a couple of minutes. Obviously, it depends on whether you've got hundreds of tests that you need to run-in sandboxes.

But, generally, the shared sandboxes shouldn't be changing back frequently compared to the individual dev orgs. For those, what we tend to say is as you start beginning of that sprint, you can run a quick refresh. So you can use something like Pearson to just deploy those changes out. And it does get sometimes a little bit complex if you have dozens and dozens of these orgs.

But one of the things that we can do is just deploy the delta between what's changed in your git branch and what's changed in your org. So you're actually pushing a relatively small number of components.

The other way is that you can have scheduled jobs that just run on a pretty regular cadence. So have something overnight that just pushes to all of your dev orgs from your main branch or your release branch, whatever it is you're going through for approvals, and just have that in the background syncing them up so you're actually reducing the the the build up of the features that are waiting to go out.

Great. Thank you. And how is migration to version control work with a dev team of two?

Quite easily and quite nicely. It's the odds that we have, like, quite a few companies actually who are working with with even teams of one, and they're still moving to adopt Git because you don't have to be a large team to get a lot of the benefits from this. You know, if you're if you're thinking about, well, I need to have some visibility into who's changing things and why, then there's Salesforce audit trail, but it only goes so far. And even if it's just you having that version control process in place can be really, really valuable.

Now the nice thing if you've got a team of two and depending on how many orgs you've got is you're not gonna have too much problem with people stepping on each other's toes, and it should be really easy for you to start with something like that feature batch model. You can put it in in, you know, hours, get up and running with something like to deploy some of those changes. And then if you need to add more complexity over time, then you can just layer in sort of different stages to that branching model as you go. But I'd say you're in a great position.

Don't don't let you think that two people is too few for Git, and don't let it think that if you're two admins that Git is not for you. Because, really, if you wanna start to build on all of this stuff that Salesforce is releasing in the platform these days, you need to be working with version control in some shape or form. When you look at all the new platform updates, you look at Salesforce DX, all of that is predicated on teams using Git in some shape or form. So the the sooner, the better.

And the fact that you've got two of you means you can just sit in a room together. You can, hopefully, fairly quickly argue out what your branching strategy is gonna be, and you can just get going and iterate on it.

Fantastic. Good news. And one more question before we get to next session. What would the ideal branching branching strategy be to achieve complete CICD, I. E. Deploy changes as soon as they're ready to be deployed to production?

It's one of those questions where it depends a little bit on your structure of your orgs and your team, and there is there's no definite best branching strategy that will always work for you. I I guess I can say that what we do internally at Gearset is the feature branch model. So we have a dev team of about, what, thirty, thirty five people at this point, and we ship updates to the app about three times a day. And we do that through a really simple feature branch model, and we have complete automation built into that.

So as soon as something is merged in, it goes out to staging and testing and then out into production through some automated builds. And you could do the same thing with Salesforce as well. Now, obviously, you may not be able to do a feature branch if you need some more gating and testing between that process. But even if you add more stages, you can still have automation at each of those bits.

So as soon as you merge a change into your integration branch or your staging branch, you can still have a job that will automatically push that out to different orgs in turn.

Now you're never gonna have a completely automated flow when you've got multiple orgs. You're never really gonna want to have a change go straight from a dev sandbox all the way through to production without some manual gates and at least someone's eyes on it. But you can do all that through the pull requests, processing git, and you can have that as your gating point. Once you approve the PR, you merge it, and you can have an automated tool like Giaset then just handle the build and push it out for you from there.

So I think I'd probably say that you can get pretty close. You can if you want to have a totally automated pipeline. At the moment, it's it's merged. It's gone straight out to production, but it's usually a good idea to have at least some form of check to make sure that you're doing something sensible and some eyes on it before it goes live to your end users.

Fantastic. And that is all our questions. Jason, thank you very much.