Skip to content

Instantly share code, notes, and snippets.

@tomdavidson

tomdavidson/twf.md

Created January 6, 2022 06:12
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tomdavidson/24eeac2725db36288c7c60715995fe73 to your computer and use it in GitHub Desktop.
Save tomdavidson/24eeac2725db36288c7c60715995fe73 to your computer and use it in GitHub Desktop.
Download ZIP
moving forward trunk based workflow
Raw
twf.md

Trunk-based Workflow

Multiple "right ways" to implement trunk-based delepment and workflow. For more info checkout trunkbaseddevelopment.com. Tom's "right way" emphisies forward moving flow and deploying from artifacts rather than git SHAs:

  • All code change starts and ends with the single, long-lived trunk, main. There are no release, prod, or other long-lived branches. Releases are cut from the trunk.

  • Code review will utilize GitHub PRs from short-lived branches targeting the main trunk. We call these short-lived branches, working branches, to avoid conflating feature-based workflow with our trunk-based workflow.

  • Prior to integration, the proposed change is fully tested, even deployed when end-to-end or manual acceptance tests are needed. Git Hooks are used to run unit tests and static analysis prior to pushing.

  • Completing a feature or epic may take multiple PRs and working branches but each should only address a single feature. If the PR could risk the production readiness of main, it should compartmentalize the change with a build-time feature flag / branch by abstraction. The flag should be removed once the code no longer breaks main.

  • Squash commits will be used to merge into main providing a single commit of all of the proposed change. The commit title and body will be taken from the PR. Engineers do not need to rebase prior to pushing and often it may be better to keep the working commit history to add context for the PR approval.

  • The main trunk should be kept in a releasable state and all PRs are blocked when code from main is not releasable, but attention needs to be given to make sure this backpressure does not inflate the size of changes in the PRs.

  • The life span of working branches has a rather significant effect on the cycle-time so the typical life of a working branch should not exceed the targeted cycle time. Working branches should be pushed once a day to share the work with others and to gain feedback from CI/CD. Working branches are automatically updated when main changes and merge conflicts are the branch’s responsibility. The pressure to avoid merge conflicts is expected to keep changes small and to avoid working on the same area of the repo as another engineer (keep the issue board up to date).

  • Automate as much of the code review as possible and auto merge when all checks have passed - including a peer review check. Use GitHub Actions and apps for continuous integration and releasing of artifacts. Use GitHub Actions for automated deploy or publish artifacts but leave the door open to using a cloud provider’s CD tool or even a self-hosted one if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment