Introducing OrgFlow’s New Snapshots and Rollback Feature

We’re very excited to announce that, starting with version 1.6.0, we have added long-awaited metadata rollback functionality to OrgFlow to help you recover from inadvertent loss of metadata.

The basic concept is simple: snapshots are created at key points during the lifetime of an OrgFlow environment, and because your Git repository contains your full metadata history, you can roll back the environment to any one of those snapshots.

Quite handy in those moments where you basically just need to turn back time a little bit.

OrgFlow’s new rollback functionality: the flying DeLorean of Salesforce metadata.

There are many possible situations where you may find this useful. Here are two very common ones:

• Metadata has been deleted from an environment by mistake and now you want to recover it from Git history
• A merge from one environment to another introduced too many deployment failures and now you’re looking to undo the merge and start over

Let’s take a closer look at how this functionality works and how you would take advantage of it in your Salesforce DevOps process.

Anatomy of a snapshot

In OrgFlow an environment consists of three parts:

1. Your Salesforce org (production or sandbox)
2. Your Git branch
3. The environment state that OrgFlow stores to keep track of undeployable components, last known parity points, etc.

For a rollback to be effective and actually roll back your environment to a consistent state, all three of these parts must be rolled back together (though if you know what you’re doing, you can roll back only certain parts if needed in order to get out a jam — more on that later).

You can think of a snapshot as a point in an environment’s Git history where OrgFlow knew the Git branch and the Salesforce org to have parity, i.e. where all the metadata was identical except for any undeployable components at that point.

Technically a snapshot consists of a number, a descriptive title, a created date, the entire environment state as it was at that point in time, including the HEAD commit hash, any undeployable or temporarily excluded components, and so on. OrgFlow stores these snapshots and all their contents in our hosted state store in the cloud.

You can see the snapshots for a given environment by running the env:snapshot:list command like so:

Each snapshot is automatically assigned a snapshot number when created. The snapshot number is continuously incrementing and unique only within a given environment (i.e. the same number may be used on a different snapshot in a different environment). This number is how you refer to the snapshot when rolling back an environment, or managing your snapshots.

Creating snapshots

OrgFlow automatically creates snapshots at certain times:

• When an environment is created
• After each inbound flow
• After each outbound flow
• After each merge flow (for each inbound or outbound flow that happened during the merge flow)
• After a rollback (more on that later)

The title of the snapshot will reflect which of the above events caused the snapshot to be created.

We only create snapshots at these specific times, because these are the points where we know the environment to have parity. At any other point in time, the environment’s Git branch or Salesforce org may each be ahead of or behind the other, and creating a snapshot at such a time would not be useful because a rollback would reset your Salesforce org to a state it wasn’t actually in at the time.

For that reason, you also cannot create your own snapshot at will — there is no env:snapshot:create command or similar.

Since version 1.5.0 of OrgFlow, these snapshots have been silently created in the background. Now in version 1.6.0 we are exposing this functionality and adding commands to let you interact with snapshots in meaningful ways.

Managing snapshots

To let you see and manage your snapshots, we have added two new commands in the env:snapshot namespace:

• env:snapshot:list (docs) shows you a list of available snapshots for a given environment.
• env:snapshot:delete (docs) lets you delete one or more numbered ranges of snapshots to keep things tidy over time.

Rolling back an environment

So far we have not seen how to actually use the snapshots for anything meaningful, so let’s get to that finally. We’ve added the env:rollback command (docs) to let you roll back an environment to a snapshot of your choosing.

You run the env:rollback command like this:

$ orgflow env:rollback --environment=UAT --toSnapshot=13

The overall process goes something like:

1. Run the env:snapshot:list for the environment, to see which snapshots are available.
2. Choose your snapshot very carefully, keeping in mind that anything that happened in your Salesforce org and its backing Git branch will be wiped out forever.
3. For some added safety, consider creating a copy of the environment’s backing Git branch in your repository as a backup, so you have some way of recovering the metadata that was rolled back.
4. Run the env:rollback command and watch the magic

OrgFlow will do the following:

• Revert the Git branch to the commit hash of the chosen snapshot
• Revert the environment state
• Perform an outbound flow to also revert the Salesforce org accordingly
• Record any deployment failures as new undeployable components
• Create a new snapshot (because the environment state may now be a bit different from the snapshot you’re rolling back to as external factors could cause a different set of deployment failures)

Advanced options (don’t try at home, kids)

The env:rollback command also has a couple of advanced options that can help get you out of the kinds of trouble we’ve not even been able to anticipate while building out this feature.

• --noGitRollback skips reverting the Git branch
• --noSalesforceRollback skips doing the outbound flow (i.e. leaves the Salesforce org untouched by the rollback)

Specifying both of these options will revert only the state store, but make no change to either Git or Salesforce.

These options should only be needed in very rare circumstances, either in situations where you’re manually altered the environment state or your Git repository in ways that OrgFlow cannot handle (e.g. force push is always a sure-fire way to get in trouble), or possibly in cases where the OrgFlow process was forcibly terminated at some inopportune moment to leave an environment in an inconsistent state.

That was a quick introduction to the recently added snapshots and rollback functionality in OrgFlow. We hope you’ll find this functionality useful and that it may some day help get you out of a tough spot. :)

Don’t take our word for it — try it out for yourself and see OrgFlow’s snapshots and rollback feature in action. Find out more about OrgFlow on our website, or jump straight in and download it today. OrgFlow is free to try for 2 months — no usage limits, no strings attached, no credit card or billing information required.