DevOps, culture, pratiques et processus : le guide complet !

Introduction

L’une des pratiques les plus importantes dans le développement logiciel, est l’organisation en tant qu’individus ou équipe pour la réalisation de ce projet. Plusieurs travaux on était faits pour perfectionner ce processus avec comme but de maximiser les performances et la fiabilité du logiciel en minimisant le temps et le budget de réalisation et de maintenance, tout en restant fidèle aux demandes du client. 

Les entreprises utilisent souvent des modèles spécifiques lors du développement tel que le modèle en cascade, le modèle en V, le modèle en spirale et les méthodes agiles (et tant d’autres) pour perfectionner le processus de développement logiciel. Une grande partie de l’effet de ces outils et logiciels dépend de l’utilisation des bonnes méthodes de développement et d’implémentation

Le génie logiciel est la science dédiée à élaborer ces différentes méthodes et pratiques. Le génie logiciel a beaucoup évolué ces dernières années, avec les travaux de recherche, les contributions des ingénieurs et les retours d’expérience.

Dans cet article nous allons discuter d’un cousin plus récent des méthodes agiles et Lean : le DevOps. Définition, philosophie, bonnes pratiques, outils et avantages : qu’est-ce que le DevOps peut apporter à vos projets et à votre entreprise ?

DevOps, c’est quoi au juste ? 

DevOps est une philosophie et un ensemble de pratiques axées sur l’agilité, la collaboration et l’automatisation des processus des équipes de développement et d’opération. 

Concrètement, sur le terrain, il faut des personnes (Dev et Ops), qui sont prêtes à collaborer ensemble en suivant une certaine méthode comme une seule équipe même si les rôles sont différents (Dev et Ops), avec les mêmes objectifs et en s’appuyant sur un panel d’outils. Le but principal du DevOps est de rapprocher les équipes de développement et d’opération pour une meilleure collaboration et moins d’inconsistances entre les équipes. 

Les principes du DevOps

L’acronyme CAMS regroupe les principes essentiels du DevOps :

Culture : le DevOps est avant tout une culture et une philosophie qui consiste à mettre en place un terrain de collaboration entre les équipes du développement logiciel et ceux des opérations d’infrastructure. 

Automating (automatisation) : l’automatisation est un aspect majeur du DevOps. Qu’elle soit dans le développement, le déploiement ou la configuration, elle apporte une grande facilité si elle es utilisée de façon efficace et au bon endroit.

Measurement (mesure) : pour avoir les meilleures performances il faut déjà savoir mesurer l’existant. Avoir les bonnes métriques est primordiale pour toute évolution.     

Sharing (partage) : un point très important est celui de capturer le savoir et de le partager. C’est un principe tout autant crucial que les trois précédents. Il permet de développer l’intelligence collective et d’ajouter de la transparence. Ainsi l’entreprise ne dépendra de personne en particulier. Il se concrétise par le partage des feedbacks, des techniques et des bonnes pratiques. 

Les pratiques DevOps

Contrôle du code source (SCM – Source Code Management ou VSC – Version Control Systems)

Le contrôle du code source est un moyen pour garder trace et historiser les changements apportés à un code source et de collaborer sur ce dernier. 

C’est un élément essentiel pour le développement en général et indispensable pour le DevOps en particulier. Le contrôle du code source permet d’avancer rapidement et intelligemment. Il protège notamment le code source des dommages soudains, des erreurs humaines et des différents conflits. 

Git

Git est un contrôleur de code source gratuit et open source. Il est nettement plus rapide que beaucoup d’autres logiciels de contrôle du code source. Il assure parfaitement les fonctionnalités nécessaires à un VSC qui sont : 

• Un historique complet des modifications à long terme de chaque fichier : chaque changement (création, modification ou suppression) dans chaque fichier est historisé et stocké avec les auteurs de ces changements. 

