Articles
Tutoriels
Guides interactifs
Comment appliquer DevOps
Un guide pas-à-pas pour les équipes qui souhaitent implémenter DevOps
Warren Marusiak
Senior Technical Evangelist
Votre cycle de vie de développement (SDLC) ressemble-t-il à un amas confus d'outils et de workflows ? Vos équipes et vos projets sont-ils cloisonnés ? Si vous avez répondu à ces deux questions par l'affirmative, il est grand temps d'envisager DevOps. DevOps permet de simplifier et d'optimiser les workflows de développement et de déploiement en créant un écosystème de développement logiciel.
Mais comment implémenter DevOps ? L'un des principaux défis posés par cette solution réside dans le fait qu'il n'existe aucun processus standard, car chaque équipe a des besoins et des objectifs différents. Le grand nombre d'outils et de ressources DevOps peut entraîner une « paralysie de l'analyse » et freiner ainsi l'adoption. Les étapes ci-dessous peuvent aider votre équipe à implémenter DevOps.
Pourquoi DevOps ?
En bref, DevOps améliore la productivité en permettant aux développeurs de faire ce qu'ils font de mieux : développer de fantastiques logiciels au lieu d'effectuer manuellement des tâches à faible valeur ajoutée, comme la vérification des fichiers journaux. Les pratiques DevOps automatisent les tâches répétitives telles que l'exécution de tests et de déploiements, la surveillance des logiciels de production pour détecter les problèmes et la création d'une méthodologie de déploiement résiliente aux problèmes. Les développeurs peuvent créer et expérimenter, ce qui permet de booster la productivité.
DevOps peut être défini de différentes façons. Dans cet article, le terme désigne une équipe qui possède l'ensemble du cycle de vie d'un logiciel. Une équipe DevOps conçoit, implémente, déploie, surveille, corrige les problèmes et met à jour le logiciel. Elle est responsable du code et de l'infrastructure sur laquelle il s'exécute. Elle ne gère pas seulement l'expérience utilisateur final, mais aussi les problèmes de production.
L'un des principes DevOps est d'élaborer un processus qui permet d'anticiper les problèmes et d'aider les développeurs à y répondre efficacement. Un processus DevOps devrait fournir aux développeurs un feedback immédiat sur l'intégrité du système après chaque déploiement. Plus un problème est découvert tôt, plus son impact est faible et plus vite l'équipe peut passer à la tâche suivante. Les développeurs peuvent expérimenter, développer, livrer et tester de nouvelles idées s'il est facile de déployer les changements et de résoudre les problèmes.
Qu'est-ce que DevOps n'est pas ? Une technologie. Si vous achetez des outils DevOps et que vous les appelez DevOps, vous mettez la charrue avant les bœufs. DevOps cherche à développer une culture de responsabilité partagée, de transparence et de feedback plus rapide. La technologie est simplement un outil pour y parvenir.
Ressource connexe
Essayez la solution gratuitement
Ressource connexe
Découvrez les bonnes pratiques DevOps
Avertissement
Étant donné que chaque équipe adopte sa propre approche, certaines des étapes suivantes peuvent ne pas s'appliquer. En outre, cette liste n'est pas exhaustive. Les étapes présentées visent à aider une équipe à se lancer et à implémenter DevOps.
Dans cet article, DevOps est utilisé comme terme fourre-tout désignant la culture, les processus et les technologies qui entourent DevOps.
Huit étapes pour implémenter DevOps
Étape 1 – Sélectionner un composant
La première étape consiste à commencer modestement. Sélectionnez un composant actuellement en production. Le composant idéal présente une base de code simple, peu de dépendances et une infrastructure minime. Il fera office de terrain d'essai qui permettra à l'équipe de se familiariser avec l'implémentation de DevOps.
Étape 2 – Envisager l'adoption d'une méthodologie Agile comme Scrum
DevOps est souvent associé à une méthodologie de travail Agile comme Scrum. Il n'est pas nécessaire d'adopter l'ensemble des rituels et pratiques associés à cette méthodologie. Trois éléments Scrum sont généralement faciles à adopter et apportent rapidement de la valeur : le backlog, le sprint et la planification du sprint.
Une équipe DevOps peut ajouter et prioriser le travail dans un backlog Scrum, puis intégrer un sous-ensemble de ce travail dans un sprint, une durée fixe pour réaliser une tâche spécifique. La planification du sprint consiste à déterminer les tâches qui seront transférées du backlog au sprint suivant.
Étape 3 – Utiliser le contrôle de version basé sur Git
Le contrôle de version est une bonne pratique DevOps qui permet d'améliorer la collaboration et d'accélérer les cycles de livraison. Des outils comme Bitbucket permettent aux développeurs de partager, de collaborer, de fusionner et de sauvegarder des logiciels.
Sélectionnez un modèle de création de branche. Cet article fournit un aperçu du concept. Le flux GitHub est un excellent point de départ pour les équipes qui découvrent Git, car il est simple à comprendre et à implémenter. Le développement basé sur le tronc est souvent privilégié, mais il demande plus de discipline et rend les premiers pas dans Git plus difficiles.
Étape 4 – Intégrer le contrôle de version au suivi du travail
Intégrez l'outil de contrôle de version à celui de suivi du travail. En pouvant afficher tous les éléments d'un projet spécifique en un seul et même endroit, les développeurs et la direction gagneront beaucoup de temps. Vous verrez ci-dessous un exemple de ticket Jira avec les mises à jour d'un dépôt de contrôle de version basé sur Git. Les tickets Jira incluent une section de développement qui regroupe le travail effectué pour le ticket Jira en matière de contrôle de version. Le ticket suivant comportait une seule branche, six commits, une pull request et un build unique.
Pour en savoir plus, consultez la section Development (Développement) d'un ticket Jira. L'onglet Commits répertorie tous les commits associés à un ticket Jira.
Cette section répertorie toutes les pull requests associées au ticket Jira.
Le code associé à ce ticket Jira est déployé dans tous les environnements répertoriés dans la section Deployments (Déploiements). Ces intégrations fonctionnent généralement en ajoutant l'ID de ticket Jira (en l'occurrence IM-202) pour commiter les messages et les noms de branche associés à ce ticket.
Un onglet de code fournit des liens vers tous les dépôts de contrôle de version liés au projet. Les développeurs peuvent ainsi plus facilement trouver le code sur lequel ils doivent travailler lorsqu'ils s'assignent un ticket Jira.
Étape 5 – Rédiger des tests
Les pipelines de CI/CD nécessitent des tests pour vérifier le bon fonctionnement du code déployé dans différents environnements. Commencez par rédiger des tests unitaires pour le code. Bien que l'objectif ambitieux soit de couvrir 90 % de ce dernier, il n'est pas réaliste au début. Fixez une base de référence faible pour la couverture de code et relevez progressivement la barre au fil du temps pour la couverture des tests unitaires. Vous pouvez ajouter des tâches au backlog pour y remédier.
Utilisez le développement basé sur les tests pour corriger les bugs identifiés dans le code de production. Lorsque vous détectez un bug, rédigez des tests unitaires, des tests d'intégration ou des tests système qui échouent dans les environnements où le bug est apparu. Corrigez le bug et assurez-vous que les tests réussissent. Ce processus augmentera naturellement la couverture de code au fil du temps. Si le bug a été décelé dans un environnement de test ou de staging, les tests permettront de garantir que le code fonctionne correctement une fois mis en production.
Si vous débutez, cette étape nécessite beaucoup de travail, mais elle est importante. Les tests permettent aux équipes de voir l'effet des changements de code sur le comportement du système avant de présenter ces changements aux utilisateurs finaux.
Tests unitaires
Les tests unitaires vérifient que le code source est correct et doivent être effectués au lancement d'un pipeline de CI/CD. Les développeurs devraient rédiger des tests pour le parcours de déploiement (« green »), les entrées problématiques et les « corner cases » connus. Lors de la rédaction des tests, les développeurs peuvent simuler les entrées et les sorties attendues.
Tests d'intégration
Les tests d'intégration permettent de vérifier que deux composants communiquent correctement entre eux. Simulez les entrées et les sorties attendues. Ces tests constituent l'une des premières étapes d'un pipeline de CI/CD avant le déploiement dans un environnement. Pour être efficaces, ils nécessitent généralement des simulations plus approfondies que les tests unitaires.
Tests système
Les tests système vérifient les performances de bout en bout du système et garantissent qu'il fonctionne comme prévu dans chaque environnement. Simulez l'entrée qu'un composant est susceptible de recevoir et exécutez le système. Vérifiez ensuite que le système renvoie les valeurs nécessaires et met correctement à jour tous ses composants. Ces tests devraient être effectués après le déploiement dans chaque environnement.
Étape 6 – Élaborer un processus de CI/CD pour déployer le composant
Envisagez un déploiement dans plusieurs environnements lorsque vous créez un pipeline de CI/CD. Les éléments ne pourront pas être modifiés si une équipe développe un pipeline qui ne sera déployé que dans un seul environnement. Il est important de créer des pipelines de CI/CD pour l'infrastructure et le code. Commencez par en créer un pour déployer l'infrastructure nécessaire dans chaque environnement. Créez-en ensuite un autre pour déployer le code.
Structure du pipeline
Ce pipeline commence par réaliser des tests unitaires et d'intégration avant d'être déployé dans l'environnement de test. Les tests système sont exécutés après le déploiement dans un environnement.
Le modèle approximatif ci-dessus peut être développé de plusieurs manières. L'analyse du code, l'analyse statique et les analyses de sécurité sont autant de bonnes étapes supplémentaires à ajouter avant les tests unitaires et d'intégration. L'analyse du code permet d'appliquer les normes de programmation. L'analyse statique peut identifier les anti-schémas, tandis que les analyses de sécurité peuvent détecter la présence de vulnérabilités connues.
Les pipelines de CI/CD utilisés pour déployer l'infrastructure et le code sont probablement différents. Le pipeline de CI/CD pour l'infrastructure ne comporte souvent pas de tests unitaires ou d'intégration. Il effectuera des tests système après chaque déploiement pour s'assurer que le système ne s'arrête pas.
Infrastructure
Les différences d'infrastructure entre les environnements compliquent la bonne exécution des logiciels dans un environnement. Les règles du pare-feu, les autorisations utilisateur, l'accès aux bases de données et les autres composants de l'infrastructure doivent être définis dans une configuration connue pour que le logiciel s'exécute convenablement. Le déploiement manuel de l'infrastructure peut être difficile à répéter correctement. Comme ce processus comporte de nombreuses étapes, le fait de penser à exécuter chaque étape dans le bon ordre, avec les bons paramètres, peut entraîner des erreurs. L'infrastructure doit être définie dans le code dès que possible pour limiter les problèmes.
L'infrastructure peut être définie dans le code à l'aide de divers outils, notamment AWS CloudFormation, Terraform, Ansible, Puppet ou Chef.
Écrivez plusieurs pipelines pour déployer l'infrastructure. Tout comme rédiger du code, il est utile de maintenir la modularité de déploiement de l'infrastructure. Décomposez l'infrastructure requise en sous-ensembles disjoints dès que possible. Supposons que A, B, C et D soient des abstractions représentant des composants d'infrastructure qui peuvent dépendre les uns des autres. Par exemple, A peut être une instance EC2 et B un compartiment S3. Les dépendances dans lesquelles un composant d'infrastructure A (et seulement A) dépend du composant B devraient probablement être regroupées dans le même pipeline de CI/CD. Les dépendances où A, B et C dépendent de D, mais où A, B et C sont indépendants, devraient être réparties dans plusieurs pipelines de CI/CD. Dans ce cas, quatre pipelines sont indépendants. Vous devriez donc créer un pipeline pour D dont dépendent les trois autres composants, et un pour chacun des composants A, B et C.
Code
Les pipelines de CI/CD sont conçus pour déployer du code. Ils sont généralement simples à implémenter, car l'infrastructure est déjà disponible par le biais de tâches antérieures. Les points importants à prendre en compte sont les tests, la reproductibilité et la capacité à récupérer après un mauvais déploiement.
La reproductibilité est la capacité de déployer le même changement encore et encore sans endommager le système. Le déploiement doit être réentrant et idempotent. Un déploiement doit définir l'état d'un système selon une configuration connue plutôt que d'appliquer un modificateur à l'état existant. L'application d'un modificateur ne peut pas être répétée. En effet, après le premier déploiement, l'état de départ nécessaire au bon fonctionnement du modificateur change.
Un exemple simple de mise à jour non reproductible ? Mettre à jour un fichier de configuration en y ajoutant des données. N'ajoutez pas de lignes aux fichiers de configuration et n'utilisez aucune technique de modification de ce type. Le fichier de configuration peut contenir des dizaines de lignes dupliquées si les mises à jour sont effectuées par ajout. Remplacez plutôt le fichier de configuration par un fichier correctement écrit découlant du contrôle de version.
Ce principe devrait également être appliqué à la mise à jour des bases de données. Ce processus peut poser problème et demander une attention particulière. Il est essentiel de s'assurer qu'il est reproductible et tolérant aux pannes. Effectuez des sauvegardes immédiatement avant d'appliquer les changements, afin de permettre la récupération.
Vous devez également vous demander comment récupérer après un mauvais déploiement. Soit le déploiement a échoué et l'état du système est inconnu, soit le déploiement a réussi, des alarmes se déclenchent et les tickets d'incident commencent à s'accumuler. En principe, deux solutions permettent de régler ce problème. La première implique de lancer une restauration. La seconde consiste à utiliser des feature flags et à désactiver les flags nécessaires pour revenir à un état fonctionnel connu. Consultez l'étape 8 de cet article pour en savoir plus sur les feature flags.
Une restauration déploie l'état fonctionnel déjà connu dans un environnement après la détection d'un mauvais déploiement. Elle devrait être prévue dès le départ. Avant de toucher à une base de données, effectuez une sauvegarde. Veillez à pouvoir déployer rapidement la version précédente du code. Testez régulièrement le processus de restauration dans des environnements de test ou de staging.
Étape 7 – Ajouter une surveillance, des alarmes et des instruments
Une équipe DevOps doit surveiller le comportement de l'application en cours d'exécution dans chaque environnement. Des erreurs se sont-elles glissées dans les journaux ? Les appels vers les API expirent-ils ? Les bases de données plantent-elles ? Surveillez chaque composant du système pour identifier les problèmes. Si vous détectez un problème, créez un ticket d'incident afin de pouvoir le résoudre. Lors de la résolution, rédigez des tests supplémentaires pour cerner le problème.
Correction des bugs
La surveillance et la résolution des problèmes sont partie intégrante de l'exécution du logiciel de production. Une équipe adoptant une culture DevOps est responsable du fonctionnement du logiciel et s'inspire du comportement d'un ingénieur chargé de la fiabilité du site (SRE). Analysez la cause racine du problème, rédigez des tests pour détecter ce dernier, résolvez-le et vérifiez que les tests réussissent désormais. Ce processus est souvent laborieux au départ, mais il porte ses fruits à long terme, car il réduit la dette technique et préserve l'agilité opérationnelle.
Optimisation des performances
Une fois la surveillance de l'intégrité de base en place, l'étape suivante consiste généralement à optimiser les performances. Regardez comment fonctionne chaque composant d'un système et optimisez les composants à la traîne. Selon Donald Knuth : « L'optimisation prématurée est la racine de tous les maux ». N'optimisez pas les performances de tous les composants du système. Optimisez uniquement les plus lents et les plus coûteux. La surveillance permet de les identifier.
Étape 8 – Utiliser les feature flags pour implémenter les tests « canary »
Pour permettre les tests « canary », intégrez chaque nouvelle fonctionnalité à un feature flag avec une liste verte reprenant les utilisateurs de test. Le code des nouvelles fonctionnalités sera uniquement exécuté pour les utilisateurs figurant sur cette liste après le déploiement dans un environnement. Prenez le temps d'intégrer la nouvelle fonctionnalité à chaque environnement avant de la promouvoir dans le suivant. Pendant qu'elle s'établit dans une région, prêtez attention aux métriques, aux alarmes et aux autres instruments pour détecter les signes de problèmes. Plus précisément, attendez-vous à une hausse du nombre de nouveaux tickets d'incident.
Résolvez les problèmes dans un environnement avant de passer à l'environnement suivant. Les problèmes rencontrés dans les environnements de production doivent être traités de la même manière que ceux décelés dans les environnements de test ou de staging. Après avoir identifié la cause profonde du problème, rédigez des tests pour cerner ce dernier, implémentez une correction, vérifiez si les tests sont réussis et mettez en avant la correction via le pipeline de CI/CD. Les nouveaux tests seront réussis et le nombre de tickets d'incident diminuera au fur et à mesure que le changement s'intègre à l'environnement dans lequel le problème a été détecté.
Conclusion…
Faites une rétrospective du projet de migration du premier composant vers DevOps. Identifiez les points faibles, ou les étapes complexes ou difficiles. Améliorez le plan pour corriger ces points faibles, puis passez au deuxième composant.
L'adoption d'une approche DevOps pour mettre un composant en production peut sembler laborieuse au début, mais porte ses fruits sur le long terme. L'implémentation du deuxième composant devrait être plus facile une fois que vous aurez posé les bases. Le processus suivi pour le premier composant peut être utilisé et légèrement adapté pour le deuxième, car les outils sont en place, les technologies sont comprises et l'équipe s'est familiarisée avec DevOps.
Pour entamer votre parcours DevOps, nous recommandons d'essayer Atlassian Open DevOps, une chaîne d'outils intégrée et ouverte contenant tout ce dont vous avez besoin pour développer et utiliser des logiciels, et offrant la possibilité d'intégrer des outils supplémentaires au fur et à mesure que vos besoins évoluent.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.