Description
Knowing how to harness the full potential of version control can be tough, even for advanced Salesforce teams — but Git doesn’t need to be difficult. In this 30-minute webinar, discover how to take your version control to the next level and successfully build a mature Git-based version control system for Salesforce.
This webinar is for you if you’re a Salesforce Admin, Developer or Manager.
In this webinar you’ll see:
• Successful branching strategies and branch management
• How to manage and limit merge conflicts
• How adopting a ticketing system aids delivery
• How to apply automation to your Git-based workflow
Learn more:
Related videos:
Transcript
Welcome everyone on to today's session. As Amy says, we are doing git for Salesforce, a deep dive. Hopefully that's what you've turned up for. And it's part two of our series on Git for Salesforce. We're gonna build on the foundation that we laid on our previous session. And diving to some more advanced topics and best practices.
Now don't panic if you missed that first session, a recording will be available, where you can play catch up a little bit on that one and get the overall picture.
So as Amy has said, I am indeed Rob Cow, one of the dev ops advocates here at Geerset, and that role means that I'm here to kind of help you, the Salesforce community, Get around the world of Salesforce dev ops and hopefully help you succeed in delivering all your amazing work on the platform.
So before we begin the deep dive, let's have a quick outline of some of the topics that we're gonna cover today. We're gonna look at branching strategies and branch management and look at some of the different strategies that teams adopt for branching in git. With a bit of an emphasis on the approaches that have proven successful for Salesforce projects, that we've seen in the wild, We're gonna look at managing merge conflicts, which are a pain for many, and we'll touch upon what those merge conflicts are why they occur, and share some best practices on how to manage them effectively.
We'll have a look at adopting ticketing systems and will shed light on that partnership between version control and those systems highlighting how they can aid in streamlined delivery.
Then lastly, we'll have a look at how version control can pave the way for automation and automating your release process.
We'll look at how such functionality in gear set can supercharge your git workflow for Salesforce and make those tasks like continuous integration and deployment both efficient and effective.
So as journey through these topics, I encourage you to have a think about your current workflows think about how some of these practices might fit in.
So with that, let's jump into that first topic.
So branching is very much at the heart of git, and it enables teams to work on multiple features or fixes in parallel without stepping on each other's toes.
So why is branching so vital to this? I like to think that there's three main reasons Firstly, we have isolation.
Branches allow you to isolate your changes and not getting in each other's way. Which means that you can work on a new feature without affecting that main code base until you're ready.
Next, It enables collaboration, probably my favorite aspect.
Being able to share those branches between team members ensures that work in progress is always visible changes are less likely to get overwritten, and it's foundational to the ability to peer review your work and just make sure that everything is up to a certain standard.
And as mentioned, we can do simultaneous development. Having several branches means that multiple features or fixes can be developed and tested simultaneously, and that speeds up your overall development process.
So as we delve deeper into DevOps, we'll see that the success of using branches is gonna largely depend on which strategy you adopt.
So when we dive into those branching strategies, there's a few approaches that you might consider.
But today, we're gonna focus on three core models that have proven effective.
Each of those strategies has its merits. And the choice that you make is gonna largely depend on your team's specific needs and the dynamics within your team whether it's more admin centric, more developer centric, or a good blend of both.
But remember, it's crucial to pick a model that aligns with your team's objectives and scales with your project's growth. There's no one size fits all.
So with that, let's start looking at the feature branching model first.
Now this is the simplest model, and it's also the one that we tend to recommend as a good starting point with a feature branch strategy the latest version of your metadata is stored on the main branch.
And that should always ideally be in a state that's ready to release.
It's your only long lived permanent branch.
When someone wants to develop a feature or a fix, they create a new branch from Maine and work on that branch.
Once the feature is done, the branch is then merged back into main.
Now ideally, in this model, feature branches should be as short lived as possible and deleted after use for general tidiness.
Larger features should be sliced into smaller deliverables and implemented one at a time. And that reduces the length of the feedback cycle from folks testing it and reduces the chance of merge conflicts as well.
This main branch is usually deployed automatically to other environments whenever it's updated using a CI process. And that means that the latest version is gonna be always available for you for testing on your staging environments.
Once you're happy with that version, then a deployment from main to production environment will release that change to your end users. But optionally before that deployment, you could deploy to a a separate UAT or QA environment or however many environments you want for further testing.
So the next strategy, we call protected main branch. And this one's similar to the feature branch model, but adds one long lived branch for integration before merging into main. So in this model, the main branch isn't updated until everything is tested and ready to go.
This makes Maine more of a protect protected source of truth as only work that has been fully tested in UOT can make it into the branch.
But one drawback of this model is it's not possible to propagate just a subset of changes if some of them aren't ready yet. If some of this work has been tested and approved, but others aren't quite ready to go yet, it's very difficult to cherry pick which ones you want to promote to the main branch.
You'd have to revert features that aren't ready from the release branch. So a lot of teams don't tend to go for this model because it slightly more inflexible when you need to pull changes back out again.
To address this, we have the expanded branching model, Now this model adds a few extra long lived branches, which will correspond to your integration, your UAT, and your QA environments, Once a feature branch is complete, again, rather than merging it straight into main, it's merged into the integration branch.
Then to promote any changes from there that you're happy with, you would merge into UAT branch, QA branch, staging branch, etcetera, and onwards on to main.
Now this model allows more fine grain control of which changes get through to each environment.
It allows for better isolated review changes on a per request basis.
And it's better for slower paced dev streams where releases happen less frequently. For example, if you have multiple work items, tickets, etcetera, that make up a sprint, for example.
Now while adopting a branching strategy is essential, it's equally crucial to manage these branches effectively.
Based on some of the insights that we have on our gear set blog, let's explore some of the key best practices.
As we touched upon earlier, the right branching strategy should be a collaborative decision based on your team's workflow. So be sure to involve everyone in that discussion to get buying and a more cohesive approach.
You also need to stay flexible as your projects evolve, so do their requirements, and maybe a strategy that worked at the project's onset might not be as effective later on. So always be open to reevaluating and tweaking your strategy.
Now long lived branches can become a bit of a developer's nightmare, So merging them back after an extended period results in those painful merge conflicts.
We can solve this with regular merges which help keep branches up to date and reduce those complexities.
And finally, I'd encourage you to have some consistency in your naming standards for your branches.
Imagine having dozens of branches with cryptic names, it's gonna get quite confusing.
But adopting a consistent naming convention, such as perhaps including a a Jira ticket number or a very brief description of what it relates to or what objects it affects can make branch identification and management a breeze.
Remember, the ultimate goal for branching is to ensure that it doesn't hindeer your development process, but actually makes it smoother and more efficient.
So let's talk a little more about those merge conflicts that, that haunt our branches sometimes.
When multiple developers collaborate on a code base, inevitably, we encounter a scenario we all know too well.
But what exactly are these merge conflicts and how do they happen?
So merge conflicts occur when developers or admins make competing changes to the same parts of Salesforce metadata in parallel branches.
It can't automatically reconcile these conflicts in all cases.
So developers have to manually review, resolve, and merge the changes before completing the branch integration.
Now the impact of this on Salesforce development can be significant.
Unlike up to some other platforms, Salesforce's metadata files can be extensive and complex.
So resolving conflicts in these files can thus be time consuming and require a deep understanding of the platform.
However, the silver lining is that by anticipating and understanding the nature of these conflicts, we can mitigate the frequency and impact they have.
So utilize tools that highlight potential issues, maintain communication with your team about ongoing changes so that you know who's working on what and embrace some best practices to streamline your development process in Salesforce.
I would like to reiterate that communication is key here.
Now these merge conflicts might seem a little daunting, but with a few strategies, we can reduce how often they occur.
Emerging your code regularly, as mentioned earlier, is a good proactive step. Because by ensuring that everyone's got the latest version, we lessen the chance of overwriting someone else's work.
And another good practice is to commit your changes little and often. So instead of waiting for a big chunk of work to be done, make small commits. And this makes it easier to spot where the conflicts might pop up and allows you to trace back any issues.
I can't stress highly enough how open communication is your best friend here. Simply having a chat amongst your fellow developers about who's handling what can prevent a lot of those potential headaches is kinda like calling Dibs on a piece of code for a little while.
Lastly, when you're working in the Salesforce environment, it's crucial to remember that not everything needs to be tracked.
Making use of a git ignore file helps keep out some of those unnecessary files like local development settings, for example.
Being choosy about what you put into gear can save a lot of time down the road.
So with these practices in place, managing conflicts becomes a much smoother process, and it helps keep our focus on building things, not troubleshooting the process.
So now let's move on and have a look at using ticketing systems such as Jira or Asana, which changes how your teams can tackle projects.
They provide a platform to track your work and make sure that everyone knows their tasks.
That can only boost collaboration as members can align on goals. And result and results in more cohesive results.
With everyone having access to that project status, you get a lot more transparency, and it's clear where things stand at any point.
But to tie it back to version control, perhaps one of the most impactful benefits is the ability to directly link your code changes in git to your business requirements This connection means that the technical work always ties back to a clear business need and tickets can be updated with their status automatic as your changes move through your pipeline.
When we look at the two leading systems for this, Jira excels in detailed tracking for those larger projects, while a sign of asana tends to shine more with its user friendly approach, and it makes it great for a whole range of teams But obviously, like so many of these things, the right pick is gonna depend on your team's specific demands and needs.
So as we've delved into some of these strategies that will streamline your Salesforce development and deployment, A question naturally arises, how can we implement these effectively?
And that's where gear set can come in.
Having one single platform that addresses the needs we've discussed will simplify that entire process, and it frees you up to focus on delivering value to your customers.
Gear set seamlessly complements some of those methods we've discussed. So remember our emphasis on regular mergers making sure everyone was on the latest code version, or gear set's visual approach allows you to clearly see your changes, and it makes those merges more intuitive.
So you don't need to spend time deciphering cryptic lines of code. Instead, you get a clean visual summary.
Speaking of those small frequent commits and the importance of automation, gear sets CI jobs and pipelines act as the backbone It's not just about automating for the sake of it, but making sure that each of those steps is transparent, efficient, and aligned to our overarching goals.
And so with gearstick, automation will feel less like a robot taking over and more like an intelligent assistant that guides you through the process.
And remember we talked about the need for communication and monitoring for changes? Well, gear sets aug monitoring ensures that we're always in the know about those changes, and it reinforces the strategies we've discussed for proactive conflict management and team coordination.
Changes in production happen sometimes. We shouldn't pretend that they don't, but how we track and handle them appropriately is what stops them from being unmanageable And so the ability to be notified of any differences between your Salesforce environments will help you stay on top of that change.
So as we draw our deep dive into Git for Salesforce towards a close, it's clear that a harmonious blend of best practice platforms, and a commitment to collaboration will help elevate your Salesforce development journey from delving into branching strategies to the invaluable role of ticketing systems and the essential task of managing merge conflicts with navigated through a whole wealth of transformative technologies.
A standout point for me has been the incredible potential of automation, especially in platforms like gearset come into play. It's not just another platform. It's a partner that refined your development workflow, ensuring our energies are directed at innovation and delivering genuine customer value.
You can see this for yourselves with our own free thirty day trial if you're not already on board. It's fully featured. You get access to everything. So you can explore all the capabilities will bring what we've talked about today to life, and we'll have a handy QR code you can scan for that on the next slide.
So I trust this session has offered you some actionable insights that you can incorporate into your teams and projects.
As we look at that intricate dance between Salesforce and Git, we should remain dedicated to learning, adapting, and most importantly, collaborating.
We have a great opportunity for you to do just that and gain other dev ops insights, but our upcoming event in London, dev ops streaming, which will be on November the sixteenth.
You can find out more about that at dev ops dreaming dot com, and you can alternatively scan the QR code on the left hand side of the screen. Hopefully, I'll see some of you there and we can chat about some of these topics.
On the right hand side of the screen is that free trial that I mentioned a moment ago.
So in the meantime, thank you for your engagement and your thirst for knowledge by joining us today. And at this point, we can open up for any questions you might have. That you'd like to discuss further.
Thank you.
Thanks so much, Rob. That was fantastic.
Super insightful. And as you say, some really great advice there for people to take away and and action themselves.
And yes, just to reiterate if we don't get around to answering your question today, please feel free to reach out to us on our live chat via our website, gear set dot com, and we can answer any of your questions over there too.
But before we do end today's session, we have got time for some of your questions that have popped up in our q and a. So the first one I've got here for you, Rob, is from Soma. How can we manage preview Sandboxes in the deployment pipeline, and they specifically mention, how they can do that if, if a preview metadata gets into git and makes deployment errors on non preview sandboxes or productions.
Okay. Now that's a that is a a great question. And I have, mildly painful memories of of having gone through this, in in my former life as a developer. So I think there's there's a a couple of key strategies that we need to kind of bring to bear on that one. So one is, you know, in an ideal world, of course, we know, we want to preempt those kind of challenges and and make sure that it doesn't happen.
I I appreciate that's easier said than done. But one of the key techniques that we can do for that is to be very mindful around that, preview sandbox release window that happens three times a year, and look at the API versions.
So for example, you know, I think, you know, We can we can look at the the highest common sorry, the the lowest common version number. Of of the API. So for example, if we've got, environment that's on API version fifty eight and another that's on API version fifty nine, then we'd want to target fifty eight because we know that both of those environments will have that same metadata in common. So the first part of the answer to that would be to just be mindful of of kind of when that window is and what the repercussions are and what versions those are.
However, I as I mentioned, it's not always an ideal world, and this is where Git's capabilities of being able to roll things back come into play. So if something has inadvertently got in that you don't want, you know, we always have that option to kind of roll back a a commit if it's still in, you know, in the git side of things rather than the Salesforce side of things. So again, the earlier we detect and address problems is is always the the better strategy on that one. If it has got further down the pipeline, because you've gone, for example, from development to UAT, and they're both on newer sandbox, there's a little bit more unpicking to do there.
But again, if you roll back the commit and redeploy, generally, that sorts out a lot of those problems.
I will wrap that answer up very quickly to say that both of those strategies are reasonably well managed in gearset. So by default, gearset will adopt that lowest common API version for your deployments, and, of course, being deeply invested in working with git, it will make those rollback deployments much easier for you.
Excellent. Thanks, Rob. So I mean, we hope that answered your question today.
We do have a couple more questions for you here in the Q and A So the next one is from Gerald, and he says, this presentation has been a good step first step for me. Can you suggest some next steps on how to use gear set and GitHub?
I can indeed. And this is one of my favorite questions.
So we many of you on the Salesforce platform will be familiar with with Trailhead, and they they certainly have a a a git and GitHub module on there. But if you want to kind of expand on more dev ops specific stuff, whether that's specific to gear set or dev Salesforce DevOps in general, then I would definitely encourage folks to go and look at our free, online training platform, dev ops launchpad dot com, There are modules on there on GitHub, branching strategies, how to manage, DevOps teams as well as, you know, whole raft of of gear set specific stuff. So whether you're using gear set or not, there's gonna be something that's gonna be usable and applicable to your DevOps process in there, and you'll be able to apply that to a multitude of tools as well as get that specific gear set product knowledge. So whichever path you choose, there's gonna be something for you available at dev ops launchpad dot com.
Excellent. Thanks, Rob. And, yeah, Daryl, do check out, the recording from our previous webinar Salesforce, the basics, that'll have some extra tips on there for you. I'm sure you could take away.
Right. We I think we've got time one final question for you, Rob.
So a question here, what are some of the technical strategies for resolving merge conflicts?
Oh, hi.
I I love the technical ones. This is where I get to deep dive as as promised in the title of the session. So there are many, many strategies to resolving merge conflicts, you know, and, you know, while I think, you know, and I've I've mentioned that, you know, talking to your teammates and agreeing, you know, whether the field length of this should be twenty or thirty, for example, is is probably the easiest path. Sometimes it's not always that easy, and sometimes you know, the conflicts are quite detailed and and complex.
So there's a few kind of der say industry standard approaches that we can take.
So the default strategy that Git will take is called the recursive strategy.
And it looks at the the entire commit history of a branch to determine, like, where there's a common starting point.
Before those branches kind of diverge from each other, and then it kind of works its way through kind of replaying those changes from both branches. And if it hits a conflict along the way, it'll just prompt you and say, I can't figure this out. You're gonna need to make a human decision here.
So another strategy is is lovingly called the octopus strategy because it has multiple tentacles, and that's used to merge branches all into one single branch, like, for example, a release branch. So it's great if you want to aggregate a whole bunch of features together from multiple developers, you know, to form a a universal release branch. That that works for a lot of teams.
There's the resolve strategy, which is kind of similar to that recursive strategy, but I into into much as it merges the changes and and waits for that manual intervention, But as the name suggests, it it isn't recursive. So it doesn't analyze that entire commit history. So it's only kind of working from that latest point Then there's a a pair of strategies that kind of, are opposites of each other. There's the hours and theirs strategies.
So the hours strategy gives priority to the branch that's being merged into. And as you might have guessed, their strategy gives priority to the the incoming changes. And again, you know, you might want to to use, that as a blanket strategy to just say, no, I have a hard and fast rule that new means new, and I will always adopt what's incoming.
And if a last one that off the top of my head It's probably the subtree branch.
And that's kind of really useful for those, like, really modular, environments where you've broken things up into into chunks or or subfolders or libraries of code, and allows you to merge from a remote repository into a subfolder of your current repository. It allows you to have, like, you know, a core branch, then one for sales, one for service, one for some other custom application you're doing, and kind of have a much more modular approach to things. So those those were a few. And, you know, like all of these things, like I mentioned earlier, you know, it's important to select a strategy that kind of suits the way that your team works. You know, there is no kind of universal answer to that. But hopefully, one of those will will resonate for the way that your your company, your organization, and your team prefers to work.
Perfect. Thanks so much, Rob. That's brilliant. Well, I think that's all the questions we have time for today.
It's been a fantastic session. Thanks all our lovely attendees for joining us and a big thank you to everyone here from Geerset and to Andy for answering your questions and of course to Rob for running the session today. We hope you found today's webinar super helpful, and we hope to see you again soon at more of our sessions. So thanks so much everyone and take care.
