3 ways to store Salesforce projects in Git with The Welkin Suite

We see the Salesforce platform constantly evolving, and along with that, we see the development processes transforming as well. But do we only see this evolution around those what I would call buzzwords of Salesforce, like moving from Visualforce to Lightning, Salesforce DX, or even about the progression away from having to use code at all? I would say no, and I think a great example of this is how the development and development flows have matured around Apex. Just 5 years ago using GIT with Apex projects was a very scare world in Salesforce, and now it is not scary at all as the tools, developers, and workflows have grown.

So let’s talk today a bit about the different options you and your team have in The Welkin Suite to store your sources and metadata in Git. I am not going to mention anything about flows and best practices, as each project and team is unique in its way of using Git, so we’ll just highlight what you can do in the IDE to make your Git journey easier and more comfortable.

What is the problem?

Depending on the processes in your team, the size of your team, the details of your project, and maybe even the phase the moon was in when your team might have made (or is going to make), you are going to have to make some  decisions about your Git repository standards. For example:

• you might follow Atlassian's proposed Git flow and create forks for each sandbox/organization while using branches for logical separation of your tasks.
• you migint choose to use branches within one repository for different sandboxes/organizations. 
• you might use your own branching strategy or mix different approaches within one project

Or maybe you will take a different angle, like:

• you might keep your repository as a full snapshot of your organization with all it's 100+ metadata types - to be (theoretically) able to deploy it to any random sandbox when needed
• you might keep only code-related metadata in your project, as Administrators refused to use Git to commit their configuration changes
• you might keep just some certain parts of metadata, thus, often, manually playing with package.xml for some kind of Ant task that retrieves only your metadata that is needed
• ... and countless other options

And one more dimension of tough decisions that could be made:

• your repository can be crafted specifically to work with your very own scripts for Jenkins / Bamboo / Travis CI or any other CI of your choice
• your repository might contain some legacy (or why legacy - actively used ones as well) custom-made Ant jobs and scripts with a lot of complex manipulations (e.g. SalesforceDX-like stuff but made with Ant and without DX  )
• you might have traces of all IDE's and tools used by your team, in the past and at the moment

I'll stop here to not overwhelm you.

To be honest with you, it doesn't matter what your standards are - the IDE should allow you to start working with your Git repo without any painful process of "refactoring" your Git strategy (we all know that it rarely happens), while at the same time it should provide you with options that you might use to build a "better life" for your team and overall development flow, and it does.

And you will have to excuse me, I don't have enough time to talk about how TWS allows your administrators to work side-by-side with developers with the same flow, tools, and without losing some of their comfort (however, it's very true the IDE can make that happen), and I also won't mention because of time the other cool things that The Welkin Suite allows you to do. I will just be covering what you can do in the IDE to work with any Git strategy that you have (or going to build) and, particularly - what can be stored in a Git repo, and how to work with such repository in the IDE.

Sources only

The most obvious and most used approach by teams that have started using Git a while back is just to store your Salesforce sources and metadata in a repository. In this case, you just have your src folder, with the metadata in the way it came from Salesforce, plus a package.xml file to "wrap" it. Your repository in such case looks like on the screenshot below - sweet & clean. Yes, of course, there are a lot of options on what exactly should be inside that 'src' folder - code, metadata, profiles, etc.

This approach was very common in the times when we had nothing else meaningful to add to our sources because they were the only interesting part of our project, so having them in a repository was completely sufficient. However, now we have some smarter tools, a bit more advanced Salesforce itself, and many more things to deal with while developing, so there's certainly some need of "extra sugar" on top of your sources. This is why when you start a new project in The Welkin Suite - it creates additional files and folders to store your test results cache, the built-in local history, your per-project UI settings and customizations, project structure and a lot of other helpful information, so let's try to handle this scenario.

First of all, when you have this type of repository you can follow the steps described in our blog post How to create The Welkin Suite project from your sources in Git to see all the detailed steps on how to add that "extra sugar" to your sources and how to work with them with all the benefits from IDE. Additionally, as a good developer, you don't want to add any "garbage" to your extremely clean repository (or you're just a ninja who doesn't want to leave any pieces of evidence that you're using an advanced IDE rather than Developer Console ), so you'll need to ensure that any misc data that would be created by The Welkin Suite won't get to the repository. As usual in this cases when using Git - .gitignore file is the solution. Just add to your .gitignore file the following lines, and you won't see any footprints of the IDE in your repository:

*.credprops
*.rmprops
*.sfproj
*.sfprojsettings
*.sfsln
*.sfuo
/.cache
/.localHistory
/AnonymousApex
/Logs
/resource-bundles
/Soql
/src/package.xml.bac
debug.log

And that's it. Plus the best thing is that you'll have everything you need locally, and you'll be able to work with your The Welkin Suite project that just simply 'wraps' your sources from a repository. Isn't that cool?

Sources and project data

If you'll go one step further and you share some details of The Welkin Suite project with your teammates using TWS - all of you will benefit, and I should also mention that if you go down this rode this will not block anyone on your team from using any other IDE or tool, as nothing won't be changed in the way how metadata is stored. It is just some extra information will be included into the repository. So what can you share in the repository without losing any kind of freedom in terms of your approach to using Salesforce organizations and/or branching strategy? Well for example:

• Project structure - it's a great way to organize large projects in a convenient way. You can read more about this here;
• Anonymous Apex files - yup, we provide you an option to store your Anonymous Apex as separate files, so you can share them with the team;
• SOQL files - the same as for Anonymous Apex;
• Pre-configured PMD or CodeScan ruleset - as you can run PMD directly from the IDE (CodeScan is as well supported) it's worth agreeing on a certain ruleset, and including it as a part of your project;

How does this look to you? In my opinion these things are worth sharing with your team, so all of you will benefit from some of our extra options in the IDE. And if you'd decide to go this way, simply modify your .gitignore in the following way:

*.credprops
*.rmprops
*.sfprojsettings
*.sfsln
*.sfuo
/.cache
/.localHistory
/Logs
/resource-bundles
/src/package.xml.bac
debug.log

Afterward, your Git repository will look this way:

Sources, project data, and organization details

What else might you want to include into the repository, compared to the previous approach? Honestly, the only other common and very important component of The Welkin Suite project that we've excluded from the repository till this moment is your organization's connection.

The Welkin Suite is built in such a way that it allows you to connect your project to any organization whenever you want, so you can have different sandboxes connected to your project in different branches. Or each team member can even have his own sandbox to work with, safely commit to the Git repository (without any manual actions), and be sure that he won't commit his password, for example. What is stored in the 'organization details':

• Organization name
• Username
• Hash sum of each file in the project at the moment when that file was retrieved from Salesforce
• Last Modified Date of each file in the project at the moment when that file was retrieved from Salesforce
• Salesforce ID of each file in the project

And please don't worry - your password or OAuth token is not stored in the project folder at all. They are stored in a secure storage within your OS, so you do not have any way to accidentally commit your password to a Git repository (we all have seen millions of secret keys, password and other sensitive data in public repositories in GitHub and learned).

However, even if you'd want to include some organization details to your repository, there are still some items that you'd like to exclude from Git repository, so again some more .gitignore magic:

*.sfprojsettings
*.sfsln
*.sfuo
/.cache
/.localHistory
/Logs
/resource-bundles
/src/package.xml.bac
debug.log

Final 2 cents

As promised - this was a very short overview of some of the not-obvious tricks using The Welkin Suite with Git and how you can manage it. If you have any questions about this topic - please feel free to comment or email us and we will be happy to chat. And if you have suggestions or would like us to highlight some other areas - please feel free to let us know and we will make sure that one of the next articles will be helpful for you.

P.S.: Git is first of all your safety net, so don't be afraid of it. However if it's not the best time for you to implement Git in your development flow - take a look at the built-in Local History that does it for you