Webinar: Getting started with version control for Salesforce teams

Share with

Description

Learn how to set up version control for Salesforce with one of Gearset’s DevOps Advocates, Rob Cowell. You’ll discover what a Git-based workflow looks like, as well as the practical steps and decisions that’ll help you get started.

Taking into account all shapes and sizes of Salesforce teams, Rob will discuss:

  • Which hosting provider is right for you (GitHub, Bitbucket, GitLab etc)
  • How you can configure your version control repository
  • How to choose a branching strategy that suits your team
  • And which metadata to start with.

Learn more:

Related videos:

Transcript

Well, welcome everybody to today's webinar in which we're gonna explore how we can get started with version control in the Salesforce world as part of a DevOps transformation.

So my name is Rob Cowell. I'm one of the DevOps advocates here at Gearset, and my role involves working with you, the wider Salesforce community, to help guide you on your Salesforce DevOps journey, however far along that path you may be.

So as we start exploring version control today, I'd like to take a moment to outline what we're going to be covering over the course of the session. I expect that we have folks here at varying stages of their adoption of version control, and and I want to ensure that we cover things that are relevant for everyone.

For some of you, this will be new to you, and we definitely wanna make sure that we equip you with enough information to get started with version control.

For others, today's session may be more of a confirmation that the steps you've already taken align to best practice, but hopefully, you'll be able to gain some new insights or techniques.

Ultimately, we want to be able to contribute to your success with version control and with DevOps in general.

So with that in mind, I'm gonna briefly cover the core areas of version control.

I'll discuss what version control is and the different version control system providers that you can choose to host it.

Next, I'll explain what a standard version control workflow looks like and introduce some different branching strategies that your team could choose.

Then finally, I'll bring the theory into practice by showing you how to set up version control for a new Salesforce project and demonstrate how to work on your Salesforce changes and use version control to deliver them.

So let's kick things off with a look at what version control actually is.

Now some of you might hear the terms version control and source control used interchangeably.

I know I do. And largely, they mean the same thing.

At the core of both concepts is the idea that as we continue to develop change, we want to be able to track that change over time and retain the ability to see what was changed, when, and by whom.

Effectively, this is seeing the different versions of things, hence the term version control.

In this sense, these versions can be iterations of code, of config, of documents, of images. We're tracking files here.

Those files that we are tracking are the ones that make up the changes that you've made to your software. In our case, your specific customizations and enhancements you've made to your Salesforce org to fit your business and your way of working.

This doesn't have to be just code either, as we'll see later, and it's important to realize and retain the notion that source control, much like all of Salesforce DevOps, is for all folks that make changes to Salesforce. So whether you're low code or pro code, it's a valuable and important part of your growing Salesforce DevOps maturity.

We also want to take a look at why version control is a worthwhile practice, particularly in the Salesforce space.

And I like to think that the most important word of version control is control.

Version control allows us not just the visibility of how changes come through, but it allows us to better manage how that change is delivered. It affords us the ability to decide the pace of delivery, our release cadence.

It also gives us the opportunity to start using some important practices and techniques that are fundamental to good DevOps, peer review, the ability to roll back changes, and, of course, it unlocks the power of automation.

All of these things contribute to the control of your changes and provide you with a framework on which to build your strategy.

To actually start using version control, you need a tool called a version control system.

There are several version control systems out there, but the most popular choice is Git. It's become the de facto standard used not only for Salesforce version control, but in a huge swathe of software projects on every single platform imaginable.

In fact, the terms Git and version control are often used interchangeably too. Git's the version control system that we're going to be covering today.

Equally, there are a number of different providers that you can use to host Git. You'll need to decide which one best suits your organization.

When choosing a provider, there's a few things to consider.

If you use or plan to use automation, check the provider has easy integration with CI platforms or has one of its own.

If you use change management software such as Jira or Azure work items, you may find it easier to manage your work if you choose a version control tool from that same provider.

If you're working in a highly regulated industry such as financial services or health care, the ability to self host your repositories on premise will affect your decision.

And you should also consider the interface and ease of use for your team. So make sure that you look at all the options out there.

I'm gonna cover a few of them now.

With over seventy million users, GitHub is the most widely used version control system provider in the world. GitHub offers automation capabilities through its GitHub actions, which is great if you're looking to automate testing or deployments with your own scripting.

Bitbucket is a fantastic option if you're already using other Atlassian software like Jira, although it's worth noting that they're not the only provider that has Jira integration, of course.

