CI/CD et DevOps
S’adapter aux évolutions du marché et aux exigences du client n’est plus une option aujourd’hui et c’est ce qui explique en grande partie l’essor des méthodologies agiles et des pratiques DevOps.
Alors que les applications traditionnelles étaient pour l’essentiel des applications de back office, les applications web sont, au contraire, en frontal avec les clients. Pour être compétitives, les entreprises n’ont pas d’autre choix que de prendre le virage digital et d’optimiser l’expérience client. C’est une véritable course contre la montre pour être le 1er sur le marché, être le plus performant et le rester.
Le DevOps, c’est finalement tenter d’atteindre, progressivement, mais sûrement, cet équilibre entre une adaptation rapide et le respect de ces processus.
comme l’explique Micaël, expert DevOps chez SoftFluent
La démarche DevOps permet de rapprocher les opérations de développement et de production en entreprise tout en alignant les équipes, les outils et les processus. L’objectif à la clé : améliorer le délai de mise en production, générer de la valeur, réduire les coûts informatiques et mieux répondre aux besoins métiers.
Avec une taille d’équipe similaire, en livrant plus souvent, on livre mécaniquement moins et on limite les erreurs, bugs et oublis en tout genre.
selon Micaël
Au-delà des outils et des méthodes, DevOps c’est un changement de culture professionnelle profond et un état d’esprit. La nouvelle chaîne de déploiement permet aux développeurs d’être plus autonomes, moins dépendants des délais de déploiement et davantage responsabilisés.
Approche CI/CD (Intégration continue/Déploiement continu)
L’approche CI/CD permet d’augmenter la fréquence de distribution des applications grâce à l’introduction de l’automatisation au niveau des étapes de développement des applications.
Avec une automatisation mature, bien maîtrisée, on ne devrait plus jamais craindre la mise en production d’un hotfix à déployer en urgence un vendredi soir, juste avant de partir en week-end…
précise Micaël
Les principaux concepts liés à l’approche CI/CD sont l’intégration continue, la distribution continue et le déploiement continu.
Le concept de développement d’applications modernes consiste à faire travailler plusieurs développeurs simultanément sur différentes fonctions d’une même application avec le risque d’un conflit de modifications des uns et des autres et d’autant plus si chacun travaille dans son propre environnement de développement. D’où l’importance du CI/CD.
Intégration continue
L’intégration continue (CI) permet aux développeurs de fusionner plus fréquemment leurs modifications de code dans une « branche » partagée, souvent critique et qui doit être protégée. Les opérations réalisées par l’intégration continue doivent garantir cette protection. Les modifications à fusionner sont automatiquement testées pour détecter le moindre conflit entre le code existant et le nouveau (à tous les niveaux, classes, fonctions, modules…). Les dysfonctionnements éventuels sont ainsi résolus très tôt, plus fréquemment et plus rapidement.
Pour que l’intégration continue reste efficace, il est essentiel que les opérations qu’elle assure s’exécutent dans un temps raisonnable d’autant que le développeur préfère souvent attendre la complétion de l’intégration continue pour démarrer une nouvelle fonctionnalité à partir d’un code source à jour.
selon Micaël
Distribution (ou livraison) continue
Après l’automatisation des tests unitaires dans le cadre de l’intégration continue, la distribution continue automatise la publication du code validé dans un référentiel. La distribution continue permet de disposer d’une base de code toujours prête à être déployée dans un environnement de production.
La livraison continue, pour être efficace, doit s’appuyer sur des référentiels capables de proposer une fonctionnalité de suivi de version pour avoir la possibilité de revenir (le plus automatiquement possible) à une version antérieure du livrable en cas de problème. Des solutions existent comme « Nexus Repository » ou « Azure DevOps Artifacts »
comme l’explique Micaël
Déploiement continu
L’étape finale d’un pipeline CI/CD mature est le déploiement continu. En complément du processus de distribution continue, qui automatise la publication d’une version prête pour la production dans un référentiel, le déploiement continu automatise l’exécution d’une nouvelle version d’une application dans un environnement de production.
Différents modèles de déploiement existent comme le ‘Blue-Green Deployment’, le ‘Canary Release’, le ‘Ring-based Deployment’ ou encore le ‘Dark Launch’ avec des processus plus ou moins complexes suivant ce que vous souhaitez faire
selon Micaël
Ensemble, ces trois pratiques CI/CD réduisent les risques liés au déploiement des applications, puisqu’il est plus simple de publier des modifications par petites touches plutôt qu’en un seul bloc. L’approche CI/CD se rapporte à un processus, souvent représenté sous forme de pipeline, qui consiste à introduire un haut degré d’automatisation et de surveillance continues dans le cycle de vie des applications.
Pipeline
C’est l’implémentation de l’approche CI CD.
Un pipeline de déploiement est une façon d’orchestrer vos builds au travers d’une série de passages garantissant la qualité, avec des approbations automatisées ou manuelles aux étapes stratégiques, culminant avec le déploiement en production.
Ce pipeline de build est généralement exploité dans le cadre de l’intégration continue, lorsqu’on a besoin d’assurer ces opérations de validation du code. Les grands opérateurs du marché, comme GitHub, GitLab ou Azure DevOps, proposent une configuration qui permet de déclencher automatiquement un pipeline de build lors des demandes de « Pull request »
Comme l’explique Micaël
Les étapes
Les étapes qui constituent un pipeline CI/CD sont des sous-ensembles distincts de tâches regroupés dans ce que nous appelons une phase de pipeline. Voici les phases de pipeline les plus courantes :
- Récupération : code source récupéré du gestionnaire
- Création : compilation de l’application
- Test : test du code et notamment tests automatisés
- Lancement : distribution de l’application au référentiel
- Déploiement : déploiement du code en production
- Validation et conformité : ces étapes de validation sont à adapter en fonction des besoins de l’entreprise
Cette liste de phases de pipeline n’est pas exhaustive. Votre pipeline devra se conformer aux exigences de votre entreprise.
Le découpage en phases est important. Il faut absolument éviter un pipeline contenant une unique phase notamment pour identifier l’étape en cas d’échec de l’exécution du pipeline. Il faut aussi séparer les pipelines eux-mêmes pour assurer l’exécution de chacun d’eux et ne pas contraindre l’un par des conditions de l’autre.
précise Micaël
Contrôle de version
Les équipes de développement pratiquant l’intégration continue utilisent différentes techniques pour contrôler les fonctionnalités et le code prêts à être déployés en production
- « Feature Flags », autrement dit, des indicateurs de fonctionnalités. Les fonctionnalités encore en cours de développement sont balisées dans le code et désactivées jusqu’à ce qu’elles soient prêtes à être utilisées
- Une autre technique consiste à effectuer un contrôle de version par branche. Certaines équipes optent pour un workflow Git comme GitFlow, pour séparer, sur des branches distinctes, le code en cours de développement et le code validé et testé.
Exposer de manière différenciée les fonctionnalités implique cependant un coût à discuter et choisir en étant toujours le plus réaliste et pragmatique possible.
comme expliqué par Micaël
Les intérêts d’un pipeline
En optimisant et en standardisant les processus, les bénéfices sont multiples :
- Livrer des applications fiables en testant automatiquement chaque changement dans le code source pour réduire l’introduction de bogues.
- Livrer de nouvelles fonctionnalités plus fréquemment en optimisant vos processus et en supprimant les obstacles à la productivité.
- Limiter le stress et améliorez la productivité des développeurs.
- Réduire le code inutile
- Réduire la taille des branches de fonctionnalités pour faciliter l’examen par les pairs
- Augmenter la qualité de code
- Améliorer la gestion des produits et donc la satisfaction des utilisateurs
Résultats : moins de pannes difficiles à réparer et des ingénieurs heureux
En résumé l’approche CI / CD consiste en cycles de déploiement courts qui conduisent à des mises à jour moins risquées et plus fréquentes, et donc à un apprentissage plus rapide et à un feedback plus fréquent des utilisateurs.
Ces pratiques sont souvent désignées par l’expression « pipeline CI/CD » et reposent sur une collaboration agile entre les équipes de développement et d’exploitation.
KPI
Les indicateurs de performance doivent être concrets, mesurables et répondre aux particularités du DevOps :
- Etre évocateurs auprès des équipes de développement comme des équipes des opérations
- Permettre de mesurer la performance de toute la chaîne en termes de productivité, qualité, et satisfaction client
Les KPI sont le gage de rapidité et d’efficacité des équipes d’autant plus s’ils sont liés à un KPI métier. Non seulement cela permet de soigner le périmètre et l’efficacité des tests (les tests pour les tests ne sont pas forcément utiles et surtout il faut penser à archiver ceux devenus inutiles) mais cela permet surtout de stimuler et de motiver l’équipe.
Ces KPI doivent être mis en œuvre très tôt dans le processus de mise en œuvre du CI/CD. Idéalement, certains devraient exister avant même l’implémentation du CI/CD et permettent ainsi d’avoir une vue objective des améliorations que le CI/CD apportent.
précise Micaël
A lire sur le même sujet | DevOps, quels indicateurs de performance et comment s’améliorer ?
CI/CD as a Service
L’intégration et la livraison continues sont des composantes fondamentales de la démarche DevOps. Toutefois, alors que les pipelines doivent prendre en compte les nouvelles architectures – conteneurs notamment –, il devient nécessaire d’abstraire un peu plus ces étapes du cycle de vie d’une application : c’est le sens d’une approche ‘as a Service’ du CI/CD.
‘As a Service’ désigne des services fournis par le biais du cloud, qu’il s’agisse de SaaS, de IaaS ou de PaaS. Facile d’en conclure que CI/CD ‘as a Service’ signifie alors que le pipeline, managé ou non, s’appuie sur une infrastructure cloud quelle qu’elle soit. Ce modèle permet aux équipes de s’affranchir des problèmes habituels et des frais liés à la gestion et au maintien d’une infrastructure CI/CD. Côté fonctionnement, CI/CD ‘as a Service’ s’intègre au service de référentiel de votre choix (GitHub, Bitbucket, GitLab, Azure DevOps, etc.).
Faire usage de plateforme proposant des services managés de CI/CD est une bonne chose : l’ensemble des parties prenantes n’a plus alors qu’à se concentrer sur ce qui apporte le plus de valeur, c’est-à-dire livrer le plus vite possible et le mieux possible une nouvelle version. Attention cependant à ne pas oublier les notions de sécurité et de coûts
Conclut Micaël
A suivre, notre prochain article sur les modèles de déploiement.
