Trunk-based development applies every change directly to the shared main branch instead of isolating work in feature branches. It favors small, incremental infrastructure changes and uses testing environments to verify them before production. section 7.2.2
A practical infrastructure workflow is:
- Clone the configuration repository and confirm that the working copy is on main. section 7.2.2
- Make a small change, commit it, and update the local copy with git pull --rebase. section 7.2.2
- Push to main, run unit and integration tests in a testing environment, and wait for team approval before production delivery. section 7.2.2
The shared branch imposes ordering: teammates cannot evolve changes independently, but conflicts and the commit causing a failure become easier to identify. The pattern reduces blast radius through incremental changes, while requiring discipline, organization, and a long-lived testing environment. It lacks a separate manual-review stage before merging. section 7.2.2 section 7.2.3
Firewall configuration changes
One engineer commits a firewall rule change to main first. A teammate pulls the updated repository, commits a firewall license update, and pushes afterward. The pipeline tests each change against a testing environment before approval and production delivery. section 7.2.2
Figure 7.13 When you use trunk development, you maintain one main branch and update the production configuration directly.
Shows the single-main-branch collaboration model used for direct configuration updates. section 7.2.2
