Devoxx france 2015 livrer chaque jour ce qui est prêt

@BeastieFurets#LesFuretsContinuous
Livrer chaque jour
ce qui est prêt
https://www.lesfurets.com
@BeastieFurets
Dimitri BAELI (@dbaeli)
Benjamin DEGERBAIX (@benbaix)

Livrer chaque jour ce qui est prêt
• Contexte
• Points de repère
• Points clés : de la conception à l’exploitation
• Quelques inspirations
2

@YourTwitterHandle@YourTwitterHandle@BeastieFurets#LesFuretsContinous
Contexte

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
Une application front et une application backofﬁce :
• 6 produits :
• Java (tomcat) & GWT (client)
• 400k LOC
• 40k tests unitaires
• 200 tests Selenium

Équipe de développement
• 4 Feature Teams :
➡ 7 Business Analysts / Product Owners
➡ 22 Développeurs
• 2 OPS + 1 QE
• 2 Archi-codeurs

2012
L’ancienne organisation en scrum classique :
• Build : 15 minutes
• 200 Seleniums : 1 heure
• Sprints d’un mois se terminant par une mise en production

Rythme 2012 - Mensuel
12 releases
L’esprit :
planiﬁer / estimer / coder / tester /
liver de manière mensuelle
Sprints

Depuis 2014
L’organisation actuelle :
• Build : 3 minutes
• Seleniums : 10 minutes
• Livraison de ce qui est prêt à J+1

Rythme 2014/15 - Quotidien
208 releases en 2014 (déjà 47 en 2015)
L’esprit :
livrer ce qui est prêt aujourd’hui
… tous les jours !
Marathon

Feature Time To Market
• 2012 :
➡ Du dernier commit à la MEP : en moyenne 2 semaines
➡ Non satisfaisant pour le business
• 2014 :
➡ Du dernier commit à la MEP : en moyenne 2 jours
➡ Quand c’est prêt

Points de repère

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

Livrer tôt, livrer souvent
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 Flow
Un puissant modèle de branches Git
http://nvie.com/posts/a-successful-git-branching-model/

Points clés : de la conception à l’exploitation

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.

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
• Conférence dédiée à Devoxx par Arnaud Pﬂieger

Continuous Merge Octopus

Environnement Stage
• 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

Zeno Pixel
• Outil Open Source de comparaison d’images (perceptual diff)
• Développé en interne chez LesFurets.com :
➡ https://github.com/lesfurets/zeno-pixel
• Conférence dédiée à Devoxx par Matthieu Fourtina

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ées
Les 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é
39

5. Monitoring & Exploitation

Monitoring technique
Sondes Zabbix - 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

Quelques Inspirations

How Google Test Software
• Quality Engineering plutôt que  
Quality Assurance
• Création d’outils de test pour les devs
• Les devs font la QA eux même

Kanban : Evolutionary Change
• Visualisation du travail
• Limiter le travail en cours (WIP)
• Règles explicites
• Amélioration continue
• Leadership

Product Development Flow
• Travailler en ﬂux
• Gérer les ﬁles d’attentes
• Regarder le lead time plutôt que le coût
de développement
• Réduire le coût de livraison

How to measure anything
• Lié à une décision à prendre
• Poser le problème
• Beaucoup plus simple qu’on pense
49

The Phoenix project
• How to avoid experts as SPOF
• DevOps as Business enabler
• Small and motivated teams
• Resilience !
50

On recrute !
http://www.lesfurets.com/nous-rejoindre

Devoxx france 2015 livrer chaque jour ce qui est prêt

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Devoxx france 2015 livrer chaque jour ce qui est prêt

Similaire à Devoxx france 2015 livrer chaque jour ce qui est prêt (20)

Devoxx france 2015 livrer chaque jour ce qui est prêt