Description
Git is essential for any scaling Salesforce team, but it can be difficult to know where to start. In this 30-minute webinar, discover the fundamental principles of successfully adopting Git-based version control for Salesforce.
Learn more:
- Creating branches in your version control system with Gearset
- How to build a Salesforce CI/CD pipeline using GitHub
Related videos:
Transcript
Welcome to everyone, and today we are going to cover version control in the Salesforce world and explore it a little bit further.
So as Amy says, I am indeed Rob Cow, one of the dev ops advocates here at Gearset, and that role involves working with you folks, the the wider Salesforce community to help guide you on your dev ops journey, however far along that path you might be.
So as we start exploring version control today, I wanna take a quick moment to outline what we're gonna be covering over the course of the session. I expect that we've got some folks here that are at various stages of adopting version control. So I want to make sure that we cover things that are relevant for everyone. For some of you, this will be pretty new to you, and we definitely wanna make sure that we equip you with enough information to get started.
For others, today's session might be a bit more of a confirmation that the steps you've already taken aligned to best practice, but hopefully you'll gain some new insights and techniques along the way regardless.
Ultimately, we want to be able to contribute to your success with version control and with dev ops in general.
With that in mind, I'm gonna briefly cover the core areas of version control.
I'll discuss what version control is, and it explain what a reasonably standard version control workflow looks like.
I'll then walk through some of the factors that will influence the strategies that you take such as branching strategies and what metadata to use.
And then finally, I'll bring some of that theory into practice by showing you how to set up version control for a new Salesforce project and demonstrate how you can 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 and source control used interchangeably. I know I have, 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 have the ability to see what was changed, when it was changed and by whom.
Effectively, this is seeing the different versions of things, hence the term version control. And in this sense, these versions could be iterations of code, of conflict, documents, images, we're essentially tracking files here.
The files that we're tracking are the ones that make up the changes you've made to your software So in our case, specific customizations and enhancements you've made to your Salesforce org to fit your business and your way of working.
And it's important to stress that this doesn't just apply to code.
You can think of, the notion that Salesforce source control is for all folks that make changes to Salesforce, whether that's through declarative flow or code.
And for low code or pro code, it's still a valuable and important part of growing your Salesforce DevOps maturity.
Also wanna take a moment though to look at why Salesforce version controls are worthwhile practice.
I like to think that the most important word of version control here is control.
Version control allows us not just the visibility of how changes come through, but it allows us to better manage how the change is delivered.
It gives us the ability to decide on the pace of delivery or release cadence.
It also gives us the opportunity to start using some other important practices and techniques for DevOps peer review. The ability to roll back changes. And of course, it unlocks the power of automation, something that all of us in the Salesforce world love to use.
All of these things contribute to the control of your changes and provide you with a framework upon which to build your strategy.
So to actually start using version control, you need a tool called a version control system.
There are several systems out there, but the most popular choice is git. It's kind of the de facto standard used not only for Salesforce version control, but a huge swathe of software projects on every system platform imaginable.
In fact, these days, the terms git and version control are almost used interchangeably, and kit is definitely the version control that we're gonna be discussing today.
Now equally, there's a number of different providers that you can use to host your git, and you'll need to decide which one best suits your organization.
When you're choosing a provider, there is a few things that you need to consider.
If you use or plan to use automation, check that the provider has an easy integration with automation 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, then the ability to self host your repositories on premises may affect your decision.
And you'd also want to consider the user interface and how easy to use a tool is for your team. So make sure that you look at a range of options out there. I'm gonna run through a few of them for you now.
So with over seventy million users, GitHub is the most widely used provider in the world. GitHub offers automation capabilities through GitHub actions, which is great if you're looking to automate your testing or deployments with some of your own scripting.
Bit bucket is also a fantastic option, particularly if you're already using other Atlassian software like Jira, although they're not the only provider that has a Jira integration of course.
As your dev ops from Microsoft is another example of an entire suite of tightly integrated services.
And finally, GitLab is a popular option for the particularly more security conscious amongst us as it allows us to self host easily on our own servers.
Now, obviously, there's a lot more that I can say on each of these providers, but hopefully this is gonna give you a place to start that research.
So now that we've covered some of 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 will get used a lot when discussing version control with git.
So starting with a repository, this is the container for your source or your, metadata.
Git can have multiple repositories, it's kind of useful to think of it as your top level folder in which you store all of your source.
A branch is a copy of your source. It could be the primary copy, which is your your source of truth, or it could be a variation in which you're making your changes and your enhancements for a particular feature.
Merging is the act of reconciling and combining these different changes into your primary branch.
And finally, a plural request is a set of changes that you're proposing to merge into that main branch.
Now this itself is a powerful mechanism because it delivers on that promise earlier of control, review, and accountability.
So let's see if we can put some of these terms into context for you.
So a branching model or branching strategy will set the rules for how you use and manage those branches when developing features in version control.
It's important to choose a branching strategy that meets the delivery needs of your business, as well as suiting the type of team that you have.
Now which one of those you pick is going to depend on a few things such as team size. Larger teams have most likely a a larger variety of roles that need to interact with the source control And this will have an impact on which model is right for you.
Equally, your team's structure and its appetite for complexity or affect your decision.
Some of the more complex models will take a little longer for newer or less technical members of the team to get their heads around Also factoring your desired release cadence, there can be some business reasons that dictate a particular release cycle.
Do you want to release fast and often, or do you want to align to fixed sprint cycles or release dates And a branching strategy should allow you to manage those requirements.
Also consider your current workflow and see whether it's right for change. In many ways, switching to using version control can be an opportunity to reshape that workflow and optimize it.
Start with a branching strategy that probably more closely resembles your existing workflow and then look at how your environments are set up. For example, how many sandboxes, how many of those environments are gonna correspond to your different branches.
Now with git, everyone has a copy of the source code, and can contribute changes without depending on a central server.
But in practice, the most common way of working with git is to have your main branch as its primary branch. And from this, other branches are created as an exact copy before changes are added back into that branch.
Once the changes are ready, a pull request is created.
And I think an easy way to kind of get your head around what a pull request is is literally the phrase I'm requesting that you pull my changes from my branch into the main branch.
At this point, a teammate will usually review and approve your pull request and allow you to merge your changes back into that main branch and from there onwards towards production.
Now this model that I've described and that you can see on the screen here is called the feature branch model.
One of its biggest benefits is simplicity, and you might wanna choose this option if your team's fairly new to version control as a concept. Or if you have a lot of people that need to interact with your version control, for example.
Now in the next session, in this getting started with Git series in a couple of weeks time, we're gonna explore a few of the other branching models that we commonly see in the Salesforce world in a little more detail. As I said, this one's a good one to get started with.
So the other decision that you'll find yourself having to make is which metadata should you add to your version control? And there's a few different approaches to this. One approach is if you're using VS code for your development, take the project defaults that are created when you start a new project in that environment.
And one of the big advantages here is that folks can check out your repository and have a working project straight away. This is how Salesforce often structure their example code, but there's also a strong argument for keeping things as simple as possible with a slightly more minimalist approach.
I'd suggest definitely adds your most common standard and custom objects your profiles, your permission sets, but then think about your UI with your layout and lightning pages.
And start thinking about how your org is built. If you're a largely declarative focused team, then flows would probably be a good thing to add Whereas more code focused teams would want to add Apex code and lightning web components.
And this comes back to what we always try and say that there's no one way to do Salesforce DevOps, and you make decisions based on the way that you work. But hopefully, these are some baseline suggestions for you.
As your development needs grow or you have pieces of work that encompass other metadata types, then feel free to add them as you go along.
So now is the time to start looking at how that actually works, and I'm gonna be brave and do a live demo.
For the purposes of this demo, I'm gonna use Visual Studio Code, and the reason for this is that it's got a vast array of tools editing all types of files. So despite the name, it's not necessarily just about code.
It's integrated very well with git as well as your Salesforce org. And you shouldn't be put off by the fact that it does initially feel a little developer centric Working with metadata in this way is equally accessible to admins.
So with that said, let's start getting some of our bits and pieces in order.
Here we have a freshly opened visual studio code.
First thing I want to do is create a new project.
With Visual Studio Code's plugins, we can see there is a handy set of menu options for most of the tasks here. It's picking up a few that I've used recently, and we're gonna go with create project.
We are going to pick a standard project.
It's very rare I use any other, and I'm going to call it VC webinar, like so.
So at this point, we tell it where to pop it. At this point, it will create a skeleton project okay, a basic template for working with Salesforce in this environment.
So it's spinning away in the background, building out all the various tools and extensions that it needs, but one of the key things to notice is that it's built a skeleton folder structure here.
Most of these are for the purposes of Visual Studio doing its own work, but the important one is everything under force app. We expand that out a few layers.
We can see some common looking things here We have Apex classes.
We have page layouts, lightning web components, our various Salesforce objects, and so on. Again, I mentioned earlier that it'll build out a lot of the common, defaults, which good pieces of metadata to bring down. But at this point, it's just a skeleton that objects folder is empty.
So how do we connect back to our Salesforce org?
Well, there's a couple of ways that we can do this. I'd like to click down here where it says no default org set and change that org.
I'm going to authorize an org.
Now I'm clicking production here, but please don't be afraid. I'm not developing straight into production. Salesforce developer edition orgs are treated as production and go through login dot salesforce dot org dot dot com. Sorry.
So again, I'm going to give it a little alias so that we know which all we're connected to.
Now what that will do it'll prompt me to log in to Salesforce. This is the familiar user interface. So we don't have to jump into command lines or anything To owner us there, we just need to use standard Salesforce login page.
And it's a little small on there, but it is telling me I have successfully logged in and I can close that window.
We flip back to Visual Studio Code. We can see at the bottom here, it's successfully authorized against our org.
And the alias that we gave it is down here serves as a useful reminder of where we're connected.
But at this point, we still don't have our objects.
We need to go and fetch what we want to work on.
On the sidebar here, we have the org browser. Again, I like to make use of the tools that the extensions have provided us. I know some folks are a little daunted by the command line.
You still can do that with the command line. But the user interface is a lot more accessible.
So I'm gonna go and find our account object. Now this is an important strange little thing with Visual Studio Code and working with metadata in this way. For reasons that I don't necessarily know why, even our standard objects are in the custom objects folder.
I'm sure somebody at Salesforce can explain that at some point, but just little thing to keep in mind.
So I've found our account object. I'm gonna hit this little download link and just pull that whole thing down.
Should be nice and quick. There we go. So what we can see here is it's bought our account custom object is bought a web link and some list views and some custom fields all associated with that account object.
If we go back to our project at the top here, We can see we look in our objects now. We have our account object and its fields.
And its list views and so on. If we look at one of those, let's go with billing address fairly traditional.
So we can see here, as I explained earlier, everything is a file. It's an XML file, not the most human readable format, but reasonably, easy to follow. We can see that it is indeed a custom field.
We can see it's called billing address, and we can see that we'd have field history tracking switched off. Not a lot else to say about that field, but we can see that it's a file.
So at this point, we have the means of bringing our project and our metadata together.
Now we need to think about how we get that into git.
Again, through the power of visual studio code extensions, we have a source control tab Now there's a couple of options here. We can initialize our repository locally, or we can just jump through all the steps at the same time and publish to GitHub. I'm not going to do that yet because I want to explain a little more step by step what's happening here. So the first thing we're gonna do is initialize a brand new repository to store our changes.
Simple as that. We have initialized that. Now when we talk about initializing the repository, at this point, we're just working locally. This is our local copied. None of our fellow developers and admins can see this, and it's not really sort of backed up and and stored safely anywhere.
Top tip from someone that's done this little while might want to flip it over to the tree view just so that you can collapse all the stuff that doesn't actually relate to your project. Just keep that force app folder that we talked about earlier.
So the next step I want to do is add our account object.
So the first step in any of these processes is to stage our changes. And you can think of that as being very similar to when you're historically building change sets, hopefully, we're gonna move you away from change sets over time.
But when you're adding your metadata components and your changes into your change but you're not quite ready to upload it. That's the staging. We're basically just adding things to our chain set and building up our collection. I'm gonna hit the big plus button there, and we can see there already we have a set of staged changes. We have forty five files that make up our account object, We have eighteen that we haven't staged.
And if my maths works correctly, that matches our sixty three changes that have been detected.
Now the reason they detect them as changes is because we have a brand new repository with nothing in it and have a bunch of files with things in it. And that's the net difference.
So we're gonna focus on our stage changes.
The a means we've added it versus the u in here, which means it's untracked.
So we're gonna go ahead and commit that to our local git repository always recommend folks if things a meaningful commit message his tradition is initial commit is usually the, the first commit message, but over time you'd want to explain you know, kind of one liner, the nature of your change. So you could equally do added account My my typing is terrible when I'm when I'm doing a demo, but it's fine for this. And we're just gonna commit that.
And there we go. So we still have eighteen changes that we haven't committed, which is fine for our purposes.
Now at this point, Like I said, they're still local. We haven't moved them anywhere. Nobody can see them unless they have access to my laptop, which I'm not gonna give them. So we need to think about the next stage in that process, and that's where GitHub comes into the process.
So, again, earlier, we had that published to GitHub button. We don't have that now because I've started the process a little more manually but don't fear it's just as easy. We go back to our menu of commands on a Mac that's Apple Shift P on Windows its Control Shift P, probably control Shift P if you're using Linux too, but we have the publish to GitHub button there.
So we can publish to a public repository or a private repository The main difference is just the accessibility of that. For your own internal orgs, the majority of the time, I would expect that you folks are gonna be using a private repository. So we'll go ahead and do that. It's defaulting to the project name that we gave it earlier, which is absolutely fine with me.
It goes away and it does its thing. So you can see there it's successfully published that. We even get the option to go and have a look at that on GitHub. So let's do that now.
And you can see there we've created a brand new repository.
We have our main branch at the moment. Because we haven't really started adding features like we saw in our feature branch model, and we can see we've added account complete with my typo on the comments there. And we can see all the metadata that we've added into GitHub.
Now if we had a team that was sharing our GitHub account and people, you know, within our fellow developers, fellow admins, they could go and pull my latest changes now. They could push them into their sandboxes, and they could start working in in inheriting the benefits of the changes that we've made there.
And that in a nutshell is a basic workflow of using Visual Studio Code, Git and GitHub. So let's have a quick recap of what we've actually seen there.
So we've seen working with Visual Studio Code is reasonably painless They have icons. They have menu options. You don't have to get into that scary world of of typing commands in unless you really want to. Some folks do.
We've seen using git and GitHub as a means of storing those changes and having them captured and safeguarded locally in our repository and then having that repository replicated up to GitHub.
And we've seen how we get those, pieces of metadata changes, etcetera, from our Salesforce org intergate via Visual Studio Code.
Now, obviously, there's a lot more complexity to get beneath the surface, but I'm gonna cover off some of the terms and concepts, that are for later research or that will be covered in our subsequent session beginning of next month.
So we mentioned branching, which is where we're taking a copy of that main branch, making our little changes, and then folding those changes back in that main branch.
And that can be a little more complex than we've got time for in today's but it is definitely a useful feature across organizations of all sizes.
Now when you are merging those changes, back from your feature branches into Maine, you might run into something called merge conflicts, whereby you have multiple admins or developers that may have worked on the same piece of metadata in parallel, and you need to reconcile the two changes.
A simplified example of that could be two admins have worked on the same field. One has it as a field length of twenty and another has thirty and get this asking, well, which version of these is is the correct one? You know, is it last one in wins, or is there actually, you know, a little bit of review needed here? Now that ties in quite nicely to one of the the fundamental ideas of dev ops as a whole, which is collaboration and communication.
Okay. The easiest way to resolve a merge conflict like that is just to talk to your fellow admins. It'll tell you who made those changes because that's again one of the aspects of having visibility and tracking here. And you can just agree amongst yourselves, or you can go back to the original business requirement and work out which version actually is the the one that's going to make it into git.
That said, it's not gonna happen all the time. There's a lot of merge conflicts across various parts of Salesforce that can actually be resolved automatically.
And again, we can look at some merge conflicts in the next session.
And it's worth noting as well that both GitHub and Visual Studios get integration, they all have pretty good tools for managing that process.
So hopefully, I've given you some of the fundamentals that you need to get started with version control for your Salesforce changes.
And if you wanna learn more about version control, as well as our upcoming session, we've got our free learning platform, DevOps launchpad, whose t shirt I'm modeling today, where you can go into a lot more detail about version control, branching strategies, and a whole bunch of other DevOps topics. And if you want to go on there, you can either follow that link on the screen there or scan the QR code on the left.
And if you wanna see how Viasat plays into this picture and how you can deploy Salesforce metadata as part of a source driven workflow with the whole bunch more features than we've covered today, you can sign up for a free thirty day trial using the QR code on the right.
I shall leave those up there. Just a little moment while people take notes of those links or screenshot or whatever it is they need to do.
Okay.
So thanks once again for following along and listening, and I look forward to seeing folks on part two of this course, which is up on October the twelfth.
And with that, we do indeed have a few minutes left to pick up any questions that may have come in while I've been presenting.
Over to you, Amy. Thanks so much Rob. That was fantastic. There's some really practical advice in there. And, yeah, just to reiterate if we don't get around to answering your specific question today, as Rob said, we will be having part two, of our webinar session on Git for Salesforce on the twelfth of October. But don't panic, we'll be sending you more details, after our session today, so you don't have to write down the date or anything.
So, yeah, we'll quickly answer one question before we go. We just have enough time.
So, Rob. We've had a question come in.
How conversion control benefits Salesforce teams, and, how do the risk of implementing a version control system within your team outweigh. Do they outweigh the benefits?
Yeah. No. I I think so. I mean, you know, full disclaimer, yes, I I do work for gearset, and we are all about dev ops. But prior to joining, I was, a freelance developer consultant.
And so, you know, I I've worked with quite a few teams on the sort of the other side of the fence and Definitely, there's been, a lot of kind of late nights trying to get a deployment in and things not working. And then, oh, I've missed a piece of metadata, and, you know, who changed this and somebody's introduced a validation rule and hasn't told me about it. So there's a lot of that kind of work that can be eliminated just by having a clear processing. And when I talk about a clear process, it's not just the version control aspect. That's the technical element I would say that a lot of it is about getting that dev ops mindset around, okay, let's all kind of focus our efforts so that we have visibility We have communication, we have collaboration, version control is just a tool that enables a lot of that and allows you to have visibility what everyone's working on, what's changed so that there's no surprises.
As we'll see in kind of, you know, future sessions, once you start kinda getting into that workflow and then layering it with automation, hopefully you're not gonna be that developer or admin that's up till two AM trying to get that released definitely not on a Friday. You wanna start your weekends. Right? So in terms of risks and, you know, risks of implementing it versus not I would say there's actually more risk to not implementing DevOps in your, pipeline because, you know, you you don't have that visibility things can get lost, things can get overwritten.
And hopefully, you know, we can mitigate a lot of that by applying dev ops.
Awesome. Thanks so much, Rob. Yeah. I definitely agree. There's a lot of benefits to be had for emergency control.
Right. I think that's our time. So we really appreciate everyone joining us today. A big thank you to all who have attended We hope you found today's webinar super helpful, and we can't wait to see you hopefully in our upcoming session. So thanks once again, everyone, and take care.
Thanks, all. Take care.
