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.
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:
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:
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
- 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:
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
I think WS is the only IDE right now which allows you to fully use GIT without any jenkins/CI help. We do this since beginning of august in our team here. Since the "build projects from sources" functionality it is actually really fun to work with GIT.
Here at our company we have split the metadata into two parts:
1) Code, that is maintained in a GitHUB repo "manually" by all developers (and very standard as everyone would use GIT)
2) All other metadata that is created in Salesforce like objects, page layouts, custom setting, etc. We have a separate repo for this that is maintained by a jenkins (no user has really access to this repo). the jenkins checks regularly the integration sandbox for changes on this metadata and then commit/adds them to GIT and also deploys them to all sandboxes + prod.
With that setup we have everything in GIT but don't fiddle around with pulling metadata from SF just for the sake of pushing it back to GIT (and ... let's be fair, admins hate GIT ;)).
Also, we take a different route for the .gitignore. Since everyone uses the WS a bit different we made a "positive" list for the gitignorefile:
And then inside the src folder we have another .gitignore
With that everyone can have what they want in their WS. Works really good for us :)
Thank you a lot for such a great feedback!
We are happy to hear that The Welkin Suite IDE can make somebody's life easier and this is interesting for you to work using TWS.
Also, we appreciate greatly sharing your experience and examples - this can be useful for other users, and, of course, this is definitely useful for us to see users' practices.
Such feedback really inspires our team to make The Welkin Suite the best IDE for Salesforce :)
Firstly i thanks for sharing an information with us. Really a great and well explained post.
Thank you for your comment - we really appreciate it and we are happy to hear that you found it useful and interesting!
If you have any questions or suggestions for further posts, feel free to share them with us and our team will work on this.
Have a nice day!
As someone starting out in Salesforce (I'm from the .NET and Azure world) and trying to bring some order to an existing Salesforce chaos with no source control or managed CI process, how do I get the existing org into source control to begin with?
Thank you for your question.
You can start from this great article from Gearset Team: https://gearset.com/assets/version-control-for-salesforce-whitepaper.pdf
If you have any questions, just let me know I will be happy to answer.