March 6, 2019
8 Principles of Continuous Integration

8 Principles of Salesforce Continuous Integration

Why is building applications on Salesforce so easy and yet continuous integration so difficult?

What if you could make Salesforce change management as simple as a few clicks instead of needing to learn complex technologies like Git? In this post, I’m going to walk you through the 8 principles of Salesforce continuous integration and how Flosum, the only 100% native, Application Life-cycle Management system makes life easy on Salesforce

What is Continuous Integration?

Continuous integration allows for extremely fast and flexible development and release of code. It is also applicable to migration of metadata. It involves short-term development, meaning that Salesforce product requirements can be adjusted without the developers having to start from scratch. In continuous integration, developers pull the latest code from a central code repository and work on completely separate sections of code at the same time — committing and building regularly.

This constant committing and automated building is the key to continuous integration as it prevents disastrous integration late in the cycle between developers working on the same project. This automation is key to making continuous integration easier and faster than the normal development cycle. Continuous and automatic testing for inconsistencies occurs throughout the process, alerting developers immediately when an inconsistency or error is found within their code. This allows for constant small adjustments to prevent code inconsistencies rather than the major time-consuming reworking of code at a later stage.

8 Principles of Continuous Integration

  1. Ensure there is a central code repository: As the entire concept of continuous integration involves making sure all code works together properly, branching should be kept to a minimum, and any necessary branches should be merged back into the main code baseline as soon as possible.
  2. Automate and test the build: Every commit of code should be built and tested automatically. Continuous integration tools in Salesforce constantly check the repository for changes and, when a change is detected, they perform a build against a Salesforce org to test it for errors.
  3. Everyone commits to the central code repository frequently: The longer a developer holds onto code without building and testing it, the more likely it is to be inconsistent with the other changes that have been made in the code repository. Constant commits are fundamental to the success of continuous integration.
  4. Build fast, catch errors early: Notify developers as soon as possible if there is an issue with integration. To speed up builds, a separate machine may be designated for build purposes so that it does not impact the development pace of any developer. For Force.com, the majority of the compiling work happens in the cloud, so this build machine does not have to be high-powered or expensive.
  5. Use a good testing environment: The testing environment (sandbox) should be as similar as possible to the eventual production environment — if not a direct copy — with a testing environment that has data as complete as will be encountered in production. This ensures the usefulness of the testing and keeps expectations consistent through the production stage.
  6. Allow global access to builds. Testers should have easy and constant access to builds so that any failure to meet product requirements can be found as soon as possible. Early detection will lessen the danger of having to rework everything later.
  7. Automate deployment & ensure transparency: Deployment into a sandbox should be automated. Everyone should have access to, or be automatically notified of, the results of the latest build and deployment so that they can see whose code broke the build and why, and rework code accordingly. History of the builds should also be accessible in addition to the details of each build.
  8. Test-Driven Development: One of the most common coding practices central to the speed and flexibility of continuous integration is Test-Driven Development (TDD). Like continuous integration, TDD revolves around very short coding cycles, as well as constantly referring back to a central goal. It forces developers to focus on exactly what they want their code to do before they even begin coding. The idea is that developers begin by writing an automated test, which their code initially fails.

From a Salesforce perspective, this requires developers to clearly understand and define exactly what type of Salesforce metadata they would like to write before they even begin writing code. Once they write code that passes the initial test in as simple a way as possible, they must then integrate it into the existing code. This allows for simpler code and more efficiency in avoiding inconsistencies because integration into the existing code occurs after the developer has already found a solution to the initial problem so that the developer can focus on proper integration without worrying about solving the task at hand. Test-driven development allows developers to catch bugs early so that they can fix issues as they arise without losing too much time to rewrite huge chunks of code.

How does Flosum help with Salesforce Continuous Integration?

Flosum…

  1. Automates dynamic creation of package.xml at run-time during deployment.
    Developers just need to pick the right Salesforce metadata components and Flosum creates the package.xml, including the appropriate folder structure.
  2. Automates deployment of metadata.
    If the deployment of the metadata succeeds, all the developers are notified of the new file changes so that they can pull the latest files from the source control.
  3. Monitors deployment status.
    If the deployment fails, Flosum alerts the developer so that they can fix the code immediately, ensuring quick and early recovery from inconsistencies.
  4. Automatic rollbacks.
    Flosum automatically rolls back to a previously known stable state if the deployment fails.
  5. Maintains code repository.
    Flosum maintains every copy of the code that developers want to commit. The latest copy is sent to build for continuous integration.
  6. Automates builds.
    Every code change can be sent for a build to confirm seamless integration.
  7. Provides detailed feedback on why the build failed.
    For every failure, developers receive a specific error message from the Salesforce metadata API, making it easy to identify and fix the problem.
  8. Flosum is built specifically for Salesforce. Using Salesforce metadata APIs is a nuanced process. Flosum handles all of them transparently so that you don’t have to worry about adjusting the metadata or tooling the API.

Native Release Management and Continuous Integration for Salesforce

Flosum is the only 100% native app for release management built specifically for Salesforce. It allows users to seamlessly orchestrate changes across their development ecosystem, eliminating pain points experienced when using traditional dev tools. Ready to take your Salesforce release management to the next level?

Next Steps