Skip to content

Instantly share code, notes, and snippets.

@drew-y

drew-y/updated-release-proposal.md

Last active April 15, 2022 21:02
Show Gist options
  • Save drew-y/d2176e0e68a7e5d7f5c84d08e1e9846b to your computer and use it in GitHub Desktop.
Save drew-y/d2176e0e68a7e5d7f5c84d08e1e9846b to your computer and use it in GitHub Desktop.
Download ZIP
Raw
updated-release-proposal.md

Updated Release Process Proposal

Goals of this plan:

  • Eliminate interruptions to an in-progress release
  • Move towards a trunk based continuous delivery model (https://trunkbaseddevelopment.com/)
  • Avoid disruption to engineers

proposed-git-workflow

New Concepts

  • prod branch - the branch that is used for production releases
  • release branch - Branches forked from main that are used for releases

Cutting A Release

  • Checkout latest main
  • Create a new release branch in the format release-v0.1.0
  • Publish release branch with git push -u origin release-v0.1.0
  • Confirm with all contributors to the release that the release branch is ready
    • Contributors can be found with git rev-list v0.0.0..HEAD where v0.0.0 is the previous release
    • Fixes can be cherry picked from main into the release branch during this time
  • Open a PR in GitHub from release-v0.1.0 to prod
  • Once merged, create a release in Github targeting prod with a new tag in the format v0.1.0.
  • Delete the release branch

Cutting A Hotfix

  • Create a hotfix branch in the format hotfix-v0.1.1 from the tip of prod
  • Cherry-pick the fix commit from main into the hotfix-v0.1.1 branch
  • Open a PR in GitHub from hotfix-v0.1.1 to prod
  • Once merged, create a release in Github targeting prod with a new tag in the format v0.1.1.

Important Notes

  • main is the source of truth for the codebase
  • Release branches and hotfix branches are never merged into main
  • Any changes to a release or hotfix branch must be done by cherry-picking commits from main.
    • This means you can not push changes to release or hotfix branches directly.
  • main should be considered to as stable. Do not push changes to main that are not ready to be in prod.
    • If a feature isn't ready for release, consider putting it behind a feature flag.
  • Task branches should be small and committed frequently.
  • Merges into prod should not be squash merges. This ensures we can determine contributors since the last release. Merges into main can still be squashed.

Good Reads

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