Salesforce has become an integral part of the business infrastructure for companies of all sizes, across countless industries. Part of the appeal is Salesforce’s ability to deliver a wealth of out-of-the-box features for generic business purposes. Of course, companies inevitably discover that they want something unique. Universal, one-size-fits-all solutions don’t last long. Everyone is different, and everyone seeks an offering tailored to their objectives. In this aspect, Salesforce shines brightly by offering ways for users to customize the product—without the need for developers. But what about companies with more complex demands? Why have they embraced Salesforce? Because Salesforce made its technology available to a sprawling community of developers. They have become instrumental to enterprises that require custom development work that can become complicated. There’s a world of difference between changing the name on a label and writing a custom interface or designing a business process that automates invoice creation and distribution while calculating overdue interest. The larger the customer, the more complex the need. Having a team of two to three developers is common. And this brings us to a term that many Salesforce users have heard and wondered about: Continuous Integration (CI). What is CI, why is it essential, and how does it work?

Continuous Integration

Continuous Integration (CI) is a fundamental DevOps concept. CI enables developers to manage their work and merge their changes into a central repository or version control system, and release these updates continuously. DevOps principles, at their core, emphasize achieving the best collaboration, whether or not people are working on the same functions of classes, triggers, or layouts. The minute an organization begins building or contracting with a development team, the use case for CI is made. 

There’s No Undo Feature in Salesforce

Salesforce is always in its current configuration at log in. It has no concept of what existed before new changes were made. Any alteration becomes the reality at the moment it’s published. There is no inherent mechanism for versioning or an undo option. If a client wished to restore a previous configuration, developers would be forced to replicate the prior iteration and overwrite the current instance. It’s a time-consuming and inefficient process for change management. Now imagine a larger team of developers, each writing custom code and developing in the same environment. 

If developers A, B, and C are working on their customizations, they are not impacting one another. But even a simple change request across developers can have catastrophic effects. For the sake of argument, let’s assume developer A was asked to change one letter of a label that resides in the instance that developer B is handling. The minute A publishes this change, it immediately overwrites all the other customizations that B has been coding. Adopting orchestrated CI practices removes these barriers and potential pitfalls.

Repeatable, Reliable Change Management

For multiple developers working in the same Salesforce environment, CI creates a repeatable and reliable process that makes sure changes are merged with those of other developers instead of being overwritten. This can occur manually or through the use of automation tools. The mechanisms around CI break down into a few separate pieces. One of the most critical is version control.

Version Control

Version control, sometimes referred to as source control, is a database solution that records a developer’s coding, changes, and amount of progress. This data is stored and archived in the version control database. Developers can go back to previous points in time and review the work that was made. If a past customization must be restored, a developer simply accesses that code and places the file version into the Salesforce organization. Think of it as a glorified copy and paste feature. One of the most common version control systems for Salesforce development is GitHub. How do developers utilize version control? 

• Work must be saved into the version control tool first, before publishing to the Salesforce organization. Otherwise, any other concurrent changes being made in the environment could wipe out the change this developer is coding—or, his or her code could overwrite other contemporaneous work being performed by other developers. 
• Version control empowers developers to go back and restore files from a specific spot in the process.
• Version control ensures that requested changes merge seamlessly into other customizations being designed at the time.
• Version control facilitates “undo” functionality.
• Version control is key to an efficient process that allows developers to protect their work and deliver on client expectations in an agile workflow. 

Interestingly, as Salesforce development experts estimate, less than five percent (5%) of developers in the world actually rely on CI version control practices to protect their work. They either don’t know these tools are available or understand how to get started with them.

Test Classes

Salesforce requires developers to write test classes if they are creating custom code that alters the way its products affect a customer’s business. Before developers can add customizations into the Salesforce configuration, they must write a test scenario to demonstrate that the new functionality performs as anticipated. A well-designed CI process pairs version control with test classes.

• The customization is added to the version control system first.
• The developer writes a test class and adds that to the version control tool.
• The developer runs the test to ensure that it passes—that the new functionality operates as intended.
• The combination of customizations and tests can be thought of as a deliverable module. And both should be entered into version or source control to prevent mishaps.
• If all the tests pass, developers have assurance that they wrote accurate code. They can then publish the changes to the organization and run additional tests in the production environment,
• Tests should continue to pass even as changes are made. If not, something in the code has been broken. Fortunately, version control allows development teams to review the code, detect changes, and determine if something was overwritten. The correct code can then be restored easily. 

