Salesforce and Git: Development Process

There is a bunch of posts about different techniques in development with Java, Ruby on Rails, and other popular languages & technologies, but not for Salesforce. I don’t even mention a standard process without a version control system usage and deployments via changesets. Does anybody like to waste time clicking and adding components to change sets?

Set up salesforce development process

I see 2 reasons of why it is so hard to find any useful posts about development processes with Salesforce:

• Salesforce – is a cloud-based platform. Developers make their changes directly in the cloud. Just imagine 2 Ruby developers making their changes at the same time on the same server! This makes standard development workflows with Git inappropriate for Salesforce.
• From my experience: it is so few really strong development teams in this area. It is so few open source libraries and frameworks. 50 % of the Salesforce development companies I know even don’t use Git.

Ok, let’s see how we can set up a good Salesforce development process with Git, Continuous Integration and comfortable deployment.

Salesforce and Git – must use

If your code is not on Git – it is nowhere. But how to use Git branches when you work in the same sandbox with other developers? What if 2 developers will make a change in the same class? The answer is pretty obvious: every developer should have own sandbox. It will allow every developer to make changes independently and create single task-related file versions.

There is a number of hints in Git configuration for Salesforce:

• Always set line endings to LF. Anyway, Salesforce will convert your line endings to LF and you’ll receive the changes after updated your project from a server.
• Configure .gitignore, here is my example for Sublime Mavens Mate.

There is a cool post about typical Salesforce + Git development process by Patrick Connelly and I will not repeat the things here.

Here you can find a successful branching model for Git. I think it is applicable to any development process. I have used it for 4 years. The following picture describes that model:

Ok, with separate sandboxes we can use Git and work in feature branches, push them to a remote repository and make pull requests. We can also pull changes from the remote and merge/rebase with yours. But how to deploy pulled changes to a server? To start making any changes in a code you need to sync your local version with a sandbox.

Automate deployment to Salesforce

Let’s assume you are working on your feature and pulled some changes from a remote repository, rebased with yours and want to deploy the result to your sandbox. You can use your IDE’s capabilities for that, but it is not comfortable at all. There are a number of tools which work via Salesforce Tooling API and useful for bulk deployments. I tried Solenopsis and Apache Ant (there is a special library adapted for Salesforce deployments).

Ant works great for me. It is easy to use and highly customizable. But before Ant usage, you need to understand what is package.xml and how it works. I plan to write a separate post about package.xml and Tooling API. Let’s review the steps of how to deploy your metadata with Ant:

• Install JDK
• Install Apache Ant
• Log in to Salesforce on your deployment machine. From Setup, enter Tools in the Quick Find box, then select Tools, then click Force.com Migration Tool.
• Take ant-salesforce.jar lib and copy and paste this file to your root project directory containing src folder.
• Configure build.xml and build.properties files or use mine from here. Do not forget to fill build.properties config with your credentials.

Now you are ready to deploy the code from your local src folder to the sandbox. If you use my build.xml you have 4 Ant commands available:

• validateDeploy — emulate deploy with tests run
• deployWithTestsRun — deploy your code from src directory in accordance with package.xml and run all of the unit tests
• deployIgnoreTests — deploy the code without tests run (the quickest operation)
• undeploy — remove the components listed in undeploy/destructiveChanges.xml from a server.

Usually, I run ant deployIgnoreTests to sync local version with a server. You can use the same procedure for deployments to Production and other environments. Git + Ant usage allows you to make deployments much faster and deploy specific versions of code, perform rollbacks which are not supported by Salesforce.

Set up auto deployment from Git branches

Usually, we have multiple environments in Salesforce, for example:

• sandboxes for developers
• sandbox for QA
• production environment

In the previous chapter, I described how you can deploy your local code to a server, that works perfectly when you work with your development sandbox. But let’s imagine how you deploy a release to QA: you need to set up a project in your IDE linked to QA instance. Then check out the right code version in Git and run Ant.

And what if you have multiple QA environments? I’m too lazy for that!

It is pretty easy to automate deployments to Salesforce environments directly from Git branches. For every environment create a separate branch in Git (master branch usually linked to the production environment). Set up webhooks to trigger deployments after a push to specific branches. I used Jenkins to perform deployments.

In Jenkins create separate projects for every environment. While setting up the project add the following configuration:

• Checkout code from Git and provide repository details
• Trigger build remotely
• As a build step set Ant target execution. Provide the path to your build.xml
• Post build action is a usual email notification

Now you have all deployment procedures automated directly from Git. After the Jenkins configuration, do not forget to set up webhooks to trigger deployments in Jenkins.

Congrats, now any deployment will take 5 seconds and will be performed by a simple Git push into a right branch!

Setup Salesforce Continuous Integration

When you have 500 unit tests in your environment, the total test execution time can be more than 10 minutes. We don’t want to spend so much time. However, we must be aware of failing tests before we try to deploy them to production. What can we do about this? I see 2 options here depending on your development team size.

• If your project is pretty big and there are 2 and more developers on the team. When is the best time to know if there are failing tests? I think when a pull request causing that issue created. Great! From the previous paragraph, you know how to configure Jenkins to trigger deployments after a change pushed to a specific branch. All you need is to create a separate sandbox for Continuous Integration purposes. Then, set up a Git webhook to trigger a deploy with tests run after a pull request created. Also, don’t forget to include all of the developers to Jenkins notification recipients. Congrats, now you are aware if anyone made a change which causes failing unit tests. You don’t need to run them manually all the time!
• If you work alone and your project is pretty small. I think you don’t create pull requests and work in a single sandbox. You don’t want to set up Jenkins because it requires time. There is a solution here: you can use my CI tool for Salesforce. This tool is written in Apex, so all you need is to deploy and configure it. This tool is still in progress, but already able to run unit tests automatically by schedule and send simple notifications about test failures.

Use code auto-formatting tools

I didn’t find anything like style-checker for Java or Rubocop for Ruby developed for Salesforce. So it is pretty hard for a large team to write Apex / Visualforce in the same style. The best solution I found here: use auto-formatting tools. I use Sublime Mavens Mate currently and found the following plugins:

• Apex auto-formatting plugin
• Visualforce autocomplete
• JS/CSS/Visualforce auto-formatting plugin. It requires some configuration, feel free to use my config.

Bottom Line

I hope somebody will find this post useful and you learned how to work with Salesforce and Git. Please feel free to tweet about it and share with your сolleagues. It will show me that there are people interested in my experience, and I will write new posts about Salesforce.

Pavel Demeshchik

CEO at datarockets