De manière générale DevOps est un mouvement ayant pour objectif l’alignement du système d’information sur les besoins de l’entreprise (en se concentrant plus essentiellement sur la partie développement et opérations).
DevOps est un terme issu de la contraction des mots anglais development (développement) et operations (exploitation).
Citation du site http://devops.fr/
Dans cet article je vais vous présenter ma vision de DevOps. Elle n’est sûrement pas complète mais elle permettra je l’espère de démystifier le terme et d’en comprendre le sens principal.
Définition du mouvement DevOps
En regroupant les différents termes de plusieurs définitions données sur le web, voici ce que l’on obtient :
DevOps est :
- un mouvement ;
- une culture ;
- un processus agile sur l’ensemble de la chaîne (du développement à la mise en production)
- une nouvelle approche technique
- une autre approche humaine
- une réponse à de nouvelles problématiques comme le déploiement massif, le déploiement régulier.
Pour résumer on peut dire aussi que le mouvement est également pour ⅓ une affaire d’outils, de code et de processus métiers et pour ⅔ une affaire de culture et de communication.
Bon, ok. DevOps est un mouvement, une culture, un état d’esprit, voire même une religion pour certains, mais en pratique, qu’est ce que c’est ? Nous y reviendrons plus loin dans cet article. Pour comprendre DevOps, et découvrir ses méthodes, processus, et les différents outils utilisés, il faut tout d’abord s’intéresser à son origine. Pourquoi ce mouvement est-il apparu ?
Pourquoi DevOps ?
De nombreuses entreprises (essentiellement les plus grandes) divisent le développement (ceux qui pensent et écrivent le code) et l’administration système (ceux qui déploient et exploitent les applications) entre différents départements / services. Dans ce type d’organisation, les développeurs ne sont pas souvent préoccupés par l’impact de leur code sur la production mais plus par la livraison fréquente de nouvelles fonctionnalités. À l’inverse, le service des opérations de production est plutôt concentré sur la stabilisation des services et de l’architecture ainsi que sur la performance des instances actuelles.
La mise en production est pour beaucoup d’entreprises une étape lourde, compliquée à cause des différentes procédures établies. Les équipes en charge refusent souvent le changement rapide du code (nombreuses livraisons / déploiements). Mais plus il y a de nouvelles fonctionnalités présentes, plus le temps pour la mise en production peut devenir important, plus il y a de chance d’avoir des remontées de bugs bloquants, plus il faudra de tests post-production, etc …. Potentiellement cela implique du temps d’indisponibilité pour l’application, du stress pour les équipes et bien entendu de l’argent perdu.
A l’inverse des équipes de production, les développeurs développent leur code sans la contrainte d’un environnement dit ‘de production’ (plusieurs serveurs, gestion de flux réseaux complexes, configurations différentes, systèmes d’exploitation différents). La plupart du temps, un développeur installe son propre serveur web avec sa configuration habituelle, sa base de donnée habituelle sur son système d’exploitation préféré, etc… Que celui qui n’a jamais eu le problème du ‘ça marche sur ma machine‘ (mais bien entendu pas sur le serveur de recette ou de production) me jette le premier pingouin :).
Même au sein des équipes de développement le problème peut être rencontré. Installation d’Oracle avec une équipe de développeurs sous Mac OSX, Ubuntu, et Windows. Résultat : même code, mais pas un des développeurs n’a réussi à faire fonctionner l’application complète de la même manière !
Le mouvement DevOps tend à essayer de fusionner ces deux mondes que sont l’exploitation et le développement. Chaque monde va apprendre de l’autre et surtout essayer de se comprendre :
-# En facilitant la communication entre les deux mondes (utilisation de méthodes agiles, intercommunication).
-# En industrialisant les processus de livraison (intégration continue, déploiement continu, etc …).
-# En utilisant des outils (Puppet, Chef, Vagrant , fabric, etc …) pour l’industrialisation de l’infrastructure.
Comment être DevOps 😉
Communication, processus et méthodes agiles
Les équipes de développement ont besoin de communiquer avec les équipes opérationnelles. Elles doivent pouvoir adapter rapidement leur environnement de développement et les changements d’architecture sur leur code. De la même manière, lorsqu’une nouvelle fonctionnalité demande un changement d’architecture ou l’installation d’un nouvel environnement et/ou serveur, les équipes opérationnelles se doivent d’être de bon conseil sur la configuration et l’installation. Elles auront souvent une vision plus juste que les développeurs.
Les équipes opérationnelles ont besoin de communiquer avec les équipes de développement qui ont des connaissances sur des outils, des processus qui peuvent aider à rendre les environnements plus facile à gérer, plus efficace et plus propre. Elles ont également besoin de comprendre le besoin applicatif et fonctionnel des développeurs pour permettre une meilleure optimisation des ressources, un meilleur monitoring et une meilleure remontée d’erreur.
Les méthodes agiles ne sont pas réservées uniquement aux équipes de développement mais peuvent aussi être appliquées sur toute la chaîne IT.
Les méthodologies de développement Agile comme Kanban et Scrum peuvent révolutionner les pratiques opérationnelles de la même manière qu’elles ont changé la façon dont les développements s’opèrent.
Prenons l’exemple de l’analyse des problèmes en production qui nécessite une coopération entre les équipes d’exploitation et celles de développement comme la gestion des logs et des exceptions, des outils de concentration et d’analyse de logs. DevOps permet avec les méthodes agiles de gérer sous forme de points les problèmes rencontrés et le partage des informations, des solutions facilitent la résolution des dits problèmes.
L’organisation, bien qu’étant le point le plus complexe à aborder pour l’adoption d’une culture DevOps, n’est pas impossible à mettre en place, même pour de grandes entreprises : Amazon a adopté ce concept, et une devise en est alors ressortie : «You build it, you run it». Le point essentiel pour la communication est de s’assurer que les objectifs soient communs aux différentes parties et se dirigent vers une amélioration de la disponibilité, de la performance et de l’évolutivité des applications.
Industrialisation des processus de livraison
Beaucoup trop d’organisations restent encore sur le cycle : Développement long -> Recette longue -> Livraison douloureuse -> Bugs -> Recettes correctives -> Redéploiement de patch (ouf..) soit par méconnaissance , soit par peur du changement ou par le coût de celui-ci. Ce type de projet avec un planning de livraison à plusieurs mois regroupe souvent un lots de fonctionnalités pour éviter une multitude de déploiement (souvent dûe à la frilosité de la mise en production). On se retrouve alors avec des allers retours dans tous les sens et des attentes dans chaque équipe, ce qui peut créer des groupes (eux / nous) et certaines frustrations (exemple : ça fait deux mois qu’on a fini de développer cette fonctionnalité mais elle n’est toujours pas testée ni livrée en production).
Prenons le postulat de base : »une portion de code qui n’est pas livrée n’apporte aucune valeur ajoutée à l’entreprise ou à l’application ».
Plus les déploiements sont fréquents, plus le processus est maitrisé. Il y a moins de code à livrer, donc moins de risque d’erreur, moins d’impact lors d’un rollback / retour-arrière. De plus, une application avec laquelle on peut rapidement livrer des nouvelles fonctionnalités ou des correctifs de bugs aura un meilleur retour des utilisateurs (plus de réactivité) et donc une meilleure image. C’est là qu’intervient la méthodologie du déploiement continu permettant le déploiement du code de façon rapide et efficace. Pour arriver à une automatisation complète ou quasi-complète de la chaîne de production, plusieurs étapes sont nécessaires :
«Continuous Integration» est le processus d’intégration (génération de code, compilation, exécution des tests unitaires, fonctionnels, ..) à chaque changement d’environnement (source code, os…)
C’est une très bonne pratique de développement qui consiste à utiliser le «développement piloté par les tests (Test driven Development, TDD) » ou à aller encore plus loin en utilisant le »développement piloté par les comportements » (Behavior Driven Development, BDD) pour permettre une couverture améliorée du code et du fonctionnement de l’application. Ces tests sont ensuite exécutés par le serveur d’intégration à chaque évolution de code ou changement de périmètre fonctionnel. Le contrôle et la gestion des résultats (tests, fiabilité, analyse du code) sont à la charge du serveur d’intégration.
«Continuous Delivery» est l’étape suivante et caractérise la possibilité de déployer ses applications à tout moment.
Cette étape est très importante et est dépendante des résultats de l’intégration, si toutes les contraintes sont au vert, le déploiement peut se faire de manière automatisée sur l’environnement cible (recette, pré-production, production).
«Continuous Deployment» est l’ensemble de ces processus et méthodologies permettant le déploiement en continu en production.
Malheureusement, la démarche de déploiement continu est loin d’être simple à mettre en œuvre, car dépendante de tous les acteurs du système d’information de l’entreprise.
Quelques outils DevOps
Les outils jouent un rôle majeur pour industrialiser les processus et la gestion des architectures dans le mouvement DevOps. Voici donc quelques outils (la liste est loin d’être exhaustive) qui vous permettront de vous familiariser avec tous les concepts abordés et qui à mon sens représentent bien le mouvement DevOps :
- Capistrano : outil open source pour exécuter des scripts sur plusieurs serveurs, son utilisation principale est le déploiement d’applications web. Il automatise le processus de déploiement d’une nouvelle version d’une application sur un ou plusieurs serveurs web.
- Liquibase est une librairie open source (Apache 2.0 Licensed) pour versionner et gérer les changements de schéma de base de données.
- Jenkins est une application d’intégration continue qui monitore l’exécution de jobs répétés, comme les builds d’un logiciel ou des tâches automatiques.
- VirtualBox est une solution permettant de monter rapidement des ‘Virtuals Machine’.
- Vagrant est un outil pour construire des VM opérables en VirtualBox via scripting.
- Puppet/ chef permet la gestion de configurations systèmes dynamiques.
Conclusion
Définir le mouvement DevOps n’est pas chose facile. Par contre, définir ce que n’est pas DevOps l’est davantage.
Voici ce qu’il n’est pas :
- un produit ;
- une personne ou une équipe ;
- une recette miracle ;
- une méthodologie stricte, au sens ou il n’y pas de règle prédéfinie mais plus une philosophie de développement.
Maintenant, à vous de vous faire votre propre opinion sur ce mouvement et ce qu’il représente pour vous.
Pour de plus amples informations sur le mouvement DevOps:
