Simple Dev/Release Workflows 2020.11.05

In this post I'll introduce very simple software development workflows, each suitable for different needs:

The Red Light, Green Light / Feature Freeze Flow

RLGL State Machine

Like in the famous children's game of "Red Light, Green Light" (aka "Statues", and many other names), development switches between two modes:

When preparing releases and not deliberately choosing a workflow, work tends to naturally develop into the RLGL flow. When you find that there are too many bugs, it may come naturally to decide: "let's focus on fixing bugs now and keep the new features for later".

The mutex analogy: A freeze is mutually exclusive with adding features to main.

Challenges with statefulness and concurrency

If you ever heard an "Oh! I wasn't aware that we're in a feature freeze", that's because communication is tricky. Someone may have missed a meeting, or announcements in the group chat may have been drowned by other messages. If you find coordinating the state to be tricky, it may make sense to use a flow that formalizes the modes of development in the structure of the git branches.

The Light Flow

Light Flow Commit Tree

The different types of branches and commits in the diagram:

How to Light Flow

Using a release branch

When the main branch is not suitable for release as is, the person in charge of the release will create a branch from a selected commit in main, calling it fixes-VERSION, or informally "the current release branch".

How to choose a branching point for the release branch

The commit messages and the bug tracker help us "taint" the states in the main branch with existence of various bugs.

A good point to start the release branch is one which is relatively clean, yet also includes valueable features which improve upon the previous release.

If the chosen point doesn't include all the fixes currently available in main, we'll git cherry-pick them into the release branch.

Caution with reverts on the release branch

Sometimes we may want to git revert a commit only for a release branch. In this case we should keep in mind that if we merge the release branch as is, the revert will propagate into main. If we wish to avoid that, we should remember to un-revert the commit!

How does Light Flow compare to other workflows

The GitHub Flow

The GitHub Flow has a main branch and feature branches, without release branches.

Its tools to avoid bugs are code reviews for all changes and rolling back faulty versions. If you can un-deploy faulty versions, which is often possible for web apps, and can put in the time and effort to do good code review, then this flow might work well for you.

If you prefer to avoid faulty releases, and prefer to not extensively code review each and every change, then the Light Flow is probably a better fit.

Comparison to GitFlow


Note that Vincent Driessen, the creator of GitFlow, currently recommends most projects to adopt the GitHub Flow instead.

The Light flow is a simplified variant of GitFlow. The differences are:

The Light Flow's recommendation for rebasing feature branches and omission of hotfix branches puts an emphasis on integrating new developments faster and releasing them from main more often, to avoid accumulating a gap of unreleased and unstable features.

Comparison to Trunk Based Development

The Trunk Based Development may seem similar to the light flow, as the difference is small: It prescribes that release branches should not be merged back to main.

Its site refers to the Light Flow by the name "Mainline" (note that their description predates this post), and it considers it as the "diametrically opposite to Trunk-Based Development", and furthermore, recommends not to use it! But personally I'm not convinced, and I'll demonstrate with a simple example how the small difference between workflow affects things:

Imagine that we decided to revert a commit in a release branch.

The following diagram represents the diff between Light Flow and Trunk based in this scenario, in the form of a bright pink cherry-pick commit and pink arrows denoting merges of release branches back to main:

Light Flow vs Trunk Based

Doing git log release-2.4..release2.5 in this example would list the correct changes list of changes between these releases with the Light Flow, but using Trunk-Based it will be have a misleading result for this log that omits the re-introduction of the reverted change.

Does the Light Flow work


I wrote this post in order to suggest this model for the development of Pajam (btw, if you happen to be a musician that wants to jam with their friends remotely, I highly recommend you to give Pajam a try!).

Update from 2021.01.26: So far this flow is working very well for us!