Development Workflow

This pages describes how team Hinnstein should work with code on a daily basis. The flow is heavily inspired by Scaled Trunk-Based Development.

Goal#

Implementation#

Main is the only long-living branch and changes are always applied by creating a branch and opening a pull request.

Create a new branch from the main branch

$ git checkout main
$ git pull
$ git checkout -b <branch name>

Implement the task and commit the changes

$ git commit -m "1234: Lorem ipsum"

Rebase on main (Build validation will fail if the branch is behind main)

$ git fetch
$ git rebase origin/main

Push

$ git push -u origin <branch_name>

Open a pull request with the main branch as target. The image below illustrates the entire process from creating a new branch to deployment into dev.

It is important to keep in mind that the main branch should always be in a releasable state. The code should be hidden behind a feature flag if the code cannot be released to production within a reasonable short amount of time.

When do I create a feature flag? See examples below.

Commits#

Commits shall be prefix with a task_id, followed by a colon separated subject. A descriptive text can be added in the commit body if necessary.

$ git commit -m "1337: Add spacing to header"

1337: Fix error on home page

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmodtempor incididunt ut labore et dolore magna aliqua.
Vel turpis nunc eget lorem dolor sed viverra ipsum.

Unrelated changes are allowed and must be prefixed with KAIZEN-0 instead of task_id. Significant changes require a separate task and task branch.

$ git commit -m "KAIZEN-0: Update readme"

How do I write good commit messages?

Branches#

Branches shall be prefix with a task_id, followed by a short title, separated by dashes. Keep the title short and descriptive.

$ git checkbout -b 1337-foo-bar

Prefix the branch with kaizen-0 if the branch only contains minor changes that is unrelated to a task

$ git checkout -b kaizen-0-remove-unused-import

Pull Request#

Try to keep the pull requests small. As a rule of thumb, a branch should not live for more than 2-3 days.

In order to keep the pull requests small, it is important that you prioritize to review the code of your teammates. Helping your teammates to finish their work, is equally as important as you finishing your own work.

Deployment#

Releasable artifacts should always be created from the main branch. The artifact is promoted to staging for verification and testing before promoted to production.

If verification in staging fails, it means that our main branch is broken and successive changes cannot be released. In that event, fixing the main branch should be of high priority for the team.

Hotfix#

In the event of a critical error in production, it may be required to create a hotfix. Creating a hotfix should be the last resort option and only be performed if the error cannot be fixed soon enough through the regular deployment flow.

Consider the following scenario, where a critical bug is detected in version n, which is currently running in production. The main branch contains two additional non-released commits, that for some reason is not desired to be included in the hotfix release.

The bug is reproduced and fixed on the main branch.

A hotfix-branch is created from the version n commit, the fix is cherry-picked from the main branch and a new version is released from the hotfix-branch. In order to replace the hotfix-version, a new release from main should be deployed soon.

If the error cannot be fixed on main or is not possible to reproduce on main, the fix can be committed directly to the hotfix-branch. In that event, releasing a new version from main and verifying that the error is gone, should be of high priority for the team.