Azure-devops-docs: Trunk Based Development

[Wil73]

Sorry, but "shared version control branch" is misleading. CI requires trunk based development. Humble stated this quite clearly in his Continuous Delivery book. For some reason everyone dances around this elephant or uses obscure language to circumvent or confuse the practice.

Develop on Trunk. Read Paul Hammant's blog for more details. This is the practice that fits with CI. Anything else is merely a half attempt and hybrid.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1bc48620-03dc-7d0e-5e30-2e70fd114028
• Version Independent ID: 6142280a-a27b-aaf6-43ef-b91f7ae44084
• Content: What is Continuous Integration? - Azure DevOps
• Content Source: https://mseng.visualstudio.com/DefaultCollection/TechnicalContent/_git/devops-learn-pr?path=%2fdocs%2fwhat-is-continuous-integration.md&version=GBlive&_a=contents
• Product: devops
• Git Login: samgu
• Microsoft Alias: samgu

[steved0x]

@samgu Can you take a look at this one?

[Wil73]

That looks good. This is a problem I run into all the time that Humble and Farley discuss at length: teams discuss Continuous Integration and do not follow through with Trunk Based Development. Teams often setup CI in their IT Infrastructure, but continue to work in feature branches for weeks. This is a huge problem and misunderstanding of CI right now: TBD and CI are a married couple really, but everyone talks about them as separate practices.

Whenever I read about CI practices now I look for TBD first thing out of the gate.

There are many articles on CI around that even suggest you can do CI with short lived branches. That I think is a half measure still. The debate now is how often the branch is alive. Some people say 1 day or less, but other teams are OK with 3 days. The worst is when CI is discussed at length and version control is not even mentioned at all.

Migrating from long lived feature branches to TBD is a huge shift... certainly important and worth a discussion.

My thinking is if you are going to make a branch for only one day.. why bother with a branch at all?

Check these great articles out:

https://www.gocd.org/2017/05/09/continuous-integration-devops-research/
https://techbeacon.com/why-you-dont-do-continuous-integration-well-you-think-you-do
https://mrdevops.io/if-you-still-insist-on-feature-branching-you-are-hurting-your-business-and-our-profession-32e1109d4594

[indigogiant]

I 100% agree with Wil73.

If all developers are not merging their code on a very regular basis you're not doing CI.

For some projects features may typically be small pieces of work that can be completed in a day or two, in which case go ahead - use feature branches if you like, if doesn't really matter.

But if your project has features that are large, complex pieces of work that can take many days or weeks before they're completed then feature branches just lead to the merge hell and brittleness that CI is intended to avoid. Use feature toggles instead of feature branches to disable features that are not ready for use.

TBD also avoids the problem of features being put on hold leading to code rot as the main branch diverges from the feature branch.

[steved0x]

I have submitted this feedback to the authors, thank you for your detailed post and information.