Azure DevOps from Microsoft is another example of a suite of tightly integrated services for your whole DevOps process.

And GitLab is a popular option for the security conscious. It allows you to self host easily on your own servers.

Now there's a lot more to say on all of these providers, obviously, but, hopefully, this will give you a place to start your research.

So now that we've covered the tools that you need to use Git, it's time to see what a version control workflow looks like by going through some of the terminology that gets used a lot when we discuss version control.

A repository. This is your container for source.

Vers Git can have multiple repositories, but but it's useful to think of it as your top level folder in which you store your source.

A branch is a copy of your source. It could be your primary copy, your source of truth, or it could be a variation in which you're making your changes and enhancements.

Merging is the act of reconciling and combining these changes back into your primary branch.

And finally, a pull request is your set of changes that you're proposing to merge into a branch.

This itself is a powerful mechanism. It delivers on that promise of control, review, and accountability that we touched upon earlier.

So let's put some of these terms into context with an example.

With Git, everyone has a copy of the source code and can contribute changes without depending on a central server. In practice, however, the most common way of working with Git is to have a master or main branch as our primary branch.

From this, other branches are created as an exact copy of all changes that are added into this new branch.

Once the changes are ready, a pull request is created.

As I mentioned earlier, this can quite literally be thought of as I'm requesting that you pull my changes from my branch into the main branch.

A teammate will usually review and approve your pull request, allowing you to merge your changes back into the main branch and then deploy your changes onwards to production.

Now this model that I've described and that you can see on the screen here is called the feature branch model.

A branching model or strategy will set the rules for how you use and manage those branches when developing features in version control. So it's important to choose a branching strategy that meets the delivery needs of your business as well as suits the type of team that you have.

The benefit of the feature branch model is its simplicity, and you may choose this option if your team's fairly new to version control as a concept or if you have a lot of people interacting with version control, for example.

Another model is the expanded branching model. Once a feature branch is complete, rather than merging it straight into main or master, you merge into your integration branches.

To promote any changes from there that you're happy with, you'd merge those, for example, into the UAT branch and then onwards into master.

This strategy works well for teams that are more concerned about stage gating and quality control than releasing as frequently as possible.

Now there are several different branching strategies you can choose from, and we're not gonna cover them all here.

If you're just getting started, we definitely suggest starting with simplicity.

As your experience grows, you continue to evolve this practice to best suit the way that you want or need to work.

To find out more about the pros and cons of these different branching strategies, you can scan the QR code here to read my recent blog post on the topic. I'll leave it there for a few moments just so that you can have an opportunity to scan that.

Okay.

So the other early decision that you'll find yourself having to make is which metadata to add to your version control. And, again, there's a few approaches to this. One approach, if you're using Versus Code for your development, is to take the project defaults that are created for you when you start a new project in that environment.

A big advantage of that is that folks can check out your repository and have a working project straight away. Indeed, that's how Salesforce themselves often structure their code examples.

However, there's a strong argument for keeping things as simple as possible with a more minimalist approach.

I would suggest definitely add your standard and custom objects, your profiles, and your permission sets.

Additionally, think about your UI and consider adding your layouts and your lightning pages.

At this point, you probably want to then consider how your org is built.

If you largely if you're largely declaratively focused in your building, flows would be a good thing to add next.

More code focused teams might want to think about Apex code and lightning web components.

This all comes back to what we always say. There's no one way to do Salesforce DevOps, and you should choose based on the way that you work, but these are some baseline suggestions.

As your development needs grow or you have pieces of work that encompass other metadata types, feel free to add them as you go.

These are big concepts with big potential.

So let's start unpacking that in a more practical way and see how we can get started with version control by bringing it to life.

So my first step is I'm gonna create a new Git repository in which to store my project, and I'm gonna do this from Versus Code simply for convenience. So let me just switch to Versus Code for you.

Okay.

So what we have here is a Versus Code project that is connected to my Salesforce org.

The Salesforce org has its alias here in the bottom left corner of version control, and I've got the default set of metadata that a new project will bring down. This goes back to what I was talking about, taking sensible defaults.

So as I say, what I want to do is create a new Git repository in which to store my work.

I'm gonna go to the tab here.

Now very conveniently, Versus Code has this publish to GitHub button, and that's what I'm gonna use here.

This isn't obviously the only way to do it, but, again, for the purposes of of the demo and and time saving, that's exactly how I'm going to do it today.

