Continuous Integration (CI) has become an almost essential part of software development. Over the last few years, I’ve made it an effort to promote more CI within the Salesforce community. I often hear many teams want to add it to their projects but don’t have the time to do so. If you were to start a new Java or C# project, it would almost be unheard of not to set up version control and CI. Why is it that so many Salesforce projects aren’t given the best possible opportunity to succeed?
Benefits of Continuous Integration
These are some of the benefits you are missing out on by not implementing CI early in your process:
Version Control
Because CI requires Version Control you will automatically gain the benefits of Version Control. For example, backing up your code at various stages of development; being able to roll back an individual change; better code reviews; and much more.
Meta Data Protection
When working in a multi-developer project where each developer is working out of their own sandbox or org, it is common for a developer to accidentally omit some key metadata when they commit their changes. CI will automatically catch this scenario immediately after submitting their changes and get a notification of their mistake, giving them a chance to correct their mistake before the change can impact and block other developers.
Error Catching
CI will automatically catch syntax and other compiler errors introduced as a result of a “quick” change that wasn’t properly tested.
Ensure Minimum Code Coverage Requirements
You can use CI to enforce minimum code coverage requirements during development, not just when you go to deploy to production.
Automatic Unit Tests
If your organization has properly written unit tests, CI can automatically run unit tests after each commit. It can prevent any changes that cause test failures to merge into common branches and affect other developers. Adopting a Test-Driven development process would dramatically help improve upon this.
Automatic Deployment
Deployment to production can be fully automated in most cases and doesn’t require using Change Sets. Deployments also become more predictable with far fewer issues arising during the deployment.
Automatic Regression Tests
More advanced CI implementations can significantly reduce regression testing by running automated regression tests that go above and beyond Salesforce’s unit tests. For example, APIs and UI testing can be performed as part of the CI build process.
More Continuous Integration Benefits
As you can probably determine, these benefits have profound time savings over the alternative manual options. There is a wealth of information on the benefits of CI in general on the web, for instance:
- The Benefits of Continuous Integration (codeship.com)
- Benefits of Continuous Integration (codeproject.com)
When and When Not to Use Continuous Integration
It is easy to see which projects would benefit from CI, but where do you draw the line? If your project is all declarative with no APEX classes, Visualforce or Lightning components then you wouldn’t want to use CI or Version Control. You probably wouldn’t need CI for a short project that will never evolve after you complete it.
Once you get into evolving projects that will continually be enhanced time after time for the foreseeable future, then you’re getting into the area where you could benefit from CI. This becomes even more evident when different developers will be used over the lifecycle of your Salesforce implementation. In many cases, CI may be better planned out as part of Salesforce as a whole, as opposed to just for an individual project.
How to Implement Continuous Integration with Salesforce
There is a wealth of information on configuring Continuous Integration for Salesforce on the Salesforce Developer site. Essentially you just need to configure a Version Control system, something every project of every size should utilize anyway, and a build server. I’ve configured several Jenkins and Atlassian CI solutions, and both of them work very well with Salesforce. I strongly recommend the Atlassian solution as it is a seamless integration with more out of the box features. If cost is a factor, then Jenkins and GitHub solution is very economical for the small projects.
Atlassian’s Bitbucket product has added a Pipelines feature that has integrated what they call, Continuous Delivery, directly into the version control sub-system. This feature allows for custom AWS Docker Containers which can be used as the build process instead of implementing a dedicated build server like Jenkins or Bamboo. GitHub has also been designing and has add-ons that also bring build server like features into the Version Control system. I personally haven’t used these for Salesforce Continuous Integration but the Bitbucket approach should theoretically work.
Configuring CI for Salesforce Best Practices
After you establish your CI infrastructure, you need to configure it for best practices. Salesforce also has some good information on this topic as well:
- Best Practices: Continuous Integration Techniques (Salesforce Technical Library)
This page also has some good information on using Version Control with Salesforce:
- Using Version Control Unit (trailhead.salesforce.com)
Once you have implemented your CI solution, you can use it on all of your Salesforce projects. It is just a matter of configuring new Version Control repositories and configuring your build server. You will also find that CI solutions fit well into Agile development practices.
I hope I’ve been able to encourage some of you to implement Continuous Integration with your Salesforce projects. Once you do, I know you, your developers and your customers will be glad you did.
Driving Innovation with Continuous Integration
If you’re seeking a partner for support on your next continuous integration project in your Salesforce solution, contact our team to learn more about our experience. We’ve helped hundreds of organizations boost their capabilities over the last decade, and we’d love to find out if we’d be a good fit for your goals too.