Le printemps des conférences informatiques parisiennes se poursuit, après Devoxx puis le Scrum Day place aux DevopsDays qui ont eu lieu le 18 et le 19 avril dernier.

Le format de ces journées est assez atypique car elles sont découpées en deux parties distinctes :

• Des conférences le matin concernant la culture devops
• Des “open spaces” l’après-midi afin de favoriser les échanges entre les participants.

Différents types de profils étaient présents : les 100% ops qui cherchent à en savoir plus sur le monde du dev, les devops (50% dev, 50% ops) qui viennent parfaire leurs connaissances et trouver de nouvelles idées, les 100% devs qui cherchent quant à eux, à en savoir plus sur le monde des ops (je me range dans cette catégorie). Vous verrez, en lisant la suite, que le contenu de ces deux jours comblera les attentes des différents profils.

Les conférences

1ère présentation : CustomerOps ou le devops appliqué au service client.

Cette première présentation nous explique comment la culture devops permet d’améliorer le service client et la qualité de support chez Datadog. Leur définition du devops tient en 4 éléments :

• Culture – Tous les développeurs se succèdent sur les tâches de support client afin de parfaire leur connaissance du produit.
• Automatisation – Automatiser un maximum de processus pour gagner et réactivité et même pouvoir être pro-actif. Automatiser également les sources de retour d’utilisation de l’application (email, réseaux sociaux etc …)
• Mesure – Utilisation de différentes métriques afin de mesurer tout ce qui se passe sur le produit.
• Partage – Exposer ces métriques

2ème présentation : Améliorer ses développements grâce aux devops

https://speakerdeck.com/skade/how-devops-improved-my-dev

Ici le speaker nous explique avec un cas concret comment la culture devops lui a permis d’améliorer la qualité et l’organisation de ses développements.

Grâce à la communication avec les ops il a pu rendre son application plus maintenable et plus facilement déployable en production.

Il a ensuite insisté sur le besoin d’avoir des métriques et du log dans chacune des applications que l’on développe afin d’avoir un maximum de retour sur son utilisation.

Le dernier point important à ses yeux est la polyvalence des développeurs; ils doivent pouvoir passer facilement d’un rôle de dev front à personne en charge du déploiement de l’application.

3ème présentation : Projet ou produit ?

https://speakerdeck.com/elpicador/how-products-can-improve-projects

Cette présentation nous montre tout d’abord les différences entre un produit (totalement orienté client) et un projet plus géré en fonction de son coût et des délais impartis.

Ensuite le speaker nous présente quels sont à ses yeux les clés du succès d’un produit :

• Construire rapidement un MVP : Minimum Viable Product
• Mesurer en ayant des feedbacks réguliers sur son produit
• Apprendre de ses erreurs afin de construire un produit meilleur

Ces éléments ne sont pas valables seulement pour un produit mais aussi pour un projet : “Think product, do project”

4ème présentation : Transformer des devs en devops

Fabrice Bernhard nous présente les éléments mis en place chez Theodo pour former ses développeurs junior à la culture devops.

La clé est d’intéresser ces nouveaux développeurs aux problématiques des ops en les confrontant à la production et en organisant du “pair devopsing” lors des phases de développement et de déploiement de l’application. Il faut ensuite les sensibiliser à l’utilisation des bons outils (mise en place de bacs à sable pour effectuer des tests) et aux problématiques de performances.

Cependant cela ne fait pas tout et un bon dev ne devient pas devops grâce à des outils. L’expérience et la responsabilité de la plateforme sont des bons leviers pour devenir devops.

5ème présentation : How we release software for gov.uk

Retour d’expérience sur  la “success story” anglaise du moment : la refonte du site du gouvernement.

Tout part d’un rapport intitulé “Revolution not evolution” qui préconise de créer un centre d’excellence pour rationaliser les services existants puis mettre en place les nouveaux services numériques du gouvernement. S’en suit une une accélération des cycles de livraison (4h pour envoyer un développement en production, 20 déploiements par jour),  une simplification des interfaces, une plus grande transparence (publication sur GitHub, ouverture des API), une refonte graphique (titre de “Design of the year 2013”). Leur mot d’ordre pour développer ce site est “digital services so good that people prefer to use them”.

Le site est effectivement, clair, pratique et utilisable depuis d’autres applications car toutes les données sont accessibles via une API ou en JSON. Exemple de question simple d’utilisation : Quand s’effectue le prochain changement d’heure ? https://www.gov.uk/when-do-the-clocks-change ou https://www.gov.uk/when-do-the-clocks-change.json

Toujours dans un esprit de transparence et de partage leur façon de travailler est expliquée sur ce même site : https://www.gov.uk/service-manual

6ème présentation : Map & Territory: A story of visibility

