0006 - Trunk-Based Development¶
Date¶
2022-11-17
Status¶
Accepted
Context¶
There are different ways of handling source control branching and deployment strategies; e.g. trunk based, feature based, release branches etc.
Evenergi needs to choose 1 strategy to keep a consistent way of working across teams and products.
From Trunk Based Development:
A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
With Trunk Based Development, the exact same application is deployed sequentially through each environment (ie develop, staging, production) ensuring the validated application is what is actually deployed to production instead of a newly merged branch which may introduce merging errors, unintended additions or missing features.
Decision¶
We are choosing to use Trunk Based Development.
Consequences¶
The consequences of using trunk based development are:
- Developmental steps need to be small, committable and without breaking the build or product.
- Large scale feature additions should be developed as a series of small steps.
- TDD is a fundamental way of working that lends itself to small incremental deployable code changes.
- Partial feature deployments not ready for customer use shall be managed via feature flags.
- CI/CD scripts and associated applications must be agnostic of the environment they are deployed to, handling a environmental variable for any environment specific values/functionality
- Failures must be tested (TDD, local developer based sanity testing, post deployment validation) early and often to ensure a viable trunk deployment