DEVOPSdigest

Salesforce app development is different from the rest of the software world. This is because the Salesforce applications are tightly bound to the Salesforce platform. Salesforce app developers are keenly focused on the developments within the confines of the ecosystem. While some are happy to stick to the tried and tested, there are those developers who push the boundaries and look to adopt the best development practices from the larger world of software development. They find themselves at an interesting intersection called Salesforce DevOps, or DevOps for Salesforce.

To clarify, when we talk about Salesforce here, we are referring to the Salesforce ecosystem, not the brand or company. There is a huge ecosystem of developers and vendors that make up this space and while they build Salesforce applications, these applications are primarily enterprise applications that happen to be made to work within the boundaries of Salesforce. Often, these applications integrate with a host of other enterprise applications that may not be based on the Salesforce platform.

What is Salesforce DevOps?

Salesforce DevOps is a move to introduce the broader principles of DevOps when building applications in the Salesforce ecosystem. This necessarily includes approaches like continuous integration and continuous delivery — CI/CD. It means taking a shift-left approach putting emphasis on the early part of the development pipeline. It involves using version control to create, store, and push code into production environments. It recognizes the need for test automation and takes a declarative approach to software deployment.

Automation is a key characteristic of DevOps. While Salesforce development has followed the waterfall model, Salesforce DevOps requires automation of every step of the process — builds, tests, and deployments.

Version Control for Salesforce

Development is a collaborative process. Multiple developers write code locally on their devices and need to sync this code with the central repository. This is done using a version control solution.

Rather than developing in silos, Salesforce developers need to adopt version control to track and manage changes with code. Version control gives developers the ability to work on individual branches of code and later merge their changes to the master branch. It helps identify conflicts in code and resolve them. Developers can review each others' code and improve quality across the team. If any change breaks something, it can easily be rolled back.

Version control is the first step of the DevOps process and cannot be ignored by teams looking to adopt DevOps for their Salesforce development.

Salesforce Continuous Integration (CI)

Version control is the beginning of the CI process, but there's more to it. Once code is committed, it needs to be packaged, and tested. This is the domain of a Salesforce CI solution.

The biggest advantage of a CI solution is that it enables healthy management of environments. It looks at differences between a sandbox and production Salesforce Org and allows teams to push changes by reconciling these differences. This is a declarative way of managing environments and is a lot more efficient than manually pushing every code change to a destination Org.

Salesforce CI tools use metadata to identify differences between Orgs. A mature CI tool would give you the option to deploy on every commit, or to deploy on a schedule such as daily, or weekly. When deploying in a continuous manner, which is recommended, it is important to reduce the size of each CI job so that the job executes faster. To do this the CI tool would need to identify only the new changes and deploy them, while leaving old code untouched. This takes metadata such as "last modified date," and "created by."

Test automation is a key step to confidently run CI processes. Salesforce CI solutions typically use a test automation framework to manage test automation. The CI tool should hide the plumbing of the test automation framework and provide a simple UI to create, run, and manage automated tests. Successful test automation should allow to run any combination of tests — all tests within the org, or select tests based on the features being deployed.

Salesforce Continuous Delivery

Continuous integration is the first half of the DevOps process, and the second half is continuous delivery, or continuous deployment. This is about automating, quickening, and better controlling the deployment to a Salesforce Org.

Once code is committed to version control, and packaged and tested, it is ready to be deployed. Here again, metadata plays a key role in identifying which code should be deployed. Continuous deployment for Salesforce should enable immediate deployments or scheduled ones. They should allow to re-deploy the entire codebase, or even better, to incrementally deploy only new code.

Admins should have full control over permissions and allow developers to deploy only to Orgs that they own. During deployments errors and conflicts in code are bound to occur, especially in the case of incremental deployments. Here, a solution that surfaces issues clearly, and facilitates quick remediation is required. Further, when a solution is not immediately available, developers and administrators should be able to rollback any recent deployments.

Implementing DevOps for Salesforce

When it comes to implementing DevOps there are multiple options. You can put together your own custom DevOps toolchain by getting a Salesforce consulting company to integrate best-of-breed solutions into a custom solution. This is expensive, takes a long time, and is hard to maintain as your DevOps process evolves.

The next option is to have an in-house team leverage SalesforceDX and build your own DevOps solution. This again requires a big investment in terms of talent, and takes time to set up. However, it gives you the most control over your DevOps toolchain. 

Whichever route you take, what's clear is that DevOps is not just for the non-Salesforce world, but can produce much gain to Salesforce development teams that adopt it. If more frequent releases and more confidence in each release is what you're after, DevOps for Salesforce is the way to go.