Continuous delivery

Le contexte

Organisation

L'équipe de développement de LesFurets.com

• 4 feature teams
• 22 développeurs
• 3 devops (automatisation et opération)
• 1 archi-codeur
• 7 business analysts / product owners

Application

Le site est constitué d'une application front et une application backoffice

• 1 code base avec 400k loc
• Java
• 10+ serveurs

2012

L'ancienne organisation en scrum classique

• Sprints d'un mois se terminant par une recette puis mise en production
• Du commit à la MEP : en moyenne 2 semaines
• Build 15 minutes + Selenium 1h

2014

• Livraison de ce qui est prêt
• Du commit à la MEP : en moyenne 5 jours
• Tout le monde fait des MEPs
• Build 3 minutes + Selenium 10 minutes

Quelques lectures

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

Continuous Delivery

Jez Humble

1. Build rapide
2. Build robuste
3. Déploiements simples et automatisés
4. Monitoring de production et alertes
5. Analyse des causes racines

How Google Test Software

James Whitaker, Jason Arbon, Jeff Carollo

• Quality Engineering plutôt que Quality Assurance
• Création d'outils de test pour les dev
• Les dev font la QA eux même

Kanban : Evolutionary change

David Anderson

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

Livrer tôt, livrer souvent

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

Commencer par finir !

Le continuous delivery

• 5. Production & Exploitation
• 4. Mise En Production
• 3. Validation
• 2. Intégration Continue
• 1. Implémentation

5. Production & Exploitation

Monitoring technique

Monitoring fonctionnel

Monitoring Open Space

Alertes & logs

Les logs/traces d'erreurs arrivent par mail à partir de chaque environnement.

• 200 erreurs/jour, dont 20% depuis le JavaScript
• 1 erreur ➜ 1 mail
• 1h synthétisée ➜ 1 mail
• 24h synthétisées ➜ 1 mail

4. Mise en production

Mise en production

Mise en production

Gérée de A à Z par un seul développeur

Automatisation des différentes étapes :

• Création de la Release Candidate
• Déploiement de la Release Candidate
• Merge de la Release Candidate dans le master
• Création et diffusion de la Release Note

Déploiement

Tout le déploiement est fait avec 0 downtime en utilisant un système style blue / green.

• Environnement de production dupliqué
• Loadbalancer en entrée

Déploiement Blue / Green

Infrastructure as code

Toutes les modifications sont historisées
Les bugs de configuration sont des bugs de code

3. Validation

3. Validation

• Tests manuels exploratoires
• 40k JUnit 3 min
• 200 Selenium 10 min
• Code review
• Validation fonctionnelle
• Régressions UI : Zeno

Zeno

Modèle de branches

• Trunk avec branches de maintenance
• Gitflow
• Trunk based deployment

Master + feature branches

2. Intégration continue

• Maven (compile + tests unitaires)
• Selenium
• Environnement de test (dog fooding)
• Mutualisation du code - gestion des conflits

git-octopus

git-Octopus

Continuous merge

• Construction de l'environnement de test
• Détection des conflits entre branches

Les conflits

• Eviter le conflit
• Attendre qu'une branche parte dans le master
• Merger une branche dans l'autre

L'octopus à l'oeuvre

30 branches features et plus !

1. Implémentation

Feature toggles

Livré désactivé

Impacts design

Hardcode anything !

Les Furets @Devoxx

• Continuous Delivery (Conférence)
• Le Continuous Merge (Conférence)
• Zeno Pixel (Tool in action)
• Annotation Processing tool (Quickie)

@BeastieFurets

github.com/lesfurets/lesfurets-conferences

github.com/lesfurets/git-octopus

github.com/lesfurets/zeno-pixel