And we can see there, it's successfully published to my GitHub account, which is connected to my Versus Code.

What we'll now see in the bottom left corner is that we're connected to our main branch.

What we can additionally do with a few mouse clicks is go to GitHub and do a quick refresh.

And I can see my new version control webinar repository populated with the same files that I had in my Versus Code project.

So we're set up our baseline, and we're we're good to go.

So with my Salesforce project in Versus Code, I and I a new repository linked to it, we're going to start some development work. So the first thing I want to do is create a new feature branch for the feature that I'm going to work on. And again, amongst many other ways of doing it, I can create that from GitHub itself By clicking here, typing in a branch name, I can create that brand new branch. And if you recall, a branch is a copy of our main branch.

So what I've done here is create a feature branch that I can start putting my work into by switching back to Versus Code.

What I'm going to do next is I'm going to fetch. A fetch is basically allowing the environment, the the development environment, to say, let me see what new branches are available for me to work with.

I can now, in the bottom corner, switch to my newly created branch, and I'm good to go.

So once I've done that, I'm ready to start my development work.

What I'm gonna do for today's demo is quickly pick this very simplified piece of code and make a small change like so, and I'm going to save that. Now what that's doing there is saving that back to my Salesforce org. It's not saving it to Git at this point. We'll cover that in just a moment.

At this point, I think it's worth pointing out that my background prior to Gearset was as a Salesforce developer, Salesforce consultant, so I'm very comfortable with Versus Code and the command line to achieve things. And that remains a valid scenario.

And like we've said, there's there's no right way to do Salesforce DevOps.

But for the purposes of today's demo, I'm gonna make things a little easier, and I'm gonna use Gearset to walk through some of the other steps in this life cycle.

I'm doing this simply for speed and simplicity in today's session. It's certainly not mandatory, but I want to demonstrate some of the the different ways in which we can do the same task.

And you can mix and match your approach too. Any changes that you or your team make to your source code repository will show up regardless of how they got there, whether that's through Gear Set, Versus Code, the command line, or even in GitHub directly.

This is more about demonstrating the steps that we take here rather than specific tooling.

So if you bear with me, I will jump back to some of my browser tools.

Quickly refresh.

Okay. So what I'm gonna do is a quick comparison between my Salesforce environment and my newly created feature branch. I'm not gonna do a deep dive on, gear set features here, but just so that you're aware, I've previously connected my Salesforce org and my version control to, to GitHub in advance so that we can actually pick those up. So we can see here on the left hand side, we have the Salesforce org, and on the right hand side, we have our source control repository.

And I'm just gonna do a basic comparison, which is a very lightweight subset of our metadata. If you recall, we talked about being very minimalist in terms of what we actually want to pick into source control.

So I'll kick off that comparison.

While I'm doing that, let's have a quick recap of where and how we are in that process.

Just as soon as I can get back here. Perfect. So what we're doing here is we we're on our feature branch up the top here because we created that earlier from GitHub, and we're committing the chart the changes from our dev sandbox at the top here into our feature branch down the bottom here. Okay? This is equivalent to the commands git add, git commit, git push. It's kind of wrapping up that entire life cycle, through the UI in in gear set. And, again, you're absolutely free to to do it from the command line, from Versus code, or whatever tooling you are most comfortable with.

So at this point, we're we're kind of at these blue circles on on the top of the feature branch.

So you can see, you know, as we work through that that workflow, we're kind of going up, across, and down.

So let's flip back to gear set and see how that's coming along.

There we go.

Perfect. Okay. So we can see here we've got one changed item, okay, which is the Apex class we just changed. It's saying that there is one difference between the version in our, org that we've just saved and our version control that we want to target.

So we're going to say, yep, we want that one, and we're just going to move across.

And here we are. Okay. So this is a quick summary of the things that we're going to be putting into our source control. What I'm going to do here is give it a commit message. A commit message is a meaningful description to the set of changes that you're adding to source control, and it aids future review.

As meaningful as I can get in a demo, of course.

So at this point, I will now commit those changes into source control.

And, again, this is the same as, a commit and a push from the, Git command line or stage changes, commit, sync changes from the buttons in Versus Code. It all works exactly the same way.

So I can see that I've pushed my edited class here, and I've added it to the feature branch, and we've got it into our source repository. If I go to, my git now, I can see has had recent pushes less than a minute ago. Okay? That's it picking up. And this goes back to what I was saying about, you know, regardless of how or whichever tooling that you use to to get your changes into version control, that they're going to show up in a a consist consistent fashion.

