Points Clés
Cet article explorera les étapes initiales pour lancer une transformation DevOps, en mettant en lumière les concepts essentiels, la gestion des versions, l’automatisation et le monitoring.
Introduction
Dans le monde du développement logiciel, DevOps (Développement + Opérations) et l’Agilité s’associent pour plus d’efficacité.
DevOps automatise les étapes, assurant une intégration continue (CI) et un déploiement continu (CD), tout en annulant les barrières entre les équipes de développement et d’exploitation.
Cette synergie entre DevOps et l’Agilité crée une culture propice à l’innovation continue. Des cycles de développement plus rapides, une qualité constante grâce à CI/CD.
COMMENT DÉMARRER UNE TRANSFORMATION DEVOPS ?
EVALUER ET ÉTABLIR NOTRE ROADMAP DEVOPS
1ère étape : On réunit les Stakeholders d’un projet et on effectue une évaluation du niveau actuel de maturité sur les différentes thématiques proposées : Culture et Organisation, Design et architecture, Build et déploiement, Test et vérification, Information et reporting.
- Permet un partage uniforme autour des pratiques actuelles
- Permet d’échanger autour des thèmes et partager la vision autour des pratiques
2ème étape : On se donne des ambitions et des objectifs autour de ce modèle de maturité
- On évalue notre niveau cible sur chacune des thématiques
3ème étape : On construit notre roadmap pour arriver à la cible précédemment établie
- Cette roadmap sera le fil conducteur pour évaluer l’avancement global
RENDRE VISIBLE LE CYCLE DE VIE PRODUIT : VALUE STREAM MAPPING
Réaliser un atelier de VSM revient à montrer une image réaliste du cycle de vie d’une demande dans sa globalité.
Le VSM a pour objectif de réduire le délai entre la demande et l’ouverture aux utilisateurs. Il se se réalise en 4 étapes :
- Cartographier l’état actuel avec les actions à valeur ajoutée et à non valeur ajoutée (délai)
- Mesurer les temps de chacune des étapes
- Trouver les axes d’amélioration et mettre en place les actions pour y parvenir
- Changer l’état actuel vers l’état futur une fois les actions engagées
METTRE EN PLACE UNE COMMUNAUTÉ DEVOPS ET L’ANIMER
Créer une communauté DevOps au niveau de l’organisation :
- Experts techniques côté développement
- Exploitants
- Hébergeurs
- Sponsors de la thématique
- Etc.
Animer cette communauté de façon agile
- Créer un Product Backlog, mettre en place une démarche d’amélioration continue – rétrospective, mettre en place la notion de sprint (sprints d’un mois par exemple), etc.
- Rapprocher les équipes de développement (Dev) et les équipes des opérations (Ops)
DevOps et Agilité : là où les erreurs de code deviennent des ‘features inattendues‘ et où chaque réunion est une séance d’entraînement pour les marathons de sprint. C’est presque comme faire de l’acrobatie, mais avec des serveurs au lieu de balles.
LES CONCEPTS CLÉS DE DEVOPS POUR BIEN DÉMARRER
Everything as Code:
- Infrastructure as Code
- Configuration as Code
- Pipeline as Code
- Documentation as Code – Living Documentation
SSOT – Single Source Of Truth.
Intégration continue – Branche par abstraction – Feature Flipping – Release Management Monitoring.
Automatisation – Livraison continue.
INFRASTRUCTURE AS CODE
Pourquoi changer d’architecture vers une architecture de type Cloud ?
- Faire de la livraison un non évènement
- Définition d’un pipeline de livraison
Exemple de transformation d’architecture
- Objectif : Automatiser la création d’infrastructure en utilisant la définition sous forme de code
- L’action manuelle de mise en œuvre d’un environnement n’a pas de valeur ajoutée
- En cas d’incident, correction du code, destruction et reconstruction d’un environnement à partir de sa définition
- Bénéfices : gain de temps pour construire et remonter un environnement et amélioration de l’évolutivité des environnements
Exemple d’infrastructure as code pour la création de l’environnement Jenkins avec Docker
CONFIGURATION AS CODE
Objectif : Garantir une configuration d’exécution identique sur tous les environnements
- Utilisation du YAML pour décrire la configuration
- Stockage de la configuration avec le code source
- Regroupe la configuration applicative et d’exécution
La configuration est construite en même temps de la construction du binaire applicatif
Bénéfices : Quel que soit la plateforme, l’application fonctionne avec le même environnement d’exécution
PIPELINE AS CODE
Objectif : être en capacité de déployer à tout moment avec le Pipeline
Dès publication “push” sous GIT d’un code source, déclenchement du pipeline d’intégration
- Packaging de l’application “Release candidate” et de sa configuration
- Construction du binaire de l’application
- Construction des images Docker
- Exécution de tous les Tests Automatisés: TUA, TIA, TAA …
- En cas d’erreur sur l’exécution des tests :
- Le déploiement est interrompu
- L’équipe est informée afin de corriger au plus vite
- En cas d’erreur sur l’exécution des tests :
- Déploiement sur l’environnement d’intégration
- Mise à jour base de données
- Déploiement des composants de l’application
Bénéfices : Déploiement de versions stables, le déploiement sur l’environnement « Intégration » ne se fait que si tous les tests automatisés sont passants.
Exemple de pipeline :
LIVING DOCUMENTATION
Objectif : faire vivre la documentation dans le même cycle que le code source
- Documenter le produit tout au long de sa construction
- Construire la documentation fonctionnelle et technique
- La documentation produite correspond à ce qui est terminé
- Construire la documentation technique à partir des éléments du code source
Bénéfices : Une documentation à jour et facilement maintenable
Important !
Eviter l’écriture d’une spécification de 300 pages avant de produire la 1ère ligne de code
SSOT : SINGLE SOURCE OF TRUST
Objectif : Disposer d’un repository unique pour TOUT élément du projet (Single Repository Of Trust)
Application
- Code source des applications, ainsi que les dépendances (librairies, contenus statiques, etc.)
- Tous les scripts de création des schémas de BDD, les données de références, etc.
- Tous les tests automatisés, ainsi que les scénarios manuels
- Tout autre artefact du projet (documentation fonctionnelle, technique, releases notes, etc.)
Packaging et environnements
- Tous les scripts permettant le packaging de l’application, déploiement, la migration des datas de la BDD et le provisionning des environnements
- Tous les outils de création des environnements et des artéfacts décrits dans les éléments précédents
- Tous les fichiers permettant de créer les conteneurs (ex: Docker file)
Configuration
- Tous les fichiers de configuration de la plateforme cloud
- Tout autre script nécessaire à la configuration du produit dans son environnement
BRANCHE PAR ABSTRACTION ET FEATURE FLIPPING
Exemple de contexte projet :
- Il peut exister plusieurs itérations en parallèle à différentes phases dans le cycle de réalisation (conception technique, développement, correction d’anomalies internes, corrections d’anomalies de recette…)
- Chaque itération apporte son lot de corrections et de changements
- Il est nécessaire de pouvoir livrer chaque itération avec le contenu concerné
- Plusieurs stratégies sont possibles
Utiliser des branches :
- Implique la multiplication des Merges
Un Merge n’est pas toujours automatique
Un Merge ne se fait jamais sereinement
Un Merge est finalement un ensemble de modifications de code standard : nécessite de tester chaque élément du merge
- Risque de régression accru
- Génère de la complexité
Une branche peut diverger drastiquement du master
Une branche peut être maintenue plusieurs semaines, mois, …
Un Merge est potentiellement impossible
- Cela revient parfois à ré-implémenter la solution
- N’est pas un candidat idéal à l’intégration continue
Qui préconise un unique job sur le master
Qui considère que la multiplication de jobs est compliquée
- Frein à une approche déploiement continu / DevOps
Branche par abstraction
- Consiste tout simplement à ne pas utiliser de branches (en tous cas pas forcément une par itération)
- Pas de branche → Pas de merge
- Tous les développements sont effectués sur le master
- Les travaux incomplets sont désactivés par l’utilisation de feature flags
- Le master est toujours stable, prêt à être livré
Feature Flipping
- Possibilité d’activer et désactiver des fonctionnalités à n’importe quel moment
- Permet d’activer des fonctionnalités pour certains utilisateurs seulement
- En cas de problème, aucun retour en arrière, seulement de la désactivation.
- Possibilité de pousser du code non terminé
- Eviter les problématiques de Merge
Le Feature Flipping est une pratique liée au déploiement continu
- Utilisé par les grands du WEB : Flickr, Facebook, Gmail, Netflix, Pages Jaunes
RELEASE MANAGEMENT
- Séparer le concept de release de celui de déploiement
- Possibilité d’utiliser une technique de Blue-Green Deployments
- Possibilité d’utiliser une technique de Canary Release
Blue-green deployments
Canary Release
Possibilité d’utiliser une technique de Dark Launch
- Ce pattern permet de déployer la partie non visible d’une fonctionnalité, en simulant progressivement le trafic qui sera généré par l’utilisation de la fonctionnalité en cible.
- L’objectif de ce pattern est de pouvoir valider les performances et la scalabilité de la plateforme. En simulant le trafic attendu de manière progressive, on peut préparer et optimiser la plateforme afin que l’ouverture de la fonctionnalité aux utilisateurs finaux se passe dans les meilleures conditions le jour J.
MONITORING
Suivi du comportement utilisateur
- Challenger l’utilisation du produit par les utilisateurs
- Questionnaire Expérience Utilisateur
- Feedback pour ajuster le Product Backlog
- Superviser l’utilisation des fonctions
Surveillance des environnements
- Technique et fonctionnelle: temps de réponse, utilisation mémoire, etc.
AUTOMATISATION
Objectif : Réduire les actions manuelles avec peu de valeur
- Assurer la reproductibilité des processus
Au final, il est possible de trouver des actions à automatiser à tout niveau du projet :
- L’infrastructure
- Les tests
- La génération des binaires et livrables documentaires
- Le déploiement
- La documentation
L’automatisation des processus permet de s’assurer de la bonne compréhension de tous les acteurs du projet
Bénéfices : Feedback plus rapide en cas d’erreur et faciliter la promotion de l’application sur les différents environnements.
0 commentaires