Salesforce DevOps

There is no doubt that DevOps for Salesforce is different. It allows for speed and collaboration between stakeholders that other platforms simply can’t offer.

DevOps is not so much a thing as it is a practice, and a complicated one at that. DevOps is the practice of controlling change within a system. Here, we will specifically look at how DevOps for Salesforce works. There are several key components that make up good DevOps practices, and those mainly include version control, release management, and CI/CD, and Flosum is a platform that uncomplicates and streamlines these practices.

Flosum Release Management and Data Migration

Flosum offers some excellent tools to help your DevOps teams including built-in version control, continuous deployment systems, merge tools, and tons of different testing tools. Schedule a demo today to find out more about how Flosum can supercharge your DevOps practices today!

Version Control

Version control refers to the creation of a system that can track changes and keep records of previous versions of an application. Developing with version control is pivotal in any DevOps system because you need to be able to revert changes at a moment’s notice. If a new change breaks production due to an unforeseen use case, then the previous version of the application needs to be ready to be restored at a moment’s notice to reduce operational downtime.

It’s also pivotal to any good DevOps practice because oftentimes there is not just one member working on an application. As multiple developers make changes to code, any changes need to be accessible and visible to the whole group or pieces of the program will start to clash. It’s for this reason that version control might singularly be the most important portion of any DevOps practice.

Release Management

It’s a costly mistake to deliver content from development by injecting it directly into production, and that’s where release management comes in. Release management focuses on the process that a finished application undergoes to make it from the developer’s hands into the user’s production organizations.

Release management systems come in all different shapes and sizes, but they usually focus on passing any application through a series of tests to look for any issues. These tests not only look for use-case issues but should also look for roll-out issues as those often go unnoticed until rollout occurs.


CI/CD stands for continuous integration and continuous delivery and follows along the lines of release management. Release management is the process by which you test and release new content, and CI/CD controls the rate of that flow. In order for that flow to be smooth and as quick as possible, good CI/CD practice focuses primarily on automating test execution.

Let’s face it, developers can not be expected to test everything, nor should they be. We want our developers to do what they do best, develop! That’s why automated testing is so important for good DevOps practices because it moves developers away from testing and keeps them focused on what’s important, developing.

How is Salesforce DevOps Special?

It’s not so much that DevOps is uniquely different with Salesforce, it’s more that there are special restrictions on what is possible. One of the main areas where DevOps is special with Salesforce is because Salesforce has different organization types depending upon what stage in the DevOps process you are. There are developer and scratch orgs for development, developer and scratch orgs for testing, sandboxes for rollout testing, and then production that everyone works in.

With common DevOps processes, there could be any number of environments that an application could pass through before being rolled out. There might not even be a specific version of production that everyone uses, for instance with phone app rollouts people could be using iOS 10 or iOS 13.

Another area that makes Salesforce DevOps special is that there are different ways to package a release depending upon its target organization. With Salesforce you could use a managed package, changesets, or Salesforce DX to load a new application into an organization. With most other DevOps practices there is one way to package an application and deliver it to another organization, but with Salesforce there are several.

These are just some of the ways that approaching DevOps from a Salesforce perspective can differ from DevOps practices with other programs. If all the different methods of transferring applications seems a little hectic, check out the Flosum platform which helps deal with transferring applications between the different environments


Is it faster to make changes directly in production? Absolutely, but the risks are also higher. A good DevOps practice allows you to mitigate the risks of making changes by spreading out the effect of an issue across several different organizations, and always keeping a backup on standby. While this does translate to longer development time, the added testing means a more robust app that is ready to face the end-user.

With a more robust app, your development teams can spend less time fixing eventual issues and more time working on creating the next big change to the system. Let’s face it, nobody wants to redo work, and by implementing smart devops practices you don’t have to.


Another unique advantage of following a good Salesforce DevOps practice is collaboration. With version control, multiple team members can work on the same application simultaneously which will speed up your Apps time to production. Whether you’re building a company-specific application or an AppExchange app, establishing a good DevOps practice is crucial to any successful app build.

Ready to simplify your Salesforce Deployment?