Comment appliquer 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.

É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 seront codés en dur 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.

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 profonde 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é.