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?
I see 2 reasons of why it is so hard to find any useful posts about development processes with Salesforce:
Ok, let’s see how we can set up a good Salesforce development process with Git, Continuous Integration and comfortable deployment.
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:
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.
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:
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:
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.
Usually, we have multiple environments in Salesforce, for example:
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:
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!
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.
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:
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.
Check out our newsletter