Without the presence of testing and the communication afforded by solid CI practices, a developer would need to walk through every possible scenario manually to uncover an error, which is impractical, to say the least. 

Salesforce DX and Test Class Automation

To ensure that the new code does not introduce bugs, builds and tests can be automated to run before or after developers check their changes. Many third-party CI tools are available to enrich and streamline the process. Salesforce DX is a series of tools, features, and APIs to make it easier for Salesforce teams to adopt modern DevOps. It encourages developers to adopt best practices already common on other platforms and software development stacks, such as using version control and automating more parts of the release process. Salesforce DX easily integrates into these tools so that developers can set up continuous integration for Salesforce applications. Following are some common tools.

• Continuous Integration Using CircleCI
  CircleCI is a commonly used integration tool that integrates with existing version control systems to push incremental updates to the environment. CircleCI can be used as a cloud-based or on-premise tool. 
• Continuous Integration Using Jenkins
  Jenkins is an open-source, extensible automation server for implementing continuous integration and continuous delivery. Organizations can easily integrate Salesforce DX into the Jenkins framework to automate testing of Salesforce applications against scratch orgs.
• Continuous Integration with Travis CI
  Travis CI is a cloud-based continuous integration (CI) service for building and testing software projects hosted on GitHub.
• Sample CI Repos for Org Development Model
  Get started quickly with CI by cloning a sample repository from your vendor of choice. Each repo has a sample configuration file and a comprehensive README.md with step-by-step information.

Tools such as these can automatically run tests once data has been entered into version control. They detect changes, merge changes with others, put the customizations into the Salesforce environment, run all tests, and then report on the results. This is the foundation of CI: a high level of confidence that what developers build actually works. In this way, CI also promotes superior service delivery to clients.

Sandboxes and Scratch Orgs

In the Salesforce ecosystem, every customer has one production environment, referred to as an organization (org). However, customers can also have several sandboxes, which are non-production instances that incorporate exact copies of the production environment at the current point in time. For non-development Salesforce administrators, sandboxes offer a rudimentary path toward version control. For example, if I’m an administrator who is making basic changes, I might create a sandbox every Monday. Then I know precisely what I have in production currently. If I make a mistake, I can go back to the sandbox and fix it. In the development world, even though sandboxes are also used, the process is seldom that smooth.

Sandboxes for development teams omit the core processes that make CI effective. By using sandboxes exclusively, developers have no insight into seeing if their changes are interfering with those made by others. They do not accommodate merging customizations or running tests. Basically, the last developer to enter changes into production is the winner. And we’re back to the origins of the dilemma that necessitates CI. 

One workaround used by developers is to create unique sandboxes for their customizations. When they’ve completed their work, they place their code into a common sandbox and test that one. If the test passes, the code moves into production. The downside, however, comes from the lack of visibility across sandboxes. Problems, in this method, won’t reveal themselves until all the changes coexist in the common sandbox. And at that point, the common sandbox has overwritten the previous work. 

Salesforce devised an alternative approach as part of its DX framework. Rather than relying on sandboxes, developers can establish Scratch Orgs, a type of sandbox that depicts a representation of any version the developer wants, without matching the current production environment configuration or another developer’s sandbox. 

Through Scratch Orgs, developers enter data and run tests to ensure that everything is working in the manner envisioned. This, in some ways, constitutes the final piece in tying a true CI process together. Scratch Orgs eliminate the need for developers to figure out how to update multiple sandboxes—without deleting anything. The CI tools further refine the process with automation. They can save incremental changes into version control, deploy and merge customizations into a sandbox, trigger a mechanism to run tests, monitor the results, and publish the work to the Salesforce organization. CI tools enable customers to do this at a frequency of their choosing: every day, every three hours, etc. 

Conclusion

Salesforce is truly a dynamic solution. It can be simple to use or it can increase with complexity as business needs dictate. Yet as the ecosystem expands, so do the terms, processes, and best practices. This can be confusing. Our intent in publishing this white paper is to soften the point of entry for users who may have heard phrases such as CI, but don’t quite fathom how they affect an organization. Our hope is to educate users in unfamiliar Salesforce ideologies or terminologies, discuss approaches to process efficiencies that make sense, and highlight some of the tools available to help. 

‍

Image by Gerd Altmann from Pixabay