Culture & enjeux du DevOps

Introduction

début ~2010 patrick debois 

avant le DevOps, il y avait une fluidification en waterfall : conception détaillée avec un suivi de contrôle humain rigoureux avant chaque livraison sur le modèle Waterfall → trop de rigueur, trop séquentiel et ne suit pas les évolutions

DevOps : ensemble de pratiques qui met l'accent sur la collaboration et la communication entre les dev de logiciels et les pro des opérations informatiques, en automatisant le processus de livraison  de logiciels et les changements d'infrastructure
ce n'est pas une méthodo mais une philo

Fondamentaux

Le DevOps est un mouvement visant à réconcilier les équipes de développement (Dev) et d'exploitation (Ops) pour fluidifier le cycle de vie logiciel via l'automatisation, la collaboration et l'agilité.

 

Modèle C.A.L.M.S. 

• Culture : Valeurs communes, confiance et droit à l'erreur.
• Automation : Gain de temps, automatisation des processus et réduction des erreurs.
• Lean : Élimination du gaspillage et concentration sur la valeur.
• Measure : Utilisation d'indicateurs (délais, coûts, performances) alignés sur les objectifs métiers.
• Share : Partage des informations, outils et retours d'expérience.

 

Écosystème et rôles

• Les métiers évoluent : DevOps, SRE (Site Reliability Engineer), Cloud Engineer et Platform Engineer.
• L'environnement de travail recommandé repose sur un système Unix (Linux, MacOS ou WSL sur Windows) et un IDE performant comme Visual Studio Code.
• L'Open Source est central pour éviter le verrouillage fournisseur (vendor lock-in) et favoriser l'innovation rapide via une communauté active.

IA vs Automatisation :

• L'automatisation exécute des tâches selon des règles fixes (ex. : déclenchement d'un pipeline CI/CD).
• L'IA utilise des modèles pour analyser, prédire et s'adapter, notamment via le Machine Learning (prévention de pannes) ou le NLP (analyse de logs et ChatOps).

outils

• git / gitlab/ github
• terraform / kubernets / jenkins / ansible
• AWS / Azure
• SAM (serverless application model) 

processus

• integration continue : le but est de tester aussi souvent et autant que possible les non regressions du livrable pour detecter les bugs le plus tot possible
• livraison continue : le but est de tester et livrer une appli à chaque étape de son cycle de vie (recette, pré-production, répétition, production). Cette étape est réalisée après validation des tests effectués en intégration.
• Déploiement continue: nécessite que les processus d'integration et livraison continue aient ete relaises avec succes pour deployer une appli en production. Auprès déploiement, il est nécessaire de mesurer les impacts à l'aide d'outils de mesure de performance et de supervision. En cas de problème, un processus automatisé de retour en arrière peut être exécuté (rollback)

 

Version Control System (VCS) & Intégration Continue

voir la fiche sur les généralités Git et GitLab

 

La gestion de l'information technique (code, documentation, configuration) est essentielle et nécessite une traçabilité rigoureuse.

• Git : Outil de gestion de version décentralisé, agissant comme l'unique source de vérité pour le code et l'infrastructure. Il permet la collaboration et déclenche les chaînes d'intégration.
• CI/CD :
  • Continuous Integration (CI) : Automatisation des tests et de la compilation à chaque modification du code pour générer un artefact.
  • Continuous Delivery (CD) : Livraison nécessitant un déclenchement manuel avant la mise en production. Le pipeline automatise build, tests et staging, mais un humain valide manuellement le déploiement en production.
  • Continuous Deployment (CD) : Déploiement entièrement automatisé en production, nécessitant une grande maturité technique. Chaque changement qui passe les tests est automatiquement déployé en production, sans aucune action humaine.

• GitLab CI :
  • Fonctionne via un fichier YAML (.gitlab-ci.yml) placé à la racine du projet.
  • Composé de stages (étapes de construction/test) contenant des jobs (commandes exécutées).
  • Les runners sont les agents physiques ou virtuels qui exécutent ces tâches.
• Qualité et sécurité : Intégration dans le pipeline d'outils d'analyse statique (comme SonarQube) pour détecter automatiquement les bugs, la dette technique et les vulnérabilités.

 

 

devops & agile

• agile : livrer plus souvent en plus petite quantité à la fin de chaque sprint
• devops & agile : un livrable est automatiquement déployé en prod dès l'intégration

=) livraison fréquente et incrémentale qui permette des maj régulière en cycle court 

Cependant, la méthode AGILE favorise les performances des développeurs, qui produisent de plus en plus de logiciels mais les ops ne peuvent pas toujours suivre. Il faut mettre en place des solutions : 

• sensibilisation (dev en observation des ops pendant x jours)
• partage (documentation, PI / roadmap, ...)
• expérimentation (test recette validation, ...)
• the 3 ways (The Phoenix Project de Gene Kim)

  • La première voie (le flux) : Elle se concentre sur l'accélération du travail de la gauche (le développement) vers la droite (les opérations et le client), en éliminant les goulots d'étranglement et en automatisant le maximum de tâches.

  • La deuxième voie (le feedback) : Elle consiste à créer des boucles de rétroaction rapides de la droite vers la gauche, afin que les développeurs soient immédiatement alertés des problèmes survenant en production.

  • La troisième voie (l'apprentissage continu) : Elle vise à instaurer une culture d'entreprise favorisant l'expérimentation, la prise de risque et l'apprentissage par l'échec pour améliorer continuellement le système.

Pour illustrer simplement ce concept, imaginez une chaîne de fabrication où la première voie pousse le produit rapidement sans interruption, la deuxième voie déclenche une alarme immédiate si un défaut de montage est détecté par les testeurs, et la troisième voie encourage les ingénieurs à inventer de nouveaux outils chaque semaine pour rendre l'usine encore plus performante. Cela permet de réconcilier la vitesse exigée par l'approche Agile avec la fiabilité requise par les Ops.

Time to Market / TTM

time to market : durée nécessaire pour qu'une fonctionnalité soit introduite sur le marché. 

Intervalle de temps entre la prise de décision de créer une fonctionnalité

vélocité : vitesse constante sur la prod / projet / ....