Trunk-Based Development And Branch By Abstraction
$23.99
Minimum price
$25.99
Suggested price
Trunk-Based Development And Branch By Abstraction
About the Book
An all you need to know reference book about trunk-based development, Branch by abstraction and related software development practices. Many diagrams throughout, and a sections on working out how your company can get from where you are to trunk-based development, CI, CD and all that comes with it.
About the Author
Table of Contents
- 1 Preface
- 2 Introduction
- 2.1 Brief Summary
- 2.2 Claims
- 2.3 Caveats
- 2.4 History
- 3 Context
- 3.1 Trunk-Based Development prerequisites
- 3.2 Trunk-Based Development facilitates
- 3.3 Psychological safety
- 4 Five-minute overview
- 4.1 Distance between developers
- 4.2 What it is
- 4.3 A safety net
- 4.4 Developer team commitments
- 4.5 Drilling into “Distance”
- 5 Deciding Factors
- 5.1 Release cadence
- 5.2 Source-Control Technology Choice
- 5.3 Conway’s Law
- 5.4 Database migrations
- 5.5 Shared code
- 5.6 Which dev teams?
- 6 Source-Control System Features
- 6.1 Productivity
- 6.2 Governance
- 7 Source-Control System Choices
- 7.1 Git and Mercurial
- 7.2 Perforce
- 7.3 Subversion
- 7.4 Team Foundation Server - TFS
- 7.5 PlasticSCM
- 8 Feature flags
- 8.1 Granularity
- 8.2 Implementation
- 8.3 Continuous Integration Pipelines
- 8.4 Runtime Switchable
- 8.5 Build Flags
- 8.6 A/B testing and betas
- 8.7 Tech Debt - pitfall
- 8.8 Flags History
- 9 Branch by Abstraction - Introduction
- 9.1 Ideal steps
- 9.2 Contrived example
- 9.3 Real life software example
- 9.4 Secondary benefits
- 9.5 Not a panacea
- 9.6 More reading for this procedure
- 9.7 History
- 10 Branch for release
- 10.1 Who is committing where?
- 10.2 Late creation of release branches
- 10.3 Fix production bugs on Trunk
- 10.4 Patch releases
- 10.5 Release branch deletion
- 11 Release From Trunk
- 12 Styles of Trunk-Based Development
- 12.1 Committing Straight to the Trunk
- 12.2 Short-Lived Feature Branches
- 12.3 Coupled “Patch Review” System
- 12.4 The Importance of a Local build
- 12.5 Choosing a style
- 13 Continuous Integration (CI)
- 13.1 Continuous Integration - as defined
- 13.2 CI services: Bots verifying human actions
- 13.3 Advanced CI topics
- 13.4 Industry CI daemon confusion
- 13.5 Server/daemon implementations
- 14 Committing straight to the trunk
- 15 Alternatives to committing straight to the trunk
- 16 Short-Lived Feature Branches
- 16.1 Merge directionality
- 16.2 Two developers concurrently working on short-lived feature branches
- 16.3 Personal preferences
- 16.4 Breaking the principles
- 17 Alternatives to short-lived feature branches
- 18 Continuous Code Review
- 18.1 The high bar today
- 18.2 Pull Requests (PRs)
- 18.3 Open Source contributions via PRs
- 18.4 PRs from colleagues
- 18.5 Common Code Owners
- 18.6 Enterprise code review - in the past
- 18.7 Mondrian
- 19 Continuous Delivery (CD)
- 19.1 Continuous Deployment
- 20 Concurrent development of consecutive releases
- 20.1 Concurrent Development?
- 20.2 Oops?
- 20.3 Reorder Releases?
- 20.4 Un-merge?
- 20.5 Flags, abstractions, and pipelines
- 21 Application/service strangulation
- 22 Observed habits
- 22.1 No Code Freeze
- 22.2 Quick Reviews
- 22.3 Chasing HEAD
- 22.4 Running the build locally
- 22.5 Facilitating commits
- 22.6 Powering through broken builds
- 22.7 Shared Nothing
- 22.8 Common code ownership
- 22.9 Always Release Ready
- 22.10 Thin vertical slices
- 23 You’re doing it wrong
- 23.1 Merely naming a branch trunk.
- 23.2 Cherry-pick of bug fixes from release branches to the trunk
- 23.3 Merging rather than cherry-pick to/from a release branch
- 23.4 Duration of ‘short-lived’ feature branches
- 23.5 Numbers of developers on ‘short-lived’ feature branches
- 23.6 Every day not being the same for developers.
- 23.7 Keeping a single release branch
- 23.8 Merge from one release branch to another release branch
- 23.9 Merge everything back from a release branch at the end of the release branch
- 24 Alternative branching models
- 24.1 Modern claimed high-throughput branching models
- 24.2 Legacy branching models
- 24.3 More than one trunk
- 24.4 CI (dis)proof of your branching model
- 25 Monorepos
- 25.1 Third-party dependencies
- 25.2 In-house dependencies
- 25.3 Code Ownership
- 25.4 Directed graph build systems
- 25.5 Recursive build systems
- 25.6 The “diamond dependency problem”
- 25.7 Clash of ideologies
- 25.8 Deciding against a monorepo
- 26 Expanding Contracting Monorepos
- 26.1 Gcheckout.sh
- 26.2 Contrived example of use
- 26.3 Contrived example of use #2
- 26.4 Git’s Sparse checkouts
- 26.5 Perforce’s client-specs
- 26.6 PlasticSCM’s cloaked.conf
- 26.7 Subversion’s sparse-checkouts
- 27 Game Changers
- 27.1 Revision Control System - RCS (1982)
- 27.2 Concurrent Versions System - CVS (1990)
- 27.3 Microsoft Secrets book (1995)
- 27.4 NetScape’s Tinderbox (1997)
- 27.5 Perforce and ClearCase (1998)
- 27.6 Extreme Programming’s Continuous Integration (1999)
- 27.7 Continuous Integration paper on MartinFowler.com (2000)
- 27.8 ThoughtWorks’ Cruise Control (2001)
- 27.9 Apache’s Gump
- 27.10 Subversion’s “lightweight” branching (2000 through 2001)
- 27.11 Git’s “lightweight” branching (2005)
- 27.12 Google’s internal DevOps (2006 onwards)
- 27.13 Branch by Abstraction technique (2007)
- 27.14 GitHub’s entire initial platform (2008)
- 27.15 Continuous Delivery Book (2010)
- 27.16 Travis-CI’s GitHub integration and pass/fail badges (2011)
- 27.17 Microservices (2011 and 2012)
- 27.18 Case Study: A Practical Approach To Large-Scale Agile Development (2012)
- 27.19 TravisCI’s per-commit speculative mergeability analysis (2012)
- 27.20 PlasticSCM’s semantic merge (2013)
- 27.21 Google revealing their Monorepo Trunk (2016)
- 27.22 Microsoft’s Virtual File System for Git (2017)
- 28 Publications
- 28.1 Books promoting Trunk-Based Development
- 28.2 Reports promoting Trunk-Based Development
- 29 Challenge: Identifying bottlenecks
- 29.1 Value Stream Mapping
- 29.2 Current Reality Trees
- 30 Addressing common bottlenecks
- 30.1 Warning: Culture eats strategy for breakfast
- 30.2 Development “cycle time” consideration
- 30.3 Insufficient business analysis.
- 30.4 Testing generally
- 30.5 Builds not speedy enough
- 30.6 Omnipresent compilers
- 30.7 A fast build example in diagrams
- 31 Trunk Correlated Practices: Charting where you are against others
- 31.1 Key to understanding the chart
- 31.2 Goal: Dialing up release cadence
- 31.3 Branching model and Source Organization
- 31.4 Release preparation & Continuous Integration
- 31.5 Code sharing and third party dependencies
- 31.6 Flags, toggles, changes that take a while, and code review
- 31.7 All classes of environment
- 31.8 Quality Assurance / Testing
- 31.9 Shift left
- 31.10 Unit tests followed by integration tests
- 31.11 Test Impact Analysis
- 31.12 Service Virtualization
- 31.13 A bit of ‘shift right’
- 31.14 Database changes and rollbacks
- 31.15 Developer Duties/Attitude/Retention
- 31.16 Talent Retention
- 31.17 Others
- 32 Contributions
- 33 Glossary
- 34 Abbreviations Used in this Publication
- 35 Appendix 1: Different ways of explaining Branch By Abstraction
- 35.1 Explained using UML sequence diagrams
- 35.2 Explained using construction metaphor
- 35.3 Explained using a series of changes to a Java app
- 36 Appendix 2: Visualizing CI & CD
- 36.1 Traditional CI without CD
- 36.2 Continuous Delivery into a QA or UAT environment
- 36.3 Continuous Deployment into Prod
- 36.4 Branch for Release
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 million USDwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
