Use Source Control, can't roll back

Created: September 16, 2020

Here's a comparison from the source control survey that is scrambling my brain a bit:

I know the images don't show numbers on the individual slices, but the two have the same scale. Out of the 56 respondents at the time, 8 (14%) are using source control but cannot identify/deploy a previous version of their code. That's a little surprising to me as that's maybe the primary feature of source control. If you are one of those 8, I would be curious to learn more about your situation.

Another fun fact: Git is the unanimous system of choice for those of you already using source control. That's what I use as well. Here's how I go about rolling back Production code in my own projects (using git on the command line).

Of utmost importance to this process is the sanctity of the "main" branch: No code ever makes it onto "main" that has not been successfully reviewed and tested according to our requirements (which is unfortunately not saying the same thing as "No broken code ever makes it on to main"). If you're not using or familiar with branches, we'll be discussing those later.

What this implies is every commit on the main branch is known to be reviewed, tested, Production-ready code, so each commit on main is treated as a new release of the project. To signify this, every commit on main gets a tag, specifically an "annotated tag":

> git tag -a v1.8.0 -m "A super great release with a ton of amazing features!! Also, we squashed that horrendous bug."

This creates a full object in the git database that I can refer back to by its name (e.g. "v1.8.0") later and gives it a short description. I use semantic versioning for all of my tag/release names.

Let's say that next, we release v2.0.0, but it causes some major issues, and we need to roll back to v1.8.0. I can do that in two steps using git and SDF:

> git checkout tags/v1.8.0 -b main
> suitecloud project:deploy

And I'm done! v1.8.0 is now back in Production, and we're free to start work on v2.0.1 to address the issues with that release.

If you don't use the command line, that's OK. All the major git UIs that I know of allow for tagging and checking out tags as well. Do a little poking around in your program's documentation, and I bet you'll find it.

This is the sort of efficiency and power that standardized, disciplined source control practices will enable for you, and it's the sort of efficiency you should be demanding from your team.

How does this differ from your experience?