Salesforce DevOps in OrgFlow

OrgFlow's DevOps features let you manage Salesforce metadata changes using a true Git-based workflow.

OrgFlow supports the full lifecycle of Salesforce metadata management: creating and deleting sandbox environments, retrieving changes from orgs, deploying changes to orgs, merging changes between environments, running Apex tests — all orchestrated through your Git repository. Metadata changes are flowed between orgs by merging between their branches — never by copying directly from one org to another.

This approach gives you automatic change detection across all your Salesforce orgs, detailed version history, branching and merging for parallel development, pull requests for peer review, and reliable conflict detection and resolution. The result is a Salesforce change management workflow that is safe, traceable and built on the same tools and practices used by the rest of the software development industry.

Every Salesforce org in your workflow is paired with a branch in your Git repository to form an environment. OrgFlow's DevOps operations operate on those environments.

DevOps operations

There are currently six DevOps operations in OrgFlow:

Operation	Description
Flow in	Detect and retrieve new metadata changes from an environment's Salesforce org and commit them to its backing Git branch
Flow out	Determine undeployed metadata changes in an environment's Git branch and deploy them to its Salesforce org
Flow merge	Merge metadata changes from a source environment into a target environment, optionally including retrieval and deployment
Run Apex tests	Run Apex tests in an environment's Salesforce org and analyze the results
Create environment	Create a new Salesforce sandbox and add it as an environment to your stack (or add an existing sandbox)
Delete environment	Delete an environment in your stack, and optionally delete its Git branch and/or Salesforce sandbox

OrgFlow's DevOps operations are built on top of core concepts like jobs and schedules, which allows you to automate DevOps operations to run on a recurring basis.

DevOps vs. Data

OrgFlow has two main product areas: DevOps and Data. The DevOps features deal with flowing changes to Salesforce metadata (the structure and configuration of your org) using Git-based version control, while the data features deal with Salesforce data (the actual records stored in your org) and operate independently of any Git repository.

The two areas share underlying infrastructure and common functionality such as workspaces, stacks, jobs and schedules, but they serve different purposes and are operated independently.

Git at the core

In other Salesforce DevOps tools boasting Git version control features, Git is often treated as an external and optional nicety — just another source or target for metadata comparisons or copy/paste change migrations. OrgFlow is different because it makes Git a core and required component of your Salesforce DevOps workflow. By making Git a core component at the center of all metadata operations, OrgFlow is able to leverage its power to provide some things that are conspicuously missing from Salesforce's built-in change management and deployment story:

• Automatic change detection in all Salesforce orgs (not just for Developer sandboxes with source tracking enabled)
• Branching and merging of your metadata codebase to allow development in temporary isolation, followed by controlled integration and deployment
• Pull requests to enable collaborative peer review and automated validation of changes
• Conflict detection and resolution to ensure that changes never silently overwrite other changes
• Metadata backup with full point-in-time rollback capabilities
• Version history that shows exactly what was changed, when and by whom — line by line, all the way back to when you started using OrgFlow

In OrgFlow, there are no direct org-to-org comparisons or deployments. Instead, each Salesforce org is paired up with, and continuously kept in sync with, a backing Git branch, and metadata changes are flowed between orgs by merging between their Git branches.

This means there are no copy/paste semantics in any part of OrgFlow's change management — every change is always done using some form of Git merge, and there is never any risk of changes made in one place inadvertently overwriting (clobbering) those made in another place.

For example, if the same line in the same metadata component was changed in different ways in two different orgs, and you flow changes from one org to the other, this is detected by Git and raised as a merge conflict. Some merge conflicts can be intelligently resolved by OrgFlow, because it possesses a degree of semantic understanding of Salesforce metadata structure that Git does not. Other conflicts must be resolved by a user in your workspace — but OrgFlow provides the tools to make this easy and efficient.

It's important to point out that, even though it plays a central role, your Git repository is never hidden or abstracted away from you, and OrgFlow never takes full ownership or requires exclusive control of your repository. Your Git repository remains fully in your control, you are encouraged to commit and push changes to it as you see fit, and OrgFlow is designed to gracefully integrate your commits with its own.