Now at this stage, we need to think about how we're going to get those changes onwards to production, and there's a couple of ways that we can approach this. But, ultimately, if we're looking at version control, we want to change to head back to our main branch.

Many organizations will have some additional review and approval of changes as a safeguard, so we're gonna look at that scenario by creating a pull request.

Some folks new to version control find that this particular piece of terminology may be unintuitive. But as a reminder, I'm requesting that you pull my changes into main is is a good mnemonic or or sentence to think about that concept.

It's this stage in the life cycle that the review can happen, whether by automation or via human interaction.

For purposes of a demo today, we're gonna touch on it very lightly so there are no external viewers or automation.

So I am just gonna do a quick pull request here from GitHub. And, again, I can do that from the command line. I can do it from GitHub. I think you're detecting a theme here in terms of, how we can create the various steps in that process.

Okay. So it's doing some checks. As I said, there there are very few checks in place for this demo environment.

So at this point, we can see that the most vital indicator here is that the branch has no conflicts with the base branch. So, basically, what that's telling me is that nothing we're deploying here has the potential to overwrite someone else's changes or at least not in a way that can't be automatically resolved. So if two people have worked on the same file, for example, sometimes conflict can arise. Sometimes that can be sorted out automatically. Sometimes it needs a little human intervention to say, actually, these lines are the ones that I actually want in there. But in this scenario, it looks like we're good to go. So we're gonna merge that pull request back into our main branch.

Quick confirmation.

And that pull request has successfully merged and closed.

Now I recognize that at this point, some of you might be a little more advanced with your experience of of working with Git version control, and you might be thinking of things such as squash commits or rebasing.

Those are complex topics that we're not gonna cover today. I want to do a kind of an introductory session, but, perhaps in a future session, we might be able to revisit those.

Right now, we're just going for a simple merge.

It all seems to have gone in quite nicely. So in the spirit of good version control hygiene, something that we recommend, I'm just gonna delete that feature branch that we've now successfully merged. We don't need it hanging around anymore.

So that we get a nice clean set of version control.

So now if we look at our main branch, we can see that that pull request has been merged into our main branch one minute ago, exactly where we need to be.

So now that our code's safely in main, the final steps that we need would be to get that into our production Salesforce environment.

And as we've seen in most of these other steps, there's a few ways to do that too.

An automated CICD process might be already set up to detect when a new merge is made into the main branch and deploy it to production for you.

Or perhaps you use gear set to compare compare your main branch against production and deploy the net differences.

Lastly, you could deploy your changes to production using Versus Code or the SFDX command line if you prefer.

This highlights that there's still many ways to achieve your Salesforce DevOps, so definitely find the unique way of working that's gonna fit your preferences.

Now in our demo today, I've been using a developer edition environment, so I don't actually have a production environment to show you.

But that itself does demonstrate how easy it is to put these concepts and techniques into practice in a safe environment by using a free developer edition org, a free GitHub account, and possibly a free gear set trial from our website, you should be able to easily replicate everything that I've done here today.

So let's flip back to our slides.

So a quick recap back to the diagram to replay what we've seen here.

So I ran through the main stages of a basic version control workflow.

I created a feature branch from GitHub in order to make my changes, and I made my changes in Versus Code.

I committed these changes using, GearSet, and I created a pull request from the GearSet sorry, from the GitHub UI in order to validate those changes. And the pull request was approved, although admittedly by myself in this scenario, and merged back into the main branch. And then this could be easily deployed onto production.

So you can see the flow go here from main to feature branch across the top. We make our changes.

We create our pull request.

That gets code reviewed, and then it gets merged back into main. So from left to right, we've kind of completed that flow.

So, hopefully, I've helped give you some of the fundamentals that you need to start with version control on your Salesforce changes.

If you want to learn more about version control at a deeper level, there's several courses available on our free learning platform, DevOps Launchpad, where you can go into much more detail about version control, branching strategies, and a whole host of other DevOps topics. Just scan the QR code on the left.

And if you want to see how you can use Gearset to deploy Salesforce metadata as part of that source driven workflow, you can sign up for a thirty day trial using the QR code on the right.

I think we are well covered on an introduction to version control.

Feel free to to contact us if you have any questions. Have a look at the DevOps Launchpad.

And in the meantime, I shall allow you three minutes of your day back again, and thank you for joining us. Take care, everyone. Bye now.