livrer chaque jour ce qui est prêt chez lesfurets.com v3.1 - ippon 201606

Livrer chaque jour ce qui est prêtContinuous Delivery & Continuous Merge

Le contexteLesFurets.com

http://lesfurets.com

@YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli

1er site indépendant de comparaison d’assurance :

• Lancé en 2012

• 2,5M de devis par an

• 31% du marché de la comparaison de contrats auto


Application

• 6 formulaires complexes

• 50+ partenaires interrogés en temps réel

• Java (tomcat) & GWT (client)

• 400k LOC / 40k tests unitaires / 200 tests Selenium

• Livraison Quotidienne

• 23 Developers

• 6 Tech Leads, 1 Architecte

• 2 Ops

• 1 Manager

@beatiefurets

github.com/lesfurets

http://github.com/lesfurets


Continuous Delivery ?

Livrés en 4 mois par container ! Record à battre :-)

Etre développeurCycle de maturation


1995-1998 Etudiant (ENSIMAG)

▪Code jamais utilisé en production▪Livraison: A la rache▪Code ▪écrit: 1000 lignes/mois▪net: +1000 lignes/mois▪Tests: 3h/mois▪3 lignes / secondes

PRIME A LA FONCTIONALITE


1998-2006 Codeur (Edition logicielle)

▪Livraison: Mensuelle-Annuelle (recette)▪ Code▪ écris 600 lignes/mois▪ ajouté (net): +500 lignes/mois▪utilisé 6-12 mois après finition▪ Tests▪ 40h (1/4 du temps)▪ 4min / ligne

PRIME A LA QUALITE


2006-2011 Développement Agile

▪ Livraison: 15-30 jours (démo global)▪ Code:▪ Ecris: 400 lignes/mois▪ Ajouté (net): +200 lignes/mois▪ Utilisé 1-2 semaines après finition▪ Tests:▪ 40h (5min / ligne)

PRIME A LA LIVRAISON


2011 Lean & Continuous Delivery

▪ Livraison: J+1 (démo unitaire)▪Code▪Ecrit 400 lignes/mois ▪Ajouté (net) +0 lignes/mois (refactoring)▪ Utilisé 1-2 jours après finition▪Test▪40h (5min / ligne)

PRIME A LA VALEUR PRODUITE


2016 Manager

D’une équipe de 25 développeurs

• 12.500 lignes par mois (risque en maintenance)

• Mes Objectifs:

• Rester sous les 1% d’inflation (du code)

• Livrer quand c’est prêt

• Ne travailler que sur le plus utile (priorisation)

• Garder des développeurs impliqués

Continuous DeliveryLa Théorie


Manifeste agile

Principe #1

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

http://agilemanifesto.org/iso/fr/principles.html

http://agilemanifesto.org/iso/fr/principles.html


Livrer tôt, livrer souvent

http://paulhammant.com/2013/03/13/facebook-tbd-take-2/

http://paulhammant.com/2013/03/13/facebook-tbd-take-2/


Continuous Delivery

1. Build rapide

2. Build robuste

3. Déploiements simples et automatisés

4. Monitoring de production et alertes

5. Analyse des causes racines


Git / Git Flow / Github Flow

Git: Un puissant modèle de branches

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

Master

Branch

Pull Request

Github

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

Livrer plus souventRetour d’expérience


Organisation en SCRUM classique :

• Sprints d’un mois, Planification au mois, Recette 1 semaine

• Build : 15 minutes

• 200 Seleniums : 1 heure

• Blocages : Build + Selenium + Recette

2012 : Livraison Mensuelle


2012 : Livraison Mensuelle

Planifier / estimer / coder / tester / livrer de mensuellement

Sprints

12 releases en 2012


• Objectif 2013: livrer plus souvent (hebdo)

• Améliorations:

• Identification de fonctionnalité livrable en avance (cherry pick)

• Build : 3 minutes (contre 15 minutes)

• Blocages:

• Selenium + Recette

• Organisation du code (trunk based dev)

• Cherry Pick sur branche de release

2013 : Livraison Hebdo


2013 : Livraison Hebdo

Planifier / estimer / coder / tester livrer chaque semaine

Sprints 1 mois + Livraison hebdo

@beastiefurets@dbaeli

branch (prod)

trunk trunk

3 - 4 semaines 1 - 4 jours5 jours

Release

Code Freeze

branch


Storie 1

branch (prod)

trunk trunk

Release

Code Freeze

branch



Storie 1

branch (prod)

trunk trunk

Storie 2

Release

Code Freeze

branch



Storie 1

branch (prod)

trunk trunk

Storie 2

Release

Code Freeze

branch


Merge à risque


Storie 1

branch (prod)

trunk trunk

Storie 2

Release

Code Freeze

branch



Storie 1

branch (prod)

trunk trunk

Storie 2

Release

Code Freeze

branch


1 semaine

Storie 3


• Objectif 2014: Livraison journalière

• Améliorations:

• Préparation branche release auto, pas de dev non terminé en release

• Selenium : 10 minutes + Zeno (regressions graphiques)

• Blocages:

• Temps de release (2-3h par 1 dev)

• Risque par release (15jh de travail par release)

2014: Livraison Quotidienne


2014: Livraison Quotidienne

Livrer ce qui est prêt demain … tous les jours !

Marathon

208 releases en 2014 (déjà 150 en 2015)


ticket3

features releaseslocal

ticket3

master

ticket3

master

Le temps de commiter 1 jour à 1 mois 1 - 2 jours

pull requests

0 - 2 jours

release


ticket1

ticket3

ticket4


ticket3

master

ticket3

ticket1

master


pull requests

0 - 2 jours

release


octopus-features

ticket1

ticket3

ticket4


ticket3

master

ticket3

ticket1

master


pull requests

0 - 2 jours

release


ticket1

ticket2

ticket3

ticket4

ticket5


ticket3

master

ticket3

ticket1

master

octopus-features

octopus-releases


pull requests

0 - 2 jours

release


Time To Market

• 2012 :

➡ Début dev à la MEP : Temps dev + 2 semaines

➡ Non satisfaisant pour le business

• 2014 :

➡ Début dev à la MEP : Temps dev + 2 jours

➡ Quand c’est prêt


Vue du métier : 2012

• Mindset “Itération” :

➡ Focalisé sur la date de livraison de l’ensemble

➡ Tendance naturelle à charger

• Mauvaises Surprises :

➡ Pas dans la release = Au min 1 itération d’attente

➡ Demande de livraisons séparées (pour voir l’impact !)

➡ MVP devient naturel pour décider des gros projets


Vue du métier : 2014+

• Mindset “Quand c’est prêt” :

➡ Petit = vite

➡ Tendance naturelle à alléger

• Bonnes Surprises :

➡ Demande de livraisons séparées (pour voir l’impact !)

➡ MVP devient naturel pour décider des gros projets

➡ Pas dans la release = au min +1 jour


Objectif 2016 - Par feature

Livrer ce qui est prêt aujourd’hui … tous les jours !

Marathon

250+ releases en 2015 (déjà 150+ en 2016)


0"

20"

40"

60"

80"

100"

120"

140"

160"

10" 20" 30" 40" 50" 60" 70" 80" 90" 100" 250" 500" 1000" 5000" 5000"

Histogramme"du"nombre"de"modifica<on"des"releases"

Modifications par Releases

Par Release

• 5 - 6 Tickets

• >150 lignes

• Avec des exceptions

Objectif:

• Eviter les commits de >100 lignes


Livraison Continue – Jours / Heures

Retour d’expérienceMise en oeuvre


Améliorer par la fin

5. Monitoring & Exploitation

4. Mise En Production

3. Release Création & Validation

2. Développement

1. Conception

1. Conception


Flux de fonctionnalités

• #1 Fonctionnalités conçues pour être indépendantes

• Livrable dès que c’est prêt

• Découplage des fonctionnalités

• Si dépendant alors attendre ou fusionner

• #2 Fast feedback

• Petites taches vites en production

• Retour chiffré rapide pour prise de décision : stop / cont.


OrganisationPr

iorit

isat

ion

Resource Allocation

Team Team Team

Strategic program initiatives

5% RUN

35% BAU / QUAL

60% BUILD


Flow from Portfolio

2. Développement


Environnement Dev

• Chaque fonctionnalité sur une branche feature dédiée

• Code Production (master) + fonctionnalité uniquement

• Isolation sur le poste de chaque développeur (+ alias DNS)

• Environnements quasi iso Production

• Capacité de se focaliser sur ce développement


Intégration Continue

Feature Branching + Intégration Continue


Intégration Continue

L’intégration continue effectue à chaque commit :

• Compilation

• Tests automatisés

• Merge des features branches (Octopus)

➡ On fait du continuous merge avec l’Octopus


Continuous Merge Octopus

• Outil Open Source de merge en continu

• Développé en interne chez LesFurets.com :

➡ https://github.com/lesfurets/git-octopus

• Il existe une conférence dédiée par Arnaud Pflieger

https://github.com/lesfurets/git-octopus


ticket1

ticket2

ticket3

ticket4

ticket5


ticket3

master

ticket3

ticket1

master

octopus-features

octopus-releases


pull requests

0 - 2 jours

release


Environnement Staging

• Quasi iso environnement de Production

• Regroupement de toutes les features en cours (Octopus)

