Les 5 mercenaires du Devops au Devoxx France

Du 18 au 20 avril 2012 s’est tenu la première édition du Devoxx France. A cette occasion, j’ai eu la chance de découvrir le mouvement Devops grâce à la présentation de ses 5 mercenaires que sont :

Devops est une contraction de Développeur et Opérationnel. Ce mouvement tente de réconcilier les développeurs et les opérationnels.

Malgré l’arrivé des méthodologies Agiles dans la plupart des structures, le monde des développeurs et des opérationnels reste scindé en deux. D’un coté, nous avons les développeurs qui fournissent aux opérationnels un « livrables », pendant que les opérationnels tentent de déployer le dit livrable.
Très souvent, la définition du livrable n’est pas la même que l’on se trouve du point de vue du développeur ou de l’opérationnel.
L’une des recommandations du DevOps est de définir un livrable compréhensibles par les deux parties.
Pendant la présentation, les 5 mercenaires nous montrent une forme de livrable depuis un Jenkins. Les livrables sont des packages natifs, des RPMs en l’occurrence.
Cette forme de livrable  :
  • est auto-suffisante
  • peut être facilement déployé
  • peut être rollbacké
  • est archivable
  • est configurable

Dans leur exemple, ils proposent de livrer des RPMs contenant le conteneur Tomcat ainsi que le War de l’application. Cela permet aux développeurs de maintenir une configuration du conteneur répondant aux besoins de leur application.

Une partie du déploiement de l’application peut être configurable et/ou laissée à la main des opérationnels afin de configurer les éléments dédiés aux environnements de production (mot de passe de la base de données, etc…).
Les RPMs peuvent être construits par Jenkins et mis à disposition des opérationnels sur un dépôt Maven.
Les opérationnels peuvent alors aller chercher une version spécifique du livrable pour le déployer, voir même utiliser Jenkins; ou tout autre outil de Build continu.
En allant même un peu plus loin, il est possible de configurer le Jenkins afin de déployer régulièrement l’application. Nous parlons alors de déploiement continu.
Cette approche permet
  • une meilleur entente entre les opérationnels et les développeurs
  • d’améliorer la qualité du livrable
  • d’augmenter la satisfaction des utilisateurs

Cependant, la mise en place de cette recette miracle peut rencontrer quelques difficultés :

  • Une résistance forte du au choc culturel. Toutes les structures ne sont pas prête à accepter une étroite collaboration entre les opérationnels et les développeurs.
  • Généralement, il est fortement recommandé d’avoir une application qui pratique déjà l’intégration continu. Oui, ça peut peut-être faire sourire, mais les applications qui pratiquent l’intégration continue ne sont pas aussi courantes.