Faster Delivery with Continuous Integration for Salesforce

Beat your competition with faster software delivery

Salesforce continuous integration builds and tests your software for instant launches. Agile techniques make your software development faster. But your DevOps (Development Operations) team still struggles to launch. You need live software to grow your competitive sales advantage.

Here are the common questions about Salesforce continuous integration. The answers mix my expertise as a Salesforce MVP with contributions from Michael Havrilla, Kevin Boyle, and Girish Jashnani.

What is continuous integration and why is it valuable to businesses?

In a typical software project, you might develop new features for weeks or months before you integrate and test them as a whole. Problems become big and expensive to fix, and delays cost you lost sales and customers.

Continuous integration automatically builds and tests your software early and often to prevent errors from delaying your final deployment to production. It delivers a faster return on investment and extends a competitive advantage to grow your business.

How do agile and continuous integration work together?

Agile and continuous integration both drive a shorter cycle time with greater transparency. By automating your build and tests, problems are found and corrected early. You gain greater confidence in your final delivery timeline and quality.

As you fully adopt continuous integration, your team will spend less time on manual builds and testing. That means more features delivered to your customers for less time and money.

How do you setup Salesforce continuous integration?

Salesforce has both benefits and constraints for continuous integration. Here’s the overall setup:

  1. Environment provisioning is simpler in the cloud, but each environment must be manually created. For continuous integration, create one environment to be refreshed with each new build.
  2. Source control drives the continuous integration process. Developers check-in completed code and administrators commit new configuration-based features. From this auditable history in Git, you know exactly which changes make or break a new build.
  3. Build tooling in Ant simulates deploying changes to your final production environment. While most changes can be automated, a manual deployment log should document any special steps.
  4. Test execution makes sure that both new and old features still function as designed, and alerts the team early to any failures in the internal logic of the system. A final set of manual Quality Assurance scripts tests external integrations and user interfaces.

That’s a big effort; what are alternatives for smaller projects?

Smaller projects or consulting engagements might only have one or two release cycles. Their largest concern is to make sure all functionality is working, so running all tests regularly is a good health check. Automated Testing for does that natively within a single Salesforce environment, and emails the results to the entire global team of project managers and developers. As a free tool, it’s become a standard for each project we do at Alvorden.

How would you handle a big AppExchange app like FinancialForce or the core Salesforce platform?

This is where Salesforce continuous integration really has benefit: a large team of developers building quickly while supporting a broad customer base already in production. AppExchange testing involves an even greater variety of Salesforce environments; Michael Elson has a great recipe to clone them for testing.

The core Salesforce platform is even more interesting: 3 major releases each year to over 100,000 live customers running their own custom code. The real reason Salesforce requires 75% test coverage is because Josh Kaplan and friends run those tests as a brute force “hammer” against their own new versions. A recent job post at Salesforce engineering sums up their challenge:

To accomplish this goal we need to configure the application to run all 60 million customer written tests, with both the current version and imminently released version. We store the results of both test runs so they can be contrasted. Did you catch that, we need to run all 60 million tests twice, then compare each and every result for differences?

Are there any generic packaged solutions?

CumulusCI is the process used by the Salesforce Foundation for the Cumulus project, the next generation of the Non-Profit Starter Pack (NPSP). GearSet and Flosum are commercial release management tools developing native Salesforce continuous integration.

What’s your parting advice to Salesforce architects, entrepreneurs, and customers?

Invest in a Salesforce roadmap that covers its overall lifecycle. Answer these 3 questions:

  1. How complex is it?
  2. How often will you release?
  3. How critical is comprehensive testing?

Based on those answers, you can choose from my 3 recommended solutions:

  1. Simple Automated Testing for
  2. Commercial Salesforce continuous integration apps
  3. Custom build system based on the recipes here

How will you deliver faster with Salesforce continuous integration?


About the author