Google Sign-In Required

Use your company Google account to access the BetterFleet private content.

Back to private home

BetterFleet Support Private
Skip to content
BetterFleet Dev Wiki
0006 - Trunk-Based Development
Initializing search
    bf-dev
    • Home
    • Product Capabilities
    • Process
    • Current Work
    • System Design
    • Software Reference
    • Operations
    bf-dev
    • Home
      • Overview
      • Manage
      • Overview
      • Product Engineering Workflow
      • Product Engineering Delivery
      • Product Engineering Workflow in Linear
        • GitLab Feature Flags
        • In-App Docs Authoring
        • Release Notes
      • Templates
      • Publishing
      • Workflow Companions
      • Overview
      • Active Artifacts
      • Backlog Artifacts
      • Archived Artifacts
      • Overview
      • Microgrid
      • OSCP
        • Challenge
        • Specification
        • Spec
        • Architecture
        • Overview
        • Script Runtime Model
        • Compose Profiles and Modes
        • Repo Topology
        • CI and Release Integration
        • Overview
        • Internal Application Diagrams
          • Overview
          • Web Model
          • Core Model
        • Service Interaction Flows
        • Data and State
          • Index
          • bf-manage-web
          • bf-manage-core
          • bf-manage-connect
          • bf-manage-sitepwrmon
          • bf-manage-incidents
          • bf-telematics
          • bf-depot-sim
          • bf-manage-roaming
          • bf-support-microsite
          • bf-digital-twin
          • bf-schedule-creator
        • Overview
        • Internal Application Diagrams
        • Migration and Flags
        • Simulation Request Lifecycle
          • Index
          • bf-bnl-ui
          • bf-bnl-settings
          • bf-bnl-schedule-analysis-compute
          • bf-route-modelling
          • bf-schedule-creator
          • bf-digital-twin
        • Overview
        • Secrets and Env Strategy
        • Vendors and Local Dependencies
        • ADRs
        • Service Matrix
        • Cloud Dependencies
        • Ports and URLs
      • Onboarding
      • Daily Operations Runbook
        • Overview
        • Staging Hotfix Release
        • Production Hotfix Release
        • Terraform Plan Dry Runs
      • Troubleshooting
      • Testing Guide
    • Date
    • Status
    • Context
    • Decision
    • Consequences

    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:

    1. Developmental steps need to be small, committable and without breaking the build or product.
    2. Large scale feature additions should be developed as a series of small steps.
    3. TDD is a fundamental way of working that lends itself to small incremental deployable code changes.
    4. Partial feature deployments not ready for customer use shall be managed via feature flags.
    5. 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
    6. Failures must be tested (TDD, local developer based sanity testing, post deployment validation) early and often to ensure a viable trunk deployment
    Made with Material for MkDocs