• Branching et  merging : sont très efficaces pour la collaboration et l’introduction de nouvelles fonctionnalités.
• La traçabilité : pouvoir retracer chaque modification apportée au code. Mais aussi avoir la possibilité de le connecter à un logiciel de gestion de projets et de suivi des bugs. 

D’autres VSC sont CVS, SVN, Mercurial et Monotone 

Git est utilisé souvent avec des services d’hébergement de répertoire. Ce sont des serveurs qui exécutent Git. Ils permettent de suivre et de partager vos projets de contrôle de versions Git en dehors de votre ordinateur/serveur local. Les plus populaires sont : GitHub, GitLab, Beanstalk, AWS CodeCommit et Bitbucket. 

Si vous travailliez avec un langage comme java, vous aurez besoin de versionner vos artefacts. Git est dédié au fichier texte, dans ce cas il n’est pas la meilleure option. Il existe des outils plus spécifiques appelés Artifact Repositories. Ces outils stockent les artefacts binaires avec les métadonnées qui les décrivent et quelques informations supplémentaires comme les dépendances, leurs versions, etc. 

Exemple d’Artifact Repositories : Sonatype Nexus, JFrog Artifactory. 

Tests continus

À chaque nouvelle version de code, on exécute une série de tests pour avoir des feedbacks le plus rapidement possible. Cela permet de vérifier la validité et la qualité du code. Le but est d’éviter toutes sortes de bugs ou problèmes dans l’environnement de production qui peut être très couteux.   

Trois catégories de tests se distinguent

• Fonctionnels :  ils permettent de tester l’aspect fonctionnel de l’application et regroupent essentiellement :  
  • Les tests unitaires pour tester le fonctionnement des modules d’une application de façon isolée, sans interdépendance avec d’autres modules
  • Les tests d’intégration pour tester le fonctionnement des modules en tant qu’ensemble
  • Les tests d’acceptation par l’utilisateur, durant lesquels l’utilisateur final ou le client consulte les changements apportés par l’équipe. Suite à cela, il vérifie et accepte ces changements avant de les mettre dans l’environnement de production.

• Les tests non fonctionnels : ils visent à déterminer les performances et l’endurance du système, sa fiabilité et sa stabilité dans des conditions de charge de travail variables. 

• Les tests de maintenance.  

Exemple d’outils de tests les plus utilisé : JUnit, Jmeter, Selenium. 

Intégration continue (continuous integration) 

Introduite en premier lieu dans la méthodologie eXtreme Programming (XP) et d’autres méthodologies agiles. Sa définition clairement formulée est souvent attribuée à Martin Fowler : “ une pratique de développement de logiciels où les membres d’une équipe intègrent leur travail fréquemment, généralement chaque personne intègre au moins quotidiennement. Ce qui conduit à de multiples intégrations par jour ” (Fowler 2006). 

La meilleure façon de comprendre ce concept est de décortiquer son nom. La CI est avant tout continue. Cela signifie qu’il ne peut s’agir d’un processus manuel. L’intégration signifie l’intégration du code et l’intégration des fonctionnalités. Il s’agit du processus consistant à combiner les mises à jour dans une base de code existant. Plus important encore, tester ces changements afin de ne pas introduire de nouveaux bugs.  Donc pour résumer la CI est une philosophie qui consiste à travailler avec les sources de contrôle où les changements sont souvent. Et pour chaque changement introduit une série de tests s’exécute pour le valider. 

Les solutions les plus populaires sont Jenkins, GitLab-Ci, Travis-CI, CircleCI 

Livraison continue (continuous delivery)

Se base sur l’intégration continue, ou chaque changement devient candidat d’être en production. Un pipeline d’intégration évalue le code, pour qu’ensuite on pourra potentiellement le déployer chez les clients.

Déploiement continue (continuous deployment) 

Ce n’est que la livraison continue avec plus d’automatisation. Les utilisateurs finaux en production reçoivent directement les changements apportés au code. Il n’y a aucune intervention humaine. Seuls les tests ratés peuvent empêcher une nouvelle modification d’être mise en production.

