Trunk-Based Development with Modern CI/CD

Long-lived feature branches create merge hell and delayed integration. Trunk-based development keeps main (or trunk) always releasable with small, frequent commits.

Trunk vs GitFlow

Daily CI/CD Loop

Branch Policy

Rule	Guideline
Branch lifetime	< 2 days
PR size	Small, reviewable diffs
Main branch	Always green CI
Releases	Tag trunk, not long release branches

GitLab CI for Trunk

workflow: rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH stages: - validate - test - deploy deploy:staging: stage: deploy script: - ./deploy.sh staging rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH deploy:production: stage: deploy when: manual script: - ./deploy.sh production rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Enabling Practices

1. Comprehensive automated tests — trunk must stay trustworthy
2. Feature flags — LaunchDarkly, Unleash, or env-based toggles
3. Pair programming / fast reviews — unblock small PRs quickly
4. Branch protection — require CI pass before merge

Metrics to Track

• Integration frequency — merges per day
• Lead time — commit to production
• CI duration — keep under 10 minutes for fast feedback
• Change failure rate — should decrease with smaller batches

Conclusion

Trunk-based development works when CI is fast and feature flags decouple deployment from release. Start by shortening branch lifetime before reorganizing your entire Git model.