trunk-based-development

Implement trunk-based development for fast, safe integration. Outputs branching rules, feature flag strategy, CI requirements, and team workflow guidelines.

Zur Installation springen

Repository: kalilurrahman/kr-claudiator-skills
Letzte Quellaktivität: 26. Juli 2026 um 07:41
Erkannte Sprache von SKILL.md: Englisch
Sterne: 1
Forks: 0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Zurück zur Suche Zurück zur Installation

name	trunk-based-development
description	Implement trunk-based development for fast, safe integration. Outputs branching rules, feature flag strategy, CI requirements, and team workflow guidelines.
argument-hint	["team size","deployment frequency","current branching model","CI/CD maturity"]
allowed-tools	Read, Write

Trunk-Based Development (TBD)

Trunk-based development is a source control practice where developers integrate small, frequent changes into the main branch (trunk). Long-lived feature branches are eliminated. The result is faster integration, fewer merge conflicts, and earlier defect detection. It's a prerequisite for continuous deployment.

Core Rules

1. One main branch (trunk) — no long-lived feature branches
2. Integrate at least daily — every developer pushes to trunk every day
3. Branches are short-lived — max 1-2 days; often hours
4. Trunk is always deployable — every commit must pass CI before merge
5. Feature flags gate incomplete features — code ships, features don't
6. Never break the build — fix-forward immediately or revert

Branching Model

TRUNK-BASED (recommended):
  main ─────●─────●─────●─────●─────●──── (always deployable)
              │           │
              └─feat(1d)──┘   └─fix(2h)──┘
              Feature branches: max 1-2 days

GITHUB FLOW (acceptable):
  Same as TBD but PRs before merge to main
  Branches: short-lived feature branches + PRs

GITFLOW (avoid for continuous delivery):
  develop → feature → release → main
  Long-lived branches = integration pain

Feature Flags for Incomplete Work

# Use feature flags to merge incomplete code safely
# Code ships to production; feature is hidden until ready

from launchdarkly import LDClient

ld_client = LDClient(sdk_key=os.environ["LD_SDK_KEY"])

def is_feature_enabled(flag_key: str, user_id: str) -> bool:
    return ld_client.variation(flag_key, {"key": user_id}, default=False)

# In product code — incomplete feature is merged but hidden
@router.get("/api/v1/orders")
async def get_orders(claims: dict = Depends(require_auth)):
    orders = await order_service.get_orders(claims["sub"])
    
    # New grouping feature in progress — only enabled for beta users
    if is_feature_enabled("order-grouping-v2", claims["sub"]):
        return await order_service.get_grouped_orders(claims["sub"])
    
    return orders

# Every commit to main must pass ALL of these before merge
# Target: < 10 minutes total

# .github/workflows/trunk-ci.yml
name: Trunk CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  quality-gate:
    name: Quality Gate (must pass to merge)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements-dev.txt
      
      - name: Lint + type check
        run: ruff check . && mypy src/
        timeout-minutes: 2
      
      - name: Unit tests
        run: pytest tests/unit/ -n auto --timeout=30
        timeout-minutes: 4
      
      - name: Integration tests (critical paths)
        run: pytest tests/integration/ -m "not slow" -n auto
        timeout-minutes: 4
      
      - name: Security scan
        run: bandit -r src/ -ll
        timeout-minutes: 1

  # Slower tests run async — don't block merge but alert on failure
  extended-tests:
    name: Extended Tests (async)
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - run: pytest tests/ --timeout=120
        timeout-minutes: 20

Anti-Pattern	Problem	Fix
Long-lived feature branches	Diverge from trunk; massive merge conflicts	Max 2-day branches; feature flags for long work
Breaking trunk	All developers blocked	Revert immediately; fix-forward never takes precedence
Skipping CI	Defects reach trunk	CI gates are mandatory; no bypassing
Feature flags forever	Flag proliferation; dead code accumulates	Every flag has a removal date in the PR that adds it
Large commits	Hard to review; hard to revert	Commit small; integrate often

Role	Meaning	Anti-pattern
Responsible	Does the work	More than two people listed
Accountable	Owns the outcome, signs off	Shared accountability (always becomes no accountability)
Consulted	Two-way input before the decision	Consulted after the decision is made — purely performative
Informed	One-way notification after the decision	Informed people are asked to approve — wastes their time and yours

Failure mode	Symptom	Counter-move
Analysis paralysis	Weeks of investigation, no decision	Time-box the analysis. State the decision quality you can defend in the time available.
HiPPO override	Highest-paid person's opinion wins regardless of evidence	Force the trade-off table into the room before opinions are voiced
Sunk-cost gravity	Team defends the current path because of prior investment	Re-frame: what would we choose today with no prior investment?
Scope creep at the checkpoint	Review becomes a re-planning session	Separate "did this work?" from "what next?" Run them as two meetings.
Stealth de-scoping	Success metrics quietly soften between day 0 and day 90	Lock the day-0 metrics into the artefact; require an explicit amendment to change them.
Owner drift	Accountable person leaves, no one re-assigns	Owner reassignment is a mandatory step in onboarding/offboarding the role