Copyright © 2015 SolutionsIQ Inc. All rights reserved.

Branching for CD?Think again !Devesh Chanchlani

Self Introduction

• Passionate Programmer

• Technical Agile Coach with SolutionsIQ

• Coach teams to embrace, scale and sustain XP practices

• Belong to Pune

3

Traditional Branching Strategies

4

Long Lived Feature Branches

Less risk of non-finished changes

» Merging with other Feature branches

» Merging with mainline changes

» Accommodating Refactorings and design improvements

5

Changes being made to the mainline after being reviewed

» Merging issues» Refactoring becomes

challenging» Cannot have CI for each

branch» Sometimes changes are big &

individual commits not stable, that folks simply squash their changes into big commits.

Short Lived Feature Branches

D1D2

D3 D4

6

Another Curious Case

<Footer Content: Presentation Title, Partner Name, Other> 7

8

“Feature branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime / deploytime they couple themselves to the source control providing this mechanism through manual merging.” Dan Bodart

<Footer Content: Presentation Title, Partner Name, Other> 9

Trunk Based Development (TBD)

10

What it means …

All developers commit to a single branch, called trunk, making frequent check-ins.

Branches are created only for Release purpose.

Bugs are always fixed on trunk and then merged with release branch.

Regular developers don’t commit to a release branch.

Release branches are never merged back to trunk.

Release branches are short-lived, frequently being replaced by other release branches.

11

Trunk Based Development Strategies

12

Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-implemented feature on your releases?

13

Feature Toggles

Courtesy: Spotify Labs / Henrik Kniberg

14

Feature Toggle implies …

A configuration file defines a bunch of toggles for various pending features.

These toggles are mostly applied at UIs, from where interaction with the features begins.

For features with no UI, the toggle will be in the app code. In such cases, techniques like polymorphic substitution and dependency injection

should be used to avoid crude conditional tests.

Feature toggles should be removed once the feature is complete.

Pipelines for different permutations of toggles for releases should be setup. If either of the build fails, it implies a bad commit.

15

Feature Toggle types

1. Release – partial features, temporary

2. Business – certain class of users, permanent

3. Runtime – easier rollbacks, run tests with various configurations of features

4. Build – new feature codebase is not compiled

16

Branch by Abstraction

Consumer

Component to be replaced

STEP 1

Consumer

Component to be replaced

Abstraction Layer

STEP 2

Consumer

Old Component

Abstraction Layer

New Component

STEP 3

Consumer

Old Component

Abstraction Layer

New Component

STEP 4

17

TBD Success Stories

18

Facebook's Trunk Based Development

19

Google’s Scaled TBD

20

Google’s Scaled TBD

Deals with enormous codebase which changes at enormous speeds.

Provides extensive tooling to the developers like Pre-commit validations

formal integration/merge/commit itself

have a “Distributed Builds” capability, which Supports “Caches” for leveraging results from previously built modules

Uses “Gerrit“ for code reviews on refs/for/master branch.

Has decided owners for all modules.

Third party dependencies can have only one existing version in the trunk.

Releases are made from branches cut from the trunk

21

Google’s Scaled TBD

Master

Canary

Beta

Dev

Stable

22

What it takes to Deliver Continuously

23

References

Paul Hammant - http://paulhammant.com

Martin Fowler - http://martinfowler.com/bliki/FeatureToggle.html

Carlos Lopes - Multiple projects, different goals, one thing in common: the codebase!

Henrik Kniberg – Engineering at Spotify

Chuck Rossi – The Facebook Release Process

24

Our Customers

25

Thank you!solutionsiq.com