Modern DevOps is a flexible thing, and it can look different across companies and teams. Despite this, there is a common set of principles that should guide any team as they adopt a new process. Following these principles will help you get the most from DevOps and Salesforce.

Complicated processes drive people crazy. Keeping things simple not only improves development speed, but also makes maintenance and training much easier. 

It's easy to get pulled into the trap of designing a solution to cater for every possible edge case right off the bat. Try to avoid this! Start simple, solve your core problems, and tweak it over time to cover additional scenarios. This will keep things manageable and allow you to quickly deliver results.

As the famous saying by Antoine de Saint Exupéry goes: “Perfection is attained not when there is nothing more to add, but when there is nothing left to take away.”

This is probably the biggest change from traditional in-org development. In modern DevOps, source control becomes the new source of truth. All changes go through the repository before they are released into sandboxes or production orgs. 

Just as development is never done directly in production, changes should never be made directly in the master branch of the repository, and the master branch should always be deployable.

Branches should be used to represent a single deliverable request from the business, and include the minimum viable number of changes to deliver that feature. New changes should be deployed out to your testing environments as soon as possible after merging.

Frequent, small releases are better than infrequent, complex ones. The longer a branch exists without getting merged, the greater the risk of merge conflicts and deployment challenges.

This process of shipping small features on a regular cadence is crucial to DevOps. A faster release cycle means that bugs can be found and fixed more quickly, the chances of conflicts and duplicated work are reduced, and the team can be more Agile.

Salesforce is a business-critical platform. From sales to marketing to support, entire sections of companies rely on Salesforce operating successfully for them to function. 

The impact of making a breaking change can be severe. And, to compound the issue, there's no native support for rollback if you introduce a problem. As a result, it's critical that any changes made to orgs are stable and function as expected.

Tests give Salesforce teams the confidence that changes function as expected and are safe to release. Tests should be written well, run regularly, and automated where possible.

Static code analysis (SCA) reviews source code to detect common bad practices, catch bugs, and make sure development adheres to coding guidelines. 

While unit tests and code coverage have the important side effect of forcing you to write more maintainable code, static code analysis explicitly formalizes a series of coding patterns, practices, and heuristics into a series of rules that can be periodically run against your code to assess its quality. By automating static code analysis and building it into your development process, you can identify style violations, bugs, and even more serious performance and security-related issues as you develop, long before they make it into production.

Where a task can sensibly be automated, do so. This reduces the time spent repeating the same series of steps and helps avoid human error causing inconsistencies in deployments. In DevOps, automation manifests itself in several ways:

Watch the following webinar, which explains how to set up a DevOps process in Gearset: