DevOps @ Devoxx

J'ai eu la chance de pouvoir assister à la présentation "Les 5 mercenaires du DevOps", qui s'est tenue à l'occasion de Devoxx 2012.

Dans une très bonne ambiance, les animateurs de la session nous ont dressé un tableau très pertinent de ce qui se cache derrière le terme DevOps, agrémenté d'illustrations très pratiques. Pour ceux qui ont raté cet événement, voici ce que j'en ai retenu.

1. DevOps, kézaco?

Le terme DevOps mérite une petite explication. Dans le développement d'une application ou d'un logiciel, trois acteurs principaux sont impliqués :

- le business (le biz) : c'est le client (ou les utilisateurs)

- les développeurs (le dev) : les réalisateurs du projet ou du produit

- les opérations (les ops) : les personnes qui assurent son fonctionnement opérationnel.

Le terme DevOps désigne le point de rencontre entre le monde des développeurs et celui des opérations.

2. C'est quoi le problème?

Si vous faites partie du monde des Dev ou du monde des Ops, cette question ne vous surprend pas... Disons qu'il est difficile pour les uns et les autres de se comprendre, parce que leurs besoins sont presque antinomiques :

- les développeurs cherchent à délivrer des fonctionnalités nouvelles toujours plus rapidement

- les opérationnels cherchent la stabilité et la performance.

De plus, le dialogue est souvent perturbé par le fait que les développeurs se contentent de livrer des éléments de l'application, parfois avec une documentation (in)complète - et complexe - que les opérationnels peinent à installer. Et dans l'autre sens, les opérationnels ne savent pas quelles informations fournir aux développeurs pour les aider à reproduire ou à comprendre des dysfonctionnements de l'application.

3. Et l' intégration continue, c'est pas fait pour ça?

L'intégration continue c'est bien. Mais c'est surtout fait pour améliorer le travail des développeurs et la qualité de leurs livrables. Mais ça ne résout pas le problème de "qu'est-ce qu'un livrable"? Pour le développeur, c'est souvent un jar, ou un war, accompagné d'une bonne documentation d'installation. L'opérationnel, lui, préfèrerait un rpm, incluant les écrans de paramétrage spécifique et les procédures de migration et de rollback, au cas où...

Donc, si une intégration continue est nécessaire pour adresser les problématiques DevOps, elle n'est pas suffisante. Il faut combler l'espace entre ce que le développeur considère comme étant un livrable (le war), et ce que l'opérationnel considère comme étant un input (le rpm).

4. DevOps, c'est des outils?

Oui. Mais pas que.

DevOps c'est avant tout une philosophie, une volonté. Un peu comme l'agilité qui, elle, a permis d'améliorer le dialogue et la collaboration entre les deux premiers maillons de la chaine, le biz et le dev (mais bon... agile, ça sonne quand même mieux que BizDev!).

Mais, comme il est très difficile de faire du SCRUM sans outil, DevOps a aussi besoin d'un outillage adapté.

5. OK, je suis convaincu. De quels outils ai-je besoin?

On peut considérer que l'outillage utilisé pour l'intégration continue se prête bien à la mise en place de DevOps. Notamment :

- une repository d'artefacts qui permettra d'échanger les packages de livraison entre l'équipe de développement et celle d'exploitation.

- un moteur d'intégration continue qui permettra d'automatiser les jobs de déploiement pour une mise en production ou une livraison aux équipes de tests sans soucis.

L'outillage à adopter dépend de votre budget. Mais parmi les solutions les plus populaires on peut citer :

- SVN ou git pour la gestion de configuration

- Nexus, Archiva ou Artifactory pour la repository d'artefacts

- Bamboo, Teamcity ou Jenkins pour le moteur (de l'avis des animateurs, Bamboo et Teamcity sont plus avancés que Jenkins, mais ils ne sont pas gratuits...). On peut imaginer un moteur pour le développement, un pour la QA et un pour les Ops.

- Fisheye, Crucible pour la collaboration autour des sources et des packages

- Confluence pour la collaboration au sens large

DevOps se justifiant également pour le dialogue entre le développement et les équipes qualité, on peut ajouter à cette liste Sonar pour la validation du code.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.