RECIPES FOR CONTINUOUS DELIVERYGurpreet Luthra - Lead Consultant, ThoughtWorks

1

_zenx_

TOPICS

2

• Continuous Integration (CI)

• Continuous Deployment (CD?) / Continuous Delivery (CD)

• Phoenix Servers

• Branching for Release

• Feature Branches

• Trunk Based Development

• Pull Request Model

• Toggles

• Branch by Abstraction & Strangulation

3

CONTINUOUS INTEGRATION

3

CONTINUOUS INTEGRATION

https://www.thoughtworks.com/continuous-integration

4

4

https://www.thoughtworks.com/continuous-integration

THE PRACTICES

5

• Maintain a single source repository

• Automate the build

• Make your build self-testing

• Every commit should build on an integration machine

• Keep the build fast

• Test in a clone of the production environment

• Make it easy for anyone to get the latest executable

• Everyone can see what’s happening

• Automate deployment

HOW TO DO IT

6

• Developers check out code into their private workspaces.

• When done, commit the changes to the repository.

• The CI server monitors the repository and checks out changes when they occur.

• The CI server builds the system and runs unit and integration tests.

• The CI server releases deployable artefacts for testing.

• The CI server assigns a build label to the version of the code it just built.

• The CI server informs the team of the successful build.

TEAM RESPONSIBILITIES

7

• Check in frequently

• Don’t check in broken code

• Don’t check in untested code

• Don’t check in when the build is broken

• Don’t go home after checking in until the system builds

THE UNDERLYING ASSUMPTION

8

• The quality and impact of your CI processes are solely dependant on the quality of your TESTS.

• If you don’t write good quality tests, with reasonable coverage, all the CI infrastructure in the world can’t protect you.

THE UNDERLYING ASSUMPTION

8

• The quality and impact of your CI processes are solely dependant on the quality of your TESTS.

• If you don’t write good quality tests, with reasonable coverage, all the CI infrastructure in the world can’t protect you.

WRITE GOOD TESTS!!!

CONTINUOUS DELIVERY

9

Image from: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

CONTINUOUS DELIVERY

9

Image from: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

PHOENIX SERVERS

10

• Configuration Drift

• Snowflake servers

• No SSH servers

• Immutable Servers

• Phoenix servers

PLEASE READ: http://martinfowler.com/bliki/PhoenixServer.html and http://martinfowler.com/bliki/ImmutableServer.html

VM (OR CONTAINERS) AS BUILD AGENTS

11

SLIDE COPIED FROM: http://decks.eric.pe/pantheon-ci/#9

BUILD AGENTS AS PHONEIX SERVERS

12

BUILD AGENTS AS PHONEIX SERVERS

13

BUILD AGENTS AS PHONEIX SERVERS

14

PHOENIX SERVERS

15

PHOENIX SERVERS

15

Diagram and full article at: https://boxfuse.com/blog/no-ssh

BRANCHING FOR RELEASE

16

Image from: http://paulhammant.com/blog/branch_by_abstraction.html

BRANCHING FOR RELEASE

17

FOR EACH RELEASE HOW MUCH EFFORT DO YOU PUT IN TO CREATE CI PIPELINES ?

FEATURES BRANCHES

18

Image from: http://blogs.riskotech.com/riskfactor/post/An-Alternate-Branching-Strategy.aspx

THE REALITY OF FEATURE BRANCHES

19Image from: http://paulhammant.com/blog/branch_by_abstraction.html

BRANCH TRACKING

20

A GIT BRANCHING MODEL

21

A GIT BRANCHING MODEL

21Image from: http://nvie.com/posts/a-successful-git-branching-model/

TRUNK BASED DEVELOPMENT

22

• Trunk Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control called “trunk” or “mainline”.

• Branches are made only for a release in the shared repository.

• Trunk always stays GREEN.

• Developers never break the build with any commit. Alternatively, broken commits are immediately rolled back. Or such commits may be blocked before being merged with the trunk.

• Developers don’t work in ISOLATION, in their “happy branches” for days. Update your workstation daily!

TRUNK BASED DEVELOPMENT

23

Image from: http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/

PULL REQUEST MODEL

24

master

fork’s master

Fork

branch

feature-1 branchbranch

Raise pull request

Update to latest

Raise pull request

feature-2 branch

review + no mergereview + mergereview + merge

PULL REQUEST MODEL

25

Image from: code.tutsplus.com/tutorials/travis-ci-what-why-how--net-34771

TRUNK BASED DEVELOPMENT

26

Feature branching is a poor man’s modular architecture, instead of building systems with the ability to easily swap in

and out features at runtime/deploy time, you’re coupling yourself to the source control providing this mechanism

through manual merging.

- Daniel Bodart

Mentioned By http://martinfowler.com/bliki/FeatureBranch.html

AND http://sethgoings.com/feature-branching

TRUNK BASED DEVELOPMENT

27

OK. I WILL TRY & AVOID FEATURE BRANCHES. HOW DO I ENSURE I CAN DEVELOP BIG FEATURES, YET, KEEP

TRUNK GREEN & STABLE?

FEATURE TOGGLES

28

• Release Toggles

• Business Toggles

• Build Time Toggles

• Run Time Toggles

• A/B Testing

• Canary Releases

• Rollback in production

PLEASE READ http://martinfowler.com/articles/feature-toggles.html

Pete Hodgson

EXAMPLES

29

• Introduce a simple search box on your home page

• Add a new feature to favorite products + My Favorite page (client side only, nothing on server side)

• Upgrade from Java7 and Java 8 (slowly across servers)

• Improve your search algo (in case it returns no results, then apply, distance algo)

• Change upload logic for images (earlier each image was assigned a thread). New logic: Create a queue, perform a de-dup, assign to a thread, batch size of 5, upload.

• Add FB Integration (FB Like + Count -- pulled from FB)

• Change JS code to use Require.JS for dependencies

• Introduce dependency injection via Spring/Guice

• Change Repository code from Hibernate to Toplink

IMPLEMENTATION

30

• Simple IF statement (top most layer)

• DB / File / Code based configuration

• Polymorphic Substitution / Injection

• Plugin Based / Dynamic JAR Lookup / Discovery

• Hook based extensions

• Toggle Based Frameworks (Use Google!)

• Many more..

BRANCH BY ABSTRACTION

31

BRANCH BY ABSTRACTION

31

BRANCH BY ABSTRACTION

31

BRANCH BY ABSTRACTION

31

BRANCH BY ABSTRACTION

31

IMAGES AND ARTICLE: http://martinfowler.com/bliki/BranchByAbstraction.html

BRANCH BY ABSTRACTION

32

• Technique for making large scale changes in a gradual way

• Use an abstraction layer to allow multiple implementations to co-exist

• Use the notion of one abstraction and multiple implementations to perform the migration from one implementation to the other

• Ensure that the system builds and runs correctly at all times

YES. IT’S JUST GOOD OBJECT ORIENTED DESIGN.

STRANGULATION PATTERN

33

• Slowly strangulate one system for another.

• Slow strangulate one model / one component for another.

PLEASE READ http://agilefromthegroundup.blogspot.in/2011/03/strangulation-pattern-of-choice-for.html

IMAGE FROM: https://dzone.com/articles/legacy-java-applications

WHERE TO NEXT?

34

• Write good tests. Make them blazing fast. Depend on them!

• Commit & push frequently to Trunk. Build should be ALWAYS Green.

• Every morning, pull latest code to your machine.

• Consider using Immutable Servers / Phoenix Servers.

• Figure out creative ways to keep software ready-for-release.

• Plan for rollbacks, or for functionality switches.

• Consider strategies like Toggles or Branch-by-Abstraction.

• Don’t work in ISOLATED branches.

• Be thoughtful in your code… and in your design.

WHERE TO NEXT?

34

• Write good tests. Make them blazing fast. Depend on them!

• Commit & push frequently to Trunk. Build should be ALWAYS Green.

• Every morning, pull latest code to your machine.

• Consider using Immutable Servers / Phoenix Servers.

• Figure out creative ways to keep software ready-for-release.

• Plan for rollbacks, or for functionality switches.

• Consider strategies like Toggles or Branch-by-Abstraction.

• Don’t work in ISOLATED branches.

• Be thoughtful in your code… and in your design.

AIM FOR Continuous Delivery!

THANK YOU

35

Gurpreet Luthra - Lead Consultant, ThoughtWorks_zenx_

Thank you for all your thoughts on CI & CD by Martin Fowler, Paul Hammant, Jez Humble, Pete Hodgson, ThoughtWorkers

and of course Calvin & Hobbes