Cette présentation part du principe qu’une fois un produit ou projet en production on passe la majeure partie de son temps à effectuer des corrections. Si l’on veut réduire ces temps de corrections on a besoin d’extraire des informations qui ont un sens depuis des sources de données hétérogènes (logs, base de données, …). Ces informations nous permettront de mieux comprendre l’utilisation faite du produit.

Avant de les extraire il faut définir des métriques clés qui indiqueront quels sont les éléments à surveiller aussi bien techniques que métiers.

Le speaker explique ensuite l’approche “event stream” : “Plenty of small producers, few big consumers”. Tout ce qui bouge doit être loggé pour être ensuite agrégé puis corrélé avec les autres métriques. Suite à cela, une décision peut être prise sur le plan d’action à mener pour corriger ou enrichir une fonctionnalité.

L’ensemble de ces métriques forme donc une carte de l’application qui nous permet de surveiller le territoire (application).

7ème présentation : Les 10 pièges à éviter lors d’une transition devops

Dans cette présentation les speakers nous indiquent les pièges dans lesquels il ne faut pas tomber lors de la mise en place d’une approche devops dans un projet.

Ces quelques conseils résument bien l’ensemble de ces deux jours :

• Devops ce n’est pas que de l’outillage mais un ensemble outil + processus + culture

• Il ne faut pas penser qu’au déploiement de l’application mais plutôt à la vie de l’application dans son ensemble.

• Il ne suffit pas de désigner des équipes devops, la transition doit être faite par les équipes elles même. L’utilisation d’un coach Devops peut être nécessaire pour les aider.

• Les aspects culturels ne sont pas à négliger et certains éléments de la transition agile peuvent être utilisés :

• Amélioration continue

• Collaboration entre les équipes

• Transparence

• Il faut mesurer un maximum de choses afin d’évaluer les progrès effectués

• Ne pas oublier l’amélioration continue

Suite aux conférences quelques Ignite Talks (présentations de 5 min chronométrées) ont eu lieu. Dur de creuser un sujet en ce court laps de temps mais quelques slides sympas :

• Si Devops avait été inventé par Coca-Cola : http://www.slideshare.net/devopsdays/what-if-devops-was-invented-by-coca-cola
• Tests de performance en continue : http://devopsdays.org/events/2013-paris/proposals/PerformancesPerpetuellesIgnite/

Les openspaces

Les openspaces sont des espaces de discussion libres où les règles suivantes s’appliquent :

• Les personnes qui se présentent, sont les bonnes.
• Ce qui arrive, est la seule chose qui pouvait arriver.
• Ça commence quand ça commence.
• Quand c’est fini, c’est fini.

Les thèmes des différents openspaces sont proposés au préalable par les personnes présentes aux DevopsDays, puis chacun s’inscrit aux discussions de son choix. Les participants aux openspaces ne sont pas obligés de rester tout le long de la discussion et sont même invités à aller de salle en salle pour assister à différentes discussions.

Ce format est assez intéressant car il permet de recueillir et d’échanger rapidement et facilement des idées assez variées sur un même sujet. Cependant les discussions étaient parfois décousues ou s’éloignaient assez rapidement du sujet de base. Dur pour un pur dev de rentrer dans certaines discussions mais néanmoins quelques discussions intéressantes où l’on sentait que les ops veulent mieux comprendre le monde des devs afin d’améliorer la qualité de leur travail et inversement.

Conclusion

Ces deux jours ont été très intéressants et plutôt surprenants. Je m’étais préparé (man page sur les genoux) à assister à des conférences très techniques qui parleraient de virtualisation, de configuration réseaux, de scripts de déploiement, etc … Pas du tout, les conférences étaient parfaitement accessibles et très orientées cycle de vie du projet.

L’élément le plus souvent cité est le fait de mesurer un maximum de choses sur une application. De ces mesures découleront un meilleur retour sur l’utilisation et une meilleure réactivité des équipes en charge de la maintenance du produit.

D’autres éléments présentés rejoignent aussi des arguments déjà entendus dans des conférences agiles : améliorer la communication entre les équipes, réduire les silos, apprendre en continue de ses erreurs, chercher à s’améliorer, partager ses connaissances, …

Suite à ce printemps de l’informatique, on se rapproche donc tout doucement de la recette magique pour développer rapidement une application de qualité : des équipes impliquées, une grande dose de communication, une cuillère d’agilité le tout agrémenté de métriques permettant d’avoir un retour constant.

En bonus quelques bons mots des devopsdays :

“I don’t want to be woken up at night, so I call myself a developper”, Florian Gilcher

“Speed is important but momentum is everything”, Kushal Pisavadia

“It’s not the big that eat the small, it’s the fast that eat the slow”, Fabrice Bernhard

“Think product, do project”, Rémy-Christophe Schermesser