Les 8 phases du DevOps [FRENCH]

Le pipeline DevOps est un flux de travail continu. On peut cependant le décomposer en huit phases. Ces huit phases sont décrites dans cet article.

1 - Plan

Recueillir les exigences et les feedbacks auprès des parties prenantes et des clients.
Etablir une Product Roadmap (feuille de route du produit) pour guider le développement.
Le Product Roadmap doit être enregistré et tracé à l’aide d’un système de gestion des tickets (exemple : Jira, Azure DevOps).
Créer éventuellement un backlog de tâches en décomposant le Product Roadmap en Epics, Features et User Stories. Ce backlog de tâche sera utilisé pour planifier les sprints et attribuer des tâches à l’équipe.

2 - Code

L’équipe développe en utilisant un environnement de développement classique auquel on ajoute des plugins qui :

  • facilitent le développement,
  • aident à appliquer un style de code cohérent,
  • évitent les failles de sécurité courantes et les anti-patterns de code.
    Les avantages sont l’enseignement des bonnes pratiques de codage, la facilitation de la collaboration et la cohérence de la base de code.

3 - Build

Le processus général est le suivant :

  • le développeur fait un commit de son code dans le référentiel de code partagé,
  • il soumet une Pull Request (demande d’extraction) : c’est une demande de fusion de son code avec la base de code partagée,
  • une itération a lieu :
    • un build automatique de la base de code est déclenché,
    • une série de tests unitaires, d’intégration, end-to-end est exécutée afin d’identifier d’éventuelles régressions,
    • si le build échoue ou si l’un des tests échoue, la Pull Request échoue et le développeur est informé du problème; il corrige le problème et l’itération suivante a lieu,
  • un autre développeur examine les modifications qu’il a apportées,
  • s’il n’y a pas de problème, il approuve la Pull Request,
    Les avantages sont d’identifier rapidement les problèmes, de minimiser les problèmes d’intégration et de mettre en évidence les bugs cassant la build (“breaking bugs”) dès le début.

4 - Test

La build est automatiquement déployée dans un environnement de test (soit un déjà existant, soit un nouveau monté pour l’occasion, grâce à l’IaC - Infrastructure-as-Code).
Des tests manuels (UAT) et automatisés (analyses de la sécurité, vérification des changements sur l’infrastructure, tests de respect des bonnes pratiques, tests de performance, tests de montée en charge) sont effectués.

5 - Release

En fonction de la maturité DevOps, la build peut être déployée automatiquement ou un mécanisme d’approbation manuelle peut être mis en place.
L’utilisation de Feature Flags permet de désactiver les nouvelles fonctionnalités afin que les clients ne puissent pas les voir avant qu’elles ne soient prêtes à être utilisées. Cela permet d’augmenter la fréquence des déploiements de nouvelles versions et de contrôler le calendrier des mises en production.

6 - Deploy

La build est mise en production.
L’environnement de production peut être construit automatiquement en utilisant l’IasC.
Un déploiement Blue-Green permet de passer au nouvel environnement de production sans interruption de service.

7 - Operate

Le service d’hébergement permet à l’environnement de s’adapter automatiquement aux pics de charge ainsi qu’aux creux. L’équipe d’exploitation s’assure que tout fonctionne correctement.
Un service de feedback permet aux clients de fournir un feedback sur le service afin de contribuer au développement des versions futures. Ce service doit capturer, stocker et trier ces feedbacks.

8 - Monitor

La surveillance de l’environnement consiste à analyser le comportement des clients, les performances, les erreurs, …
Cela consiste aussi à surveiller le pipeline et à rechercher les goulots d’étranglement (bottlenecks) potentiels du pipeline.
Ces informations sont transmises à l’équipe de développement.

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×