The Salesforce Admin's guide to git
Kevin Boyle on November 8th 2016
Git has taken over the world in the past few years and for many, terms like version control, git and GitHub have become synonyms. This post digs into the jargon and sheds light on how #AwesomeAdmins that don’t currently source control their work can start to realise the benefits.
Assuming no prior knowledge, let’s start by defining some terms:
Version control or source control provides a mechanism for tracking changes to files. For software projects, this almost always means representing your work as text files and tracking changes to those text files over time.
git is but one version control system among many such as Perforce, Subversion, and Mercurial. They all have pros and cons but the momentum behind git means that it’s a great option unless you explicitly have a reason for choosing another.
A git repository is what git uses to track changes to the items that you have under version control. This is the mechanism that teams use to share changes to their work pushing and pulling changes from a central repository.
GitHub is a service that makes it easier for software teams to collaborate. It provides a hosted git repository that everyone on the team can connect to and use to share changes. It also adds issue tracking, code review and project management to enable visibility into where work is happening. GitHub is built on top of git to deliver this collaboration platform but there are other git hosting options including GitLab, BitBucket and Git for TFS.
What benefits does source control provide?
Adopting source control as a team makes it easier to work together and share changes between Salesforce environments. Working together in teams has traditionally been a bit of a pain and it's been too easy to lose track of what changes need to be migrated or to step on each others toes.
Services like Gearset have made this much better by enabling easy comparison and deployment between Salesforce environments, but in spite of this it’s still more challenging with Salesforce than traditional software platforms to identify changes and track them over time. The big benefits that source control provide are:
- All changes are associated with a team member so you always know who did what
- All changes have an associated comment so you always know why it was changed
- All changes should have an associated assignee so they can be reviewed before being pushed into production
Adopting this process makes it very easy to go back in time and understand why things have been configured in a certain way and who knows most about each part of the system.
Why don’t Salesforce projects always use source control?
The reason that most Salesforce projects haven’t typically used source control is because getting your Salesforce configuration, code and metadata into text form so it can be version controlled has traditionally been a pain. And whilst getting configuration changes into source control might have been difficult, getting changes back out of source control and applied to your orgs was so difficult as to be almost impossible.
With SalesforceDX, Salesforce have started work that will make this process easier. For now, the focus of that project is more on Salesforce Coders than Salesforce Admins and requires command line tools that have a steep learning curve.
Git and Salesforce, the traditional way
Traditionally, using git and Salesforce together meant using some combintation of the
git command line tool and the Force.com Migration Tool. E.g.
// get my org in sync git pull -p // get my changes from my org into my local git ant retrieveUnpackaged // understand what has changed git status // add the files I want to commit git add objects/Account.object // Describe what my changes are git commit -m “This is the account object” // Share the changes with the rest of my team git push origin master
This kind of workflow isn’t exactly a simple way to share changes with your team, and for anyone unfamiliar with the command line tool there's a lot to learn. Luckily, the great thing about source control is that it doesn't matter how you get your changes into the system. Changes can be pushed via the command line, or a tool such as Gearset, and once they're in, the whole team can easily collaborate.
A simpler approach
Gearset is all about making it easy to understand the differences between Salesforce environments. To us, source control is just another source of metadata which can be compared and deployed. Gearset allows you to compare source controlled repositories with each other, compare an org with source control to push changes, or compare source control with your org to pull changes. All of this is done through the app, without the use of a command line tool.
Here is how you share changes with your team via source control, using Gearset
Make a change in the Salesforce org just as your normally would
In Gearset, select that org as the source of your comparison and a GitHub repository as the target
Compare Now. Gearset will now run all those git commands I showed earlier and grab the metadata from both source control and from your org.
When it finishes, Gearset doesn’t just show you how the text files are different, but shows you instead how the Salesforce components are different. In this screenshot we can see the profile changes that have been split apart.
Now I can select just the changes from my Salesforce org that I want to share with my team and leave the others behind
Provide a commit message so that people know what I’ve done
Press Deploy, and that's it. We’ve successfully shared our changes with the rest of the team via the source control system, without touching the command line
For your teammate to get this change, they can either use the command line to pull from source control or use Gearset to select the git repository as the source of the comparison and their salesforce org as the target.
Gearset makes it easy to collaborate with each other using the source control system regardless of how everyone on the team likes to work: be it coders using the command line tools or admins using a nice UI. Combining the traditionally separated developer and admin workflows provides a range of benefits, including faster project delivery, better visibility into what separate teams and working on, and reducing the chance of accidentally overwriting work.
Click here to get started using Gearset and experience git the easy way.