• Effets de bord des features

• Seleniums sur le regroupement

• Suivi des logs plus facile

3. Release Création & Validation


Création Release Branche

Création entièrement automatisée :

• Regroupement des features prêtes (Octopus)

• Déploiement sur Pre-Prod (quasi iso Prod)

• Validation sur Pre-Prod


Validation Release Branche

Validation à l’aide d’outils manuels et automatiques :

• Tests unites et d’intégration

• Code review

• Validation fonctionnelle (sur env Stage)

• Grid Selenium

• Non régression UI (Zeno)


Grid Selenium on LXC

• 200 Tests Selenium : 6 heures

• Grid Selenium classique : 1heure

• Grid Selenium RamFS : 10 minutes

• 1 Machine OVH, 128 Go RAM, 300 euros/mois

• Détails sur https://github.com/lesfurets/selenium-lxc

https://github.com/lesfurets/selenium-lxc


Zeno Pixel

• Outil Open Source de comparaison d’images (perceptual diff)

• Développé en interne chez LesFurets.com :

➡ https://github.com/lesfurets/zeno-pixel

• Il existe une conférence dédiée par Matthieu Fourtina

https://github.com/lesfurets/zeno-pixel


Zeno Pixel

• Screenshots automatiques des pages du site

• Cross-environment (Stage, Pre-Prod, Prod)

• Cross-device (Desktop, Mobile, Tablet)

• Comparaisons des versions de chaque page

• Calcul des différences graphiques


Zeno Pixel

4. Mise En Production


Mise En Production

• Réalisée de A à Z par un seul développeur

• Automatisée via Jenkins :

➡ Création de la Release Branche

➡ Déploiement de Release Branche

➡ Merge de la Release Branche dans le master

➡ Création et diffusion de la Release Note


Infrastructure As Code

Toutes les modifications de configuration sont historiséesLes bugs de configuration sont des bugs de code


Déploiement

Tout le déploiement est fait avec 0 downtime en utilisant un système Blue / Green


Git Flow Résumé

5. Monitoring & Exploitation


Monitoring technique

Sondes Datadog - Indicateurs techniques


Monitoring fonctionnel

Sondes Zabbix - Indicateurs fonctionnels


Alertes & Logs

Chaque logs/traces d'erreurs arrivent par mail depuis de chaque environnement :

• 200-1000 erreurs / jour, dont 20% depuis le JS

• 1h synthétisée = 1 mail

• 24h synthétisées = 1 mail


Post Mortem

• Work in progress

• Post Mortem sur chaque incident de Production

• Analyse de la cause profonde

• Suivi de résolution de la cause

• Actuellement 5-10 incidents mineurs par mois, ~1 major

Théorie v2Retour d’expérience


Kanban Games

•GetKanban !Découverte des principes Kanban

Contexte : équipe de développement

• KanbanZine !Découverte des principes KanbanContexte : fabrication d’un magazine


LIVRES

• KANBAN by D.Anderson

• PRODUCT DEVELOPMENT FLOW by Don Reinertsen

• LEAN ENTERPRISE by Humble,Molesky,O'Reilly

• KANBAN POUR L’IT by L.Morisseau

• PREMIER KANBAN by J.Boeg

• THIS IS LEAN by N.Modig, P.Ahlstrom

• SLACK by Tom DeMarco

• KANBAN FROM THE INSIDE by M.Burrows


Kanban : Evolutionary Change

•Visualisation du travail

•Limiter le travail en cours (WIP)

•Règles explicites

•Amélioration continue

•Leadership


Product Development Flow

•Travailler en flux

•Gérer les files d’attentes

•Regarder le lead time plutôt que le coût de développement

•Réduire le coût de livraison


The Phoenix project

•How to avoid experts as SPOF

•DevOps as Business enabler

•Small and motivated teams

•Resilience !


How Google Test Software

•Quality Engineering vs Quality Assurance

•Création d’outils de test pour les devs

•Les devs font la QA eux même


How to measure anything

•D’abord identifier la décision à prendre

•Identifier l’information manquante

•Mesurer uniquement cette information

•Beaucoup plus simple qu’on pense


Lean Enterprise

•Orient• Alternative to Command and Control

• Enterprise Portfolio

•Explore Uncertainty• Discover opportunities

•Exploit• Continuous Delivery, Cost of Delay

•Transform• Embrace Lean Thinking, Rethinking the IT Mindset

79

LesFurets.com LeanKanban.fr29, 30 Novembre 2016 www.leankanban.fr

http://lesfurets.com

http://leankanban.fr

http://www.leankanban.fr

@dbaeli@beastiefurets

MERCI !

livrer chaque jour ce qui est prêt chez lesfurets.com v3.1 - ippon 201606

Technology