Monitoring continue (continus monitoring) 

Un processus automatisé par lequel le personnel DevOps peut observer et détecter les problèmes de conformité et les menaces pour la sécurité au cours de chaque phase du pipeline DevOps. 

Il aide les équipes ou les organisations à surveiller, détecter et étudier les principales mesures pertinentes, et à trouver des moyens de résoudre les problèmes en temps réel. 

Le continus monitoring se faite à trois niveaux différents : 

• Monitoring de l’infrastructure : surveille et gère l’infrastructure informatique nécessaire à la fourniture de produits et de services. Cela comprend les data centers, les réseaux, le matériel, les logiciels, les serveurs, le stockage, etc. La surveillance de l’infrastructure rassemble et examine les données de l’écosystème informatique afin d’améliorer autant que possible les performances des produits.
• Monitoring des applications : surveille les performances du logiciel publié en se basant sur des mesures telles que le temps de fonctionnement, le temps et le volume des transactions, les réponses du système, les réponses de l’API et la stabilité générale du backend et du frontend. 
• Monitoring du réseau : Surveille et suit l’activité du réseau, notamment l’état et le fonctionnement des pare-feu, des routeurs, des commutateurs, des serveurs, des machines virtuelles, etc. La surveillance du réseau détecte les problèmes éventuels et actuels et alerte le personnel concerné. Son objectif principal est de prévenir les temps d’arrêt et les pannes du réseau. 

Outils de monitoring : Sensu, PagerDuty, Datical Deployment Monitoring Console, Splunk. 

Git workflow

Une des pratiques les plus importantes dans le DevOps est d’avoir une stratégie solide pour la gestion du flux Git. Donc avant de commencer n’importe quel projet pensé à choisir une bonne stratégie avec votre équipe pour l’adopter lors du développement et la soumission des changements à votre répertoire git. Cela vous fera gagner en productivité, en organisation et vous évitera un grand mal de résolution des conflits. 

Un bon exemple d’un workflow solide et complet est d’utiliser :  

• Plusieurs branches de fonctionnalité (feauture branches) : à chaque développement d’une nouvelle fonctionnalité, le développeur crée une nouvelle branche. Cela évitera les conflits avec les codes des autres développeurs lors de la soumission au répertoire Git. 
• Développement (develop branch ou quality assurance) : quand les développeurs terminent avec une fonctionnalité ils l’intègrent (merge) avec la branche develop. Cela leur donne posibilité de tester leurs avec les autres fonctionnalités récemment ajoutées. 
• Délivrance (release branch ou stagging) : après l’ajout de plusieurs fonctionnalités, leurs documentations et régler tous les bugs qui lui sont relatifs, on intègre les changements de la branche develop à la branche release. Cela donnera une version « candidate » pour l’environnement de production. L’environnement lié à la branche délivrance est très similaire à l’environnement de production (ex : utiliser une base de données avec des données réelles, copiées depuis la base de l’environnement prod), ce qui permet de faire des teste plus poussés et plus réels.
• Production (généralement master branch) : cette branche contient le code responsable de répondre aux requêtes de vos clients finaux. Tirée directement d’une version release après que cette dernière et juger apte pour l’environnement de production. 
• Correctifs (hotfix): utilisée uniquement lorsque vous devez rapidement corriger un problème de production. L’avantage de cette branche est qu’elle vous permet de déployer rapidement une solution d’un problème en production sans perturber le flux de travail des autres ou sans devoir attendre le prochain cycle de publication. Créée depuis la branche master et directement intégrée avec la branche master après les changements.

Ce workflow reste qu’un exemple d’utilisation, vous pouvez l’ajuster en ajoutant ou supprimant des branches selon votre contexte (taille du projet, taille de l’équipe, le sujet traité et l’impact d’erreurs … etc.) et vos besoins. 

Cloud

