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 91导航
- 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 a little bit further. So as Amy says, I am indeed Rob Cowell, one of the DevOps advocates here at 91导航. And that role involves working with you folks, wider Salesforce community, to help guide you on your DevOps 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 wanna 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 align 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 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 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 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 config, 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. I also want to take a moment though, to look at why Salesforce version control is a 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 Git is definitely the version control that we're going to be discussing today. Now, 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 70 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. Bitbucket 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.
Azure DevOps 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 among 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, but 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 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 pull 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 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 will 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 ripe 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 going to 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 team mate will usually review and approve your pull request and allow you to merge your changes back into that main branch and from there onward toward production. Now, the 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 going to explore a few of the other branching models that we commonly see in the Salesforce world in a little more detail. But 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 structures 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 add your most common standard and custom objects, your profiles, your permission sets, but then think about your UI with your layouts 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's the time to start looking at how that actually works. And I'm going to be brave and do a live demo.
For the purposes of this demo, I'm going to use Visual Studio Code. And the reason for this is that it's got a vast array of tools for 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 going to 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 are 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 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.salesforce.org.com, sorry. So again, I'm going to give it a little alias so that we know which org we're connected to. Now, what that will do, it'll prompt me to log into Salesforce.
This is the familiar user interface, so we don't have to jump into command lines or anything too onerous 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 a little thing to keep in mind.
So I've found our account object. I'm going to 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 brought our account custom object. It's brought 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 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 going to 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 copy. None of our fellow developers and admins can see this and it's not really sort of backed up and stored safely anywhere. Top tip from someone that's done this a 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 set, but you're not quite ready to upload it. That's the staging. We're basically just adding things to our change set and building up our collection. So I'm going hit the big plus button there and we can see there already, we have a set of staged changes.
We have 45 files that make up our account object. We have 18 that we haven't staged. And if my maths works correctly, that matches our 63 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 we 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 give things a meaningful commit message. The tradition is initial commit is usually the first commit message, but over time you'd want to explain in a kind of one liner the nature of your change. So you could equally do added account.
My typing is terrible when I'm doing a demo, but it's fine for this. And we're just going to commit that. And there we go. So we still have 18 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 going to 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 publish 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. If we go back to our menu of commands on a Mac that's Apple plus Shift plus P on Windows, it's Control plus Shift plus P, probably Control plus Shift plus 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. 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 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 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 and 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 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 into Git via Visual Studio Code. Now, obviously there's a lot more complexity to Git beneath the surface, but I'm going to 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 into that main branch.
And that can be a little more complex than we've got time for in today's session, 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 main, 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 20 and another has 30.
And Git is asking, well, which version of these is the correct one? Is it last one in wins or is there actually a little bit of review needed here? Now that ties in quite nicely to one of the fundamental ideas of DevOps 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 among yourselves or you can go back to the original business requirement and work out which version actually is the one that's going to make it into Git. That said, it's not going to 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 Studio's Git 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 wanna 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 91导航 plays into this picture and how you can deploy Salesforce metadata as part of a source driven workflow with a whole bunch more features than we've covered today, you can sign up for a free 30-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 12. 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. Some really practical advice in there. And yeah, just to reiterate, if we don't get round 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. Rob, we've had a question come in how can version control benefit Salesforce teams and how do the risks of implementing a version control system within your team outweigh? Do they outweigh the benefits? Yeah, I think so.
I mean, you know, disclaimer, yes, I do work for 91导航 and we are all about DevOps. But prior to joining, I was a freelance developer consultant. And so, you know, 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 has 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 process. 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 DevOps 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 of what everyone's working on, what's changed so that there's no surprises. As we'll see in kind of future sessions, once you start kind of getting into that workflow and then layering it with automation, hopefully you're not going to be that developer or admin that's up till 2 AM trying to get that release done and definitely not on a Friday.
You want to start your weekends, right? So in terms of risks 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 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 DevOps.
Awesome, thanks so much Rob. Yeah, I definitely agree. There's a lot of benefits to be had for version 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 and 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.
