Trunk-Based Development (TBD) has been practiced on and off by dev teams since the '90s, and is inextricably linked to high-throughput organizations. In this full-day interactive workshop, Paul Hammant, chief documenter of TBD, explains the key aspects of this concept, and will answer questions as the attendees ask them.

The format is directed education on getting a dev group to TBD and higher release cadence from a non-TBD branching model and lower release cadence.

Focus areas include:

  1. moving a hypothetical group from quarterly to monthly release cadence
  2. moving a hypothetical group from monthly to weekly release cadence
  3. moving a hypothetical group from weekly to daily release cadence
  4. daily to many times a day.

Outline/Structure of the Workshop

In a room setup for participation of the attendees, a directed education around the challenges of improving enterprise release cadences using Trunk-Based Development (and CI/CD), that allows for questions and answers as we go. To a great degree the attendees get to steer the day, which is what happens when I visit companies and do the same for them - normally over a few days. Attendee laptops will be for note taking rather than participation in any coding/committing exercise.

Learning Outcome

The attendees will:

  • be educated on the science and rationale for Trunk-Based Development
  • have an idea of the challenges an attempt to improve release cadence may encounter generally.
  • hopefully have identified the immediate bottlenecks they would face were they to attempt such transformation back in their workplace
  • be left with concrete alternatives for how to push through those bottlenecks

Target Audience

Tech Leaders and Engineers interested in getting to Continuous Delivery and/or Trunk-Based Development

Prerequisites for Attendees

  1. Knowledge of source-control systems, branches, commits, and merges. If not as a developer (ideal case), then at least as a tech-educated manager.
  2. An understanding of their employer's branching model and release cadence.
  3. An understanding of a typical day and a typical week for a developer at their enterprise/employer.
  4. Some knowledge of the flow of project work in series (and perhaps in parallel) for multiple dev teams in their organization towards a forthcoming release.
  5. Come with your questions, concerns and doubts, and I'll look to address them during the session.
schedule Submitted 11 months ago