Le Cloud Computing se définit comme l’externalisation de données sur des serveurs distants. En clair, vos fichiers en plus d’etre stockés et traités sur un poste local, ils le sont aussi dans ensemble de serveurs distant. Cette technologie permet une grande capacité de calcul et de stockage, une meilleure disponibilité (mise à l’échelle, réplications de données), en plus une facturation selon l’utilisation, donc on ne paye que ce qu’on consomme, ce qui permet de réduire les coûts.ce qui permet de réduire les coûts. 

Afin de pouvoir utiliser au mieux les pratiques DevOps, les entreprises tendent à passer des infrastructures de serveurs sur site (on-premise) à l’ancienne à des solutions basées sur le cloud. La nature centralisée de cette dernière s’intègre parfaitement avec l’automatisation DevOps et réduit la complexité des systèmes distribués (éliminer les opérations de gestion des serveurs, offre des outils d’automatisation et de monitoring). 

Même si l’utilisation d’une infrastructure cloud a énormément davantage, elle reste “non-essentiel” et les pratiques DevOps peuvent très bien s’appliquer sur une architecture sur site.

Les cloud provider qui ont la plus grande part du marché sont : AWS (Amazon Web Services), Microsoft Azure, GCP (Google cloud Provider). 

Infrastructure en tant que code (IaC – Infrastructure as a Code) 

Un autre grand avantage d’utilisation du cloud dans le DevOps, est qu’il nous donne la possibilité gérée et de provisionner notre infrastructure en utilisant du code plutôt que par des processus manuels, grâce aux outils IaC.

Avec l’IaC, vous utilisez des fichiers de configuration contenant les spécifications de votre infrastructure pour la provisionner. Cela facilite ensuite la modification et la distribution des configurations de façon automatique. Il permet également de garantir que vous provisionnez le même environnement à chaque fois.  

Quelques Solutions : Terraform, Ansible, Chef, Puppet. 

Architecture micro-services

Pour pouvoir profiter pleinement des avantages du cloud, on doit concevoir nos applications de façon qu’elle puisse être scalable (peuvent s’étendre sur plusieurs ressources), alors que les applications généralement sont conçues sur une architecture monolithique très difficilement scalable. C’est ainsi que l’architecture micro-services est apparue, apportant une solution efficace au problème de scalabilité. 

Les micro-services sont une approche qui découpe un grand problème en petites unités implémentées sous forme de micro-services. Ces micro-services sont responsables d’une fonctionnalité, parfaitement autonomes (leurs propres bases de données, leurs propres serveurs d’applications … etc.), séparément développés, testés et déployés des autres. 

On peut utiliser des technologies différentes pour le développement des micro-services (Java, NodeJs, .NET, etc.), l’essentiel c’est qu’ils exposent une API REST. 

L’échange de données effectué à travers les différentes APIs qu’ils exposent est la seule relation entre les différents micro-services.

Lorsqu’on les combine, ces micro-services peuvent réaliser des opérations très complexes. 

Les micro-services offrent également une meilleure isolation des pannes. Ainsi, en cas d’erreur dans un service, l’ensemble de l’application ne s’arrête pas nécessairement de fonctionner. Après avoir corrigé l’erreur, on déploie le correctif uniquement dans le service concerné au lieu de redéployer entièrement l’application.

Conteneurisation

Se définit comme une forme de virtualisation du système d’exploitation, par laquelle l’application s’execute dans un espace utilisateur isolé du système hôte (OS) appelé conteneur. Un conteneur est essentiellement un environnement informatique entièrement packagé et portable. Tout ce dont une application a besoin pour fonctionner (ses binaires, bibliothèques, fichiers de configuration et dépendances … etc.) est encapsulé et isolé dans son conteneur. 

La plupart du temps chaque micro-service est dans un container. Ce qui donne une indépendance totale vis-à-vis de la machine sur laquelle ils tournent. 

Technologies : Docker (leadeur absolue), Rkt, LXD, OpenVZ, Windows Containers. 

Orchestration de container  

L’orchestration des conteneurs automatise le déploiement, la gestion, la mise à l’échelle, l’équilibrage de charge entre les micro-services, le monitoring et la configuration réseau des conteneurs. 

L’orchestration de conteneurs peut être utilisée dans tout environnement où vous utilisez des conteneurs. Elle peut vous aider à déployer la même application dans différents environnements sans avoir à la reconcevoir. 

Solutions : Kubernetes, Docker Swarm, Nomad, Apache Mesos. 

Processus DevOps : 

Le processus DevOps résume l’utilisation des pratiques et outils DevOps par les étapes suivantes : 

• Planifier : au début d’un projet, d’un sprint/itération ou d’une journée on fait la planification la hiérarchisation. Cela permet de s’assurer que tous les membres de l’équipe comprennent les objectifs actuels et de définir le travail attendu. 
• Coder : les développeurs créent et soumettent des modifications ou des ajouts au code qui répondent aux tâches définies pour l’itération en cours. Cette étape comprend également la révision du code et les clarifications ou ajustements nécessaires. 

• Build : compilation, test et mise en package du code soumis au VSC. 
• Tester : les builds réussis sont soumis à une série de tests pour garantir la fonctionnalité, la qualité et souvent la sécurité. Idéalement, les tests les plus rapides ou les plus critiques sont effectués en premier. De cette façon, si un test échoue, la modification du code à l’origine de l’échec peut être renvoyée aux développeurs instantanément, et moins d’efforts seront gaspillés. Si tous les tests réussissent, le build est transmis à la livraison et les modifications sont fusionnées dans la branche de code principale. Cela garantit que tous les développeurs continuent à travailler à partir de la même base.  
• Livrer : on conserve la dernière version réussie est conservée et mise à disposition pour le déploiement. 
• Déployer : un build peut être déployé dans un environnement de test pour des tests supplémentaires (ex : tests d’acceptation par l’utilisateur). Il peut également être livré à des environnements de production ou de mise à disposition pour le déploiement. 
• Opérer/configurer l’infrastructure : Les Ops construisent ou maintiennent une infrastructure évolutive, en utilisant l’IaC et vérifient les problèmes de sécurité en plus de la gestion des journaux. 

• Monitoring : après la mise en production, l’application est contrôlée pour intervenir en cas de problèmes détectés.

L’ingénieur DevOps 

L’ingénieur DevOps est essentiel au succès de DevOps. Son rôle consiste essentiellement à améliorer et à maintenir le cycle de vie du développement logiciel.  

L’ingénieur DevOps est un polyvalent de l’informatique qui doit avoir une connaissance étendue dans le développement et les opérations, y compris le codage, la gestion de l’infrastructure, l’administration des systèmes et les chaînes d’outils DevOps. Les ingénieurs DevOps doivent également posséder des compétences interpersonnelles, car ils travaillent au-delà des silos de l’entreprise pour créer un environnement plus collaboratif.  

« Vous devez constamment lire des articles techniques, consulter les versions et les mises à jour d’AWS, par exemple. Vous devez vraiment vous tenir au courant de ce qui se passe, car de nouveaux outils sortent tous les jours. Si vous ne les connaissez pas, vous ne les utiliserez pas et vous ne mettrez pas en place le meilleur processus DevOps pour votre entreprise », explique Mark Quinn, directeur de l’ingénierie chez Mojo Mortgages.  

Conclusion 

DevOps est avant tout une question d’individus et de culture. Si on ne travaille pas sur cet aspect de la manière appropriée, on ne peut rien accomplir de spécial. L’objectif principal est de permettre aux personnes et aux équipes de ressentir le confort de pouvoir ajouter de la valeur à l’organisation d’une manière innovante sans se soucier d’avoir tort ou de faire des erreurs. Il s’agit d’une culture d’expérimentation et d’apprentissage continu. Ensuite vous choisissez les meilleurs outils adaptés à cette philosophie pour réaliser au mieux vos objectifs.