The document discusses the journey of an insurance comparison website from 10-12 releases per year using a traditional development process to daily releases using a continuous delivery approach. Key aspects of the continuous delivery approach implemented include adopting Kanban workflows, validating and deploying each feature independently with automated deployment scripts, integrating production monitoring, and maintaining a clean codebase. This has allowed the organization to increase release frequency from every 3 weeks to daily while empowering individual developers and teams.

1. From 10 to 500 releases a year,
a Continuous Delivery Journey
DC Continuous Delivery meetup - 09/28/2016
&
* The ferrets

2. #DCCD
Raphael Brugier

3. #DCCD

4. #DCCD
● Insurance comparison website
● Launched 2012
● 3.5M quotes/year

5. #DCCD
IT department - Feature teams
Site conversion
Landing Funnel Panel
Data ArchOps

6. #DCCD
Architecture
● Monolithic Architecture
● Java (tomcat) & JSP / GWT(client)
● 1 codebase
● 500k LOC
● 40k unit tests

7. Journey

8. #DCCD
2012
● 12 developers
● Scrum
● 3 weeks / sprint
● 15-minute build

9. #DCCD
2012 - 12 releases
plan / estimate / code / test / fix

10. #DCCD
Since 2014
● Kanban
● Deliver each feature separately
○ when ready
● One delivery per day
● 3-minute build

11. Fundamentals

12. #DCCD
Agile manifesto #1
“Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software”
www.agilemanifesto.org/principles.html

13. #DCCD
Common patterns
http://paulhammant.com/2013/03/13/facebook-tbd-take-2/

14. #DCCD
● Production monitoring and alerts
● Automated & simple deployment
● Faster and reliable build

15. Step by step

16. #DCCD
Start by the end
5. Ops
4. Deployment
3. Validation
2. Development workflow
1. Implementation

17. 5. Ops

18. #DCCD
5. Ops
Functional monitoring

19. #DCCD
5. Ops
Key metrics

20. 4. Deployment

21. #DCCD
4. Deployment
● Jenkins + Scripts
○ versionned
● 1 developer every day
○ From A to Z
○ Anyone with a ready feature

22. #DCCD
4. Deployment

23. #DCCD
4. Blue/Green Deployment

24. 3. Validation

25. #DCCD
3. Validation
● Each feature on its own branch
● Validate each feature separately
○ Code reviews
○ Demo
○ “Ready for production” status in Jira
● Visual regression tool

26. #DCCD
3. Visual validation - ZENO Pixel
github.com/lesfurets/zeno-pixel

27. 2. Development workflow

28. #DCCD
2. Development workflow
● Git Flow
nvie.com/posts/a-successful-git-branching-model

29. #DCCD

30. Let’s do both!

31. #DCCD
Git octopus - continuous merge
Prod 4.17
github.com/lesfurets/git-octopus

32. #DCCD
Git octopus
Prod 4.17
github.com/lesfurets/git-octopus

33. #DCCD
Git octopus
Prod 4.17
github.com/lesfurets/git-octopus

34. #DCCD
Git octopus
github.com/lesfurets/git-octopus
Prod 4.18

35. DEMO

36. #DCCD
Git octopus in action!
github.com/lesfurets/git-octopus

37. 1. Implementation

38. #DCCD
1. Implementation
● (almost) No feature toggles
● Hardcode anything! (behavior config)
● Force to maintain a clean code base

39. What changed?

40. #DCCD
For the developers
● More responsibilities
○ QA
○ Monitoring
○ Deployment
● Many teams, same codebase
● Less risk

41. #DCCD
For the business
● Manage projects, not teams
● 10 - 15 days
● Faster time to market

42. Take aways

43. @IpponUSA
github.com/ippontech
github.com/lesfurets
@beastiefurets