Skip to content

Latest commit

 

History

History
37 lines (27 loc) · 3.43 KB

branching.md

File metadata and controls

37 lines (27 loc) · 3.43 KB
Raw

Charon Branching and Release Model

We follow Trunk Based Development as a branching model for this repo.

Trunk based development has been identified by the DORA research program as one of the set of capabilities that drive higher software delivery and organizational performance.

Trunk Based Development

Overview:

  • Another way to think of it is: micro-commits on stable master.
  • We just call our trunk/master branch “main”.
  • A single GitHub issue can (and probably should) be broken into multiple incremental “micro-commits” / ”micro-PRs” / “short-lived feature branches”.
  • A big feature/ticket/change is split into multiple sequential micro-commits, that each introduce a small incremental change. All while never breaking trunk!
  • CI is run on each commit on trunk, and if a failure is detected, fixing it is the highest priority for the team since it is basically a global blocker.
  • Micro-commits ensure fast and early code reviews and that improves velocity and increases alignment.
  • Micro-commits are pushed for review and then squash-merged into trunk. This process repeats until the ticket or feature has been completed.
  • It is possible to do stacked diffs (multiple open dependent PRs), but this often requires tricky rebases followed by force-pushes that cause PR comments to become “outdated”.

Controlled introduction of change:

  • Since a feature cannot be added as a single big merge of a big feature branch, tools and patterns are required that allow gradual controlled introduction of increment changes without breaking.
  • New code can be added as “dead code”. So not integrated into the actual program yet. Once it is properly complete, it can be integrated in a single PR.
  • Some features should however not be enabled straight into prod/mainnet, but should be rolled-out slowly being first tested in alpha (internal devnet only), then beta (internal and external testnet), and then only stable (enabled everywhere). This can be achieved by simple feature switches (if statements) that enable features based on their feature_set status.
  • Another powerful pattern to gradually introduce change is branching by abstraction. This basically introduces an abstraction layer at the point where a new feature has to replace an old feature (like an interface). Using dependency injection, the new feature can be integrated during testing/staging while the old feature is still being used in production.
  • Note that both feature switches and/or abstraction layers used to roll out a feature should be removed once released to prod/main-net.

Release Process

Charon is set up to create a release with Github Actions triggered by a tag. To create a new release:

  1. Ensure the build is green and that all tests are passing
  2. Identify the version of the release, e.g. v0.1.2 (note the v).
  3. Push a PR that bumps charon version global variable, see example ObolNetwork#312
  4. Merge above PR, checkout latest main, and tag it: git tag <version> && git push --tags
  5. Double-check the generated release and changelog: https://github.com/ObolNetwork/charon/releases/tag/<version>
  6. Maybe generate a changelog manually and/or update the release: go run testutil/genchangelog/main.go