Description
When orgs drift out of sync, conflicts pile up and releases are disrupted. Syncing dev sandboxes safely — without overwriting active work — is a big challenge for many Salesforce teams.
This short on-demand webinar outlines the causes and impact of environment drift, what you can do to stay ahead of it, and how Gearset makes it easy to sync sandboxes in just a few clicks — without risking in-progress work.
Transcript
I'm very excited to introduce you to today's speakers, Matt Jackson, product manager at Gear Set, and Richard Owen, senior product manager at Gearset. So if everyone's ready to get started, Richard, I'll hand over to you first.
Thanks very much, Amy. And, thanks very much, everybody, for coming along to the webinar today.
So some quick introductions first. I'm Richard. I've been at Gearset for three years, and I lead our product management group focused on helping larger teams work well together. As part of this, I've been PM for GitHub pipelines since it started, helping over four hundred teams of all shapes and sizes establish and maintain their CICD process. And keeping environments aligned is such a such a key part of this. So I'm really, really excited to talk with you about this today. And I'm delighted to be joined today by Matt.
Hey, folks. Nice to see you all. I'm Matt. I've been at Gearset for around five years now. I spent most of that time on the ground with customers, so, might have met a few of you folks few Gear Set customers today, working on enterprise, DevOps implementations, and proof of concepts. And I've been lucky to work with hundreds of customers getting up and running with Gearset.
I moved over to the product team to work with Richard about a year and a half ago, spending all of our time focused on functionality that helps large diverse teams work better together. Nice to see you, folks.
Cool. So here's what we're gonna be talking about today. First, I'll go through what also we need to keep in sync, why we care about doing this, and when it makes sense to carry out these operations. And then I'll hand over to Matt to go into the how to describe what people have done in the past, the approaches that teams have taken, and the pros and cons.
And then we're gonna go into what we think teams should be doing to find success here as well as introducing our own solution to this problem. But as we go along, drop any questions you got in the q and a. We'll probably get to as many of them as possible at the end of the session. So with that, let's get started.
So first, let's talk about the key question. What environments do we care about keeping aligned when it comes to syncing metadata? Well, realistic realistically, it should be all of them. So let's take a look at what teams generally have. Of course, this varies from team to team, and I've seen many different shapes of pipeline, but this is a decent reflection of it for many folks.
Of course, there's a production environment at the core. In addition to that, pretty much all teams have main pipeline environments through integration or QA, UAT, and staging, and these also need to be kept aligned.
Many teams also have longer term project work, and they want to ensure that all changes going to their main pipeline stream are being pushed back into those projects. And this helps minimize the difference between the projects as and business as usual work so that it's easier to release towards production when it's time to do so. But really importantly, you also wanna make sure that your working environments, your dev sandbox is whether they're individually owned or shared, are kept up to date.
Now keeping all your environments well aligned with what you choose your source truth to be helps ensure that if you're doing that that you're doing relevant testing at each stage of the process and that you're building on that source of truth as a base. Because if you're creating feature branches from main or master and your dev box is already aligned with it, then it's so much easier to find your new changes and set them off into your first environment.
Now let's get to the other side of the question. What should that source of truth be? What does Teams need to stay in sync with?
Well, if you're deploying org to org, then the answer is usually production. After all, when you spin up a new box or refresh it, you're doing that from your production environment, so it's the cleanest state to start developing from.
But for teams working with version control, the answer is often a little bit more nuanced than that, and it depends on the branching strategy that you use. For teams working with the main branch strategy that we and most of the tools in the market support as their primary model, this is usually production or your master branch. But if the team is working using more of a Gitflow type approach, then the target environment stay in sync with this dev or your first environment where everything comes together. Because changes will, or at least they should, align naturally further down the pipeline as they get pushed through each stage of the process.
But, of course, that branch won't be your source of truth for absolutely everything because Salesforce message structure means that some message types are just not suitable for keeping under version control or aren't retrievable through the message data API. And others like dashboards or reports tend to be more environment specific because you don't want your testing dashboard to be pushed straight into production.
But other than that, your chosen branch, whether it's main or a lower environment, should be a good source of truth for what you're working from.
Next, why do we care about this? What happens if you don't keep these environments up to date and in sync? And in short, trouble.
That's one of the key causes of problems in the release process, especially on those environments in the virtual production is environment drift. If there are lots of changes in your main branch or your production environment which aren't in your lower environments, like UAT or integration, new features you're working will often hit conflicts or validation errors when you try to merge them in. As you might be merging changes which are either inconsistent or there may be missing dependencies.
So to be able to deal with this, we always recommend merging back from master into your lower environments frequently, which will make the whole process cleaner and ensure that and it'll ensure that those environments are well aligned. And some of the cases where I've seen teams get into a lot of trouble is if they let those environments drift further and further out of alignment because this causes more friction as they go through subsequent releases.
But when it comes to individual or shared their hand boxes, a lot of these same problems occur. You wanna keep them up to date with your source of truth as far as possible. Yes. You may need to occasionally add some changes you need to build on top of before they get to production, but for the most part, being up to date with production is the key. Because if you don't do that, there's a risk of pushing changes in the feature branches which are out of date or accidentally reverting changes which have already gone through the process.
But one of the main pain points with this process is that for your dev sandboxes because they're they're the environments that you're working in. Right? So you're adding new changes to them all the time. So those environments can be continually shifting under your feet. It it can be really easy to overwrite changes and lose work, and this itself can cause seem to be too cautious or afraid of updating those environments or allow them to fall way, way behind where they should be.
Now when you're using version control, this situation is made more complex by the fact that you've got a branch under each major environment that you're using.
So if all changes are being pushed to the pipeline's process, this should stay pretty well aligned, but any changes made outside of that process. So anytime somebody makes a field change directly in prod because it was easiest to do it that way, that that starts to create drift here as well. That makes that branch a less good source of truth for you. And when it comes to dev sandboxes, if you need to have a long running branch underneath that sandbox, it makes it more complicated still. After all, you can't avoid making changes to the sandbox outside of us pipeline's branchable push because it's where you're working in the first place. So having a branch having a long running branch here leads to an inevitable tug of war between the branch and the org loads and loads of misalignments whenever work's going on. So keeping those in sync can be absolutely exhausting.
And for too many teams, it looks like this. Oh, everybody's seen this meme. Right? Environment's way out of sync. More and more changes piling up. If you ignore those changes, you hope nothing comes back and bites you. And, And, realistically, you're only gonna be able to get away with this for so long before it all comes crashing down around you.
So this brings us to the low when. What point should you make sure that your environments are in sync? Well, the ideal answer is that they should always be in sync, but that's not always or or even usually practical. The best practice, as we said earlier, is to make sure that you align changes remain to all your parallel environments after every release of production, and this ensures that those lower environments for your first integration environments all the way through to UAT or pre prod, they always have the commits and features which have gone into main plus anything new that's being worked on at the time. So this is a relatively easy bit. But when it comes to dev sandboxes, it's a different matter because it's an active working environment.
Some teams enforce updating the sandboxes after each sprint or even after each feature is released, and this can be incredibly time consuming, especially when it's enforced in the sandbox refresh because you might be looking at hours before you can start working in.
On top of this, when a refresh happens or even when back propagating work into a branch under your sandbox, there's a risk that you'll lose the things that you're currently working on, and that wastes a lot of time.
So there's a strong case to wait for a good time to do this process. Ideally, when there's no work in progress and that you're guaranteed not to lose the things you're working on. But just think about that a minute.
When is it really a good time to do this? Because most developers or admins have elements of multiple stories or features going on at once, so it's hard to find that perfect time. And if you're at a team which has shared sandboxes, this problem is exponentially worse. Because can you find a time when all the users in your sandbox are finished and have pushed their work at the same time? Probably not. Right?
So this problem, the work in progress problem, leads to the users and teams building up hundreds of changes waiting to be pushed back into the sandbox.
And as our volume goes up, the fear factor also increases. How can I get my sandbox back up to date and work through the amount of changes? Which order do they need to go in? Because that matters. Right? So we need a new way of thinking about this.
And to take us through how teams handle this today, the pros and cons of the approaches, and how we can do this better and easier, here's Matt.
Thanks, Richard.
So let's take a look at the approaches we see being used to solve this problem and then some of the options you have to maybe bring this into your team as well.
So if you're doing absolutely nothing before, then the first place to start, would be doing some manual deployments of changes that reach a certain org or branch back to our developer sandboxes or the particular sandboxes we need to keep in sync. You can do this using tools like chainsets, DevOps center, SFDX CLI, or any other method that allows you to specify items to deploy between a source and target.
In this case, the source you would use would be your choice, but I'd recommend focusing on whatever seems to be your most stable state of production ready configuration and code. So in an org to org scenario, this is usually production. And if you're using version control, this is usually main or master. But as we said, it could be an earlier branch depending on your particular branching strategy.
Now this is a great place to start. If you weren't doing anything before, you you're gonna be better off, than when you started, and you're gonna have some concept of syncing here. However, one of the most important things around syncing is that there's a defined process and culture across the team for when you keep in sync. If the deployments are manual, it's really hard to enforce when folks do this, as it's not so easy to see when whether they're up to date or not. And it's also really easy to end up doing a piecemeal deployment that can miss critical items that you might need need to build on top of in the next release cycle. And then when it comes to not overriding work in progress, manual deployments will help with being slightly more selective in what you you want to bring back. So if there's an item that collided with some work you were doing to the same item in your dev sandbox, you may be able to exclude it from that deployment.
The ideal state here would be that you bring the changes to the file back from prod whilst preserving your own changes to the same file in the dev sandbox. This is something we'll come back to you later.
Now for a slightly more advanced method. This is really for teams that are already dabbling with version control and base their DevOps processes around Git. If you're working in this way, you can start to take things into your own hands by automating some of these operations using a mixture of a version control system, SFDX commands, and scripted YAML files executed via a CI server.
As you mentioned earlier, there can be many scenarios where you want to synchronize different sandboxes with a certain source of truth. These might be higher environments like QA or UAT. They could be dev sandboxes, or they could be parallel project environments.
What using a Git based process allows us to do is to align changes happening to a particular branch with a specific sandbox. So for example, your main branch will be aligned to production, meaning that when changes emerge into your main branch, the automation you scripted will identify those changes and deploy them out to production.
We can use the same method for any other branch in sandbox. As a result, we can create a bunch of highly flexible and relatively effective synchronizing operations by aligning some branches with their related sandboxes.
Now the method by which you set up this automation, if you're gonna do it yourself, can be incredibly diverse. There are a number of open source repos. There's some links, in this slide here as well and Salesforce developer articles talking to different methods here.
To deliver this kind of automation, though, your team will have to be fairly technically adept. You will have to write your own scripts to define this and execute them using a CI server like Jenkins Azure pipelines, GitHub actions, Atlassian, Bamboo, and any of the others that you can mention here. You'll also have to be okay with a few of your team members taking ownership of the the maintenance of these scripts, NCI operations to make sure they keep running successfully and performance can be improved over time as well.
So here, the deployment is just gonna take the state of the files in whatever source branch you've specified and deploy them out to the target sandbox. So before any kind of operation like this, you might want to stash your work chain your work in progress, in your dev sandbox into a branch somewhere, just in case it gets overwritten when things are coming back.
Cool. And lastly, we have an ecosystem favorite, sandbox refresh or bone as well if you use a sort of golden copy sandbox org. Refreshing is highly effective. It's gonna ensure that a particular sandbox is fully replicated from production at that particular point in time. All teams should aim to have a regular cadence for refreshing their sandboxes, and this is actually fairly necessary because not everything is deployable via the Salesforce API. So, periodically doing it is sensible.
This should be slightly more regular when it comes to orgs like dev sandboxes and less regular when it comes to more critical higher environments like QA or UAT, which are partial and full copies usually, as they take a huge amount more thought due to the preparation steps and pauses in work that might need to happen.
So whilst refreshing is highly effective, it's really the new co option. It doesn't give us the opportunity to be precise about certain items or releases we want to bring back. It has to be everything, and it absolutely does not take into account active work in progress that could be going on in the sandboxes in question.
As a result, teams often end up refreshing at very specific times with a huge amount of preparation steps, or they outright end up not refreshing. I've definitely spoken to a bunch of teams where they haven't managed to refresh for a couple of years.
And this is totally understandable with the amount of pre and post steps needed to be done around a refresh and the chance of losing critical work in progress as well. And the last point to stress about sandbox refreshes is even if you if you're using version control, there is no link or concept of branching here. So if you refresh your orgs, you're gonna need to make sure main and master is up to date with production at that point in time, then open pull request to sync synchronize all other long lived branches overall.
There are overall. There are a few commonalities we've seen. Some of them we've used ourselves in the past at gear set that are worth calling out here.
One of the main issues we see with the older approaches to back promotion is that it's handled on a story by story basis even if you bulk select these stories or pull requests to bring back.
When you're a high volume large team, this becomes really hard to handle. Usually, dev sandboxes are owned by individuals, and it's their responsibility to keep them up to date.
But let's be honest. If you have a hundred back promotions to sort through, are you gonna do that, or are you gonna get on with building the feature you're supposed to do to do for the next release?
And here, often teams combine their units of work meaningfully into a release branch or a larger feature before they're pushed out to production. So why when you're back promoting, can you not just take those combined units back in one operation?
There also tends to be a focus for having a branch for every sandbox and especially dev sandboxes. And we've certainly seen this approach in our customers before too, and many customers still do this approach.
This is fine when it comes to higher environments, but when it comes to dev sandboxes, of which some teams might have thirty or more, this becomes a huge overhead to maintain. Means you have thirty extra states to take care of along with thirty extra potential places. You could get different conflicts or errors you might have to work through. The biggest problem here is that these extra branches are not really your source of truth for what you should be syncing with, and they're often missing files from other dev sandboxes.
So, really, your source of truth is just one branch for dev sandboxes, often main or wherever you create your feature branches from. So, ideally, we should be taking the state of files directly from there.
Lastly, the age old fear of work in progress being affected is still alive and well with this approach. If you haven't already committed your changes, there is no way to check for conflicts. Often, there is work in your dev sandbox that isn't ready to be shipped yet, which could still be overwritten by a back promotion.
So with that, what should this all look like in an ideal world? What principles can we apply if we were to think about this based on what we know so far and from us speaking to customers as well.
So we should track changes that happen to a single source of truth and use those to sync with. We don't need additional branches and PRs to do this. You know? We can use main or developer, whatever you deem that source of truth to be.
The order in which promotions went out to that source of truth can be really critical when deploying back, so we should maintain that order to ensure things come back safely without dependency related validation errors.
If we deployed an entire release, we should be able to take that whole release back in one operation, not its individual stories within it. We should aim to take all units we need to sync back in one go if possible.
We seem to have a clear visibility and tracking of how out of sync a sandbox is with the source of truth so we can check where folks on the team are up to as well.
And most importantly, for work in progress that hasn't yet been committed, we need a point in time way of identifying where the work in progress will be affected by back syncing. We then need to capture that work in progress to protect it and allow a merge of those files coming back.
So I'm gonna switch over tabs to Gearset Pipelines itself. If you've never seen Gearset before or Pipelines, this is a visual representation of our DevOps process.
This is backed by version control. And you'll see here on the left, we have developer sandboxes in blue with our UK team and US team's developer sandboxes.
Those are linked to UAT, which is the next stage in that DevOps process here backed by the UAT branch. And then those flow through to production, going through main, which is our source of truth here and where we create feature branches from. We also have a parallel project stream here that needs to be back promoted with things that go out to production. And any solution you look at should track which streams those stories have come from and open back promotions going back to that.
Now when we've got a a long lived branch and environment, that's fairly easy. We're gonna automate deployments between the branch and the environment, and we can use pull requests to sync those with. But when it comes to dev sandboxes, as you mentioned earlier, the source of truth is usually just one branch. So that is main in this case.
So with that, we need to start thinking a little bit differently about how we handle synchronizing to dev sandboxes with less overhead.
So you'll see on the dev sandboxes, I'm dev three in this case, we'll have five updates that we need to take from main.
If we click onto the dev sandbox, we'll see this updates tab here, and this is essentially tracking any promotions that have happened to our main branch and gone out to production since the last time we've updated.
Here, they're presented as updates that we can take back to our developer sandbox, if we would like to to keep it in sync.
There is no underlying branch here. There is no pull requests that need to be opened or sorted through. We're simply just presenting the things that have gone out to main as updates take back. So here, I've got a few individual user stories in chronological order here that have gone out to main. I've got an entire release that will be presented as one update that you can bring back in one go here. And by default, they're all selected to take back. But if you needed to bring in a particular order, you can do if they're dependent as well.
So from here, we'll see all of the items in that update on the right hand side to check through them. And I know there's some things that I'm working on in my dev sandbox that this collides with. So think about that work in progress problem. How am I going to save my work from being overwritten? I wanna keep the stuff that I'm working on, but also bring back the changes and lines in my Apex files from main as well.
So when we click update now, we're going to kick off a deployment of these items in the way they went out to production back to our dev sandbox.
But more critically, Gearset's going to automatically identify and detect whether any of the things that I've been working what working on in my dev sandbox will be affected by this update.
Once you've identified those, we'll capture those at that point in time from the dev sandbox and then allow you to merge. If we can semantically resolve those with some of our semantic merge algorithms, we will do for XML files. And if we can't, if it's a true Apex conflict, we need to bring some things back from prod, but keep your work in progress, we'll present a conflict, which should pop up in just a moment as well. So, really, making sure that we're taking a point in time look at that dev sandbox even on things that I have not yet committed and making sure they're safe when we back sync.
So we'll see gear GearSet has detected some work in progress in my sandbox to be affected by this update. We can go ahead and have a look at what that looks like. So we'll see on the left hand side here are the changes that are in my dev sandbox related to this and those that are in main as well. For simplicity, I'm just gonna select all in dev three, and then we'll mark this as resolved.
But often, you would choose individual pieces you might wanna bring back and keep as well.
When we mark that as resolved, we'll go ahead and commit the merge, and then that's gonna kick off the update to deploy those back to our dev sandbox, and then we'll be in sync with production. I can move on from there.
So this sneak peek being over, what are the next steps that you folks can do on your team? How can you make a start?
So some final thoughts to leave you with.
First of all, just assess your starting point. You know? If you're in an org to org process, what are you doing today to stay aligned with production? Are you refreshing at all? How often is that? Are you doing any manual deployments back to, dev sandboxes periodically?
And what are you really struggling with the most? Is it the higher environment? Is it a parallel project that's really out of sync, has been ongoing for months versus your business as usual? So identify these pain points, list them out, and then think about what is the most valuable thing you can do first. Don't try and solve everything at once. Once you've identified that most valuable thing, which again could be maybe we start refreshing once every sprint to every couple of sprints so we we stay more more aligned.
Then start with that, review from there, and then build on top of that over time.
The last thing is just getting agreement and buying across your team. Now it's can be quite a scary thing to keep aligned, again, for the work in progress problem if you're not using a solution.
So, really, you want to make sure that your team is aligned on the value, the reason why you do this. What what will it stop? You know, what problems will it stop when you go further down the pipeline?
And then what are you syncing with and when you should all do that syncing as well? So with that, thank you very much for listening. I think we'll move on to the q and a now.
Thanks so much, Matt, and to Richard as well. So we have had a bunch of questions come up here.
First one here, we've got, do you think Scratch orgs help solve this problem?
Richard, do you wanna start?
Yes. Yeah. So, Scratch Orgs, we we talked with a bunch of teams about how they use Scratch Orgs and decided to be able to to spin up scratch rules easily to help do feature development. It can solve this problem to a limited extent, I think, but it doesn't really address the core of the overwrites problem. Because if you got work in progress, then it can that that can still be that can still be impacted and it's still it's very easy to be overwritten if you're trying to if you're trying to do an update, using the the traditional processes.
So and, also, if you're working for stuff for items for a for a longer period of time, then both scratch always have a limited shelf life. So they're not suitable for those cases if you've got future development which goes on across a couple of sprints. So it can be used for to solve some of this problem, but we don't think it's a complete solution here.
Awesome. Yeah. Great. I'm I'm gonna move straight on because we've got a bunch of questions here.
So the second question we've got here is, can we sync changes directly from production to a git feature branch and push it to master branch?
Yeah. Happy to take that one. So I'm guessing it depends on the scenario here. I would love a back and forth on this one. But I'm assuming if you want to, sync to a feature branch, this may be when changes are being made directly in production that you need to reflect in main.
Most changes flow into a feature branch from a developer sandbox. I'm assuming this is the case. You definitely could do this easily. Yeah.
I mean, there's flexible in gear set certainly or using DIY automation. You could set up, automation between production and a particular branch to capture those changes that you can periodically merge merge into main. Just Just always be really careful what those changes are, how you identify them. And whenever you're dabbling with main, be very careful.
That's all I'll say. But, yeah, you can absolutely do that. I'd look at a flexible, CICD functionality to do that. Yeah.
Perfect. Thank you, Matt.
Got final couple of questions on on the demo, and the new functionality, you showed us there, Matt.
So first of all, Cam has asked, does this send updates to the sandbox directly instead of pushing a branch and then that branch pushing to the sandbox?
Yeah. So as we said, there's no dev sandbox branches backing the DevOps here. We're directly tracking main. And then the idea is that we're taking the exact state of those items from main, pushing them back. We do have some architecture in the background that only lives for as long as the update is going on to do that, check for work in progress where we capture that from your dev sandbox, and that does involve spinning up a couple of branches to get thrown away after the update is done, essentially. But they're they're not long lived branches, and you do not need branches, as the conduit for those deployments.
Thank you, Matt. Unfortunately, we have run out of time today. You can always reach out to us, at gearset dot com via the live chat on our website. Or if you're a Gearset customer already, you can reach out, via the app there as well.
If you, currently aren't a Gear Set customer and are intrigued by any of the bits we've chatted about today, Matt, if you wouldn't mind popping on to the next slide. I have, put a QR code there for you on screen, and and that there will invite you to try all of Gearset's Salesforce DevOps platform, for thirty days for completely free.
