Le DevOps en pratique avec GitLab - Comprendre le cycle de développement logiciel

Introduction

Afin de mieux mesurer la valeur ajoutée de GitLab et des approches DevOps et DevSecOps que la plateforme implémente, il convient de voir en quoi consiste le cycle de développement logiciel (Software Development Life Cycle, SDLC) dont nous avons déjà parlé et comment celui-ci s’est transformé au fil des années. Une petite incursion dans le passé s’impose ici afin de mieux comprendre comment les logiciels étaient conçus avant l’apparition de solutions comme GitLab.

Les sections qui suivent prendront le SDLC comme fil conducteur pour explorer l’évolution du processus de livraison de logiciels, de l’approche dite « traditionnelle », jusqu’aux méthodologies privilégiées aujourd’hui. Nous insistons sur la notion de cycle de développement logiciel parce qu’il s’agit du concept autour duquel s’articulent les différents outils et fonctionnalités de GitLab.

Qu’est-ce que le cycle de développement logiciel ?

Tout logiciel est conçu pour résoudre un problème à l’aide d’un programme informatique écrit dans un ou plusieurs langages de programmation. En réalité, la création de logiciels s’accompagne plutôt d’un ensemble de problèmes du fait que ce processus comprend différentes phases et implique de nombreux intervenants.

De ce fait, une méthode de travail efficace s’impose pour la programmation d’un logiciel avec tout ce que ce processus implique, c’est ici qu’intervient la notion de cycle de développement logiciel.

Définition et origine du cycle de développement logiciel

Le cycle de développement logiciel peut être défini comme un cadre conceptuel décrivant les activités faisant partie d’un projet de développement, depuis sa planification jusqu’à sa maintenance. Chaque phase du cycle se caractérise par des tâches spécifiques et des livrables qui alimentent la phase suivante, mais cette progression n’exclut pas les retours en arrière si le produit ne répond pas aux exigences. Cependant, au fil du temps, de nouvelles manières de travailler se sont développées pour tenter de rendre le processus plus fluide afin d’éviter...

Le modèle en cascade

Le modèle en cascade (waterfall model) est l’une des premières méthodologies du SDLC à s’imposer. Cette approche qui a été popularisée durant les années 1990 est également connue sous le nom de « modèle linéaire-séquentiel » puisque son fonctionnement repose sur un certain nombre d’étapes à compléter avant de procéder à la suivante.

1. Les étapes du modèle en cascade

De manière générale, le modèle en cascade se compose de cinq ou six phases dont la nomenclature est susceptible de varier selon l’implémentation, mais elles peuvent se résumer ainsi :

1. Évaluation des besoins ou exigences : cette phase consiste à rassembler et documenter les besoins et les exigences liées au projet ainsi que les objectifs d’affaires.
2. Conception ou analyse : en s’appuyant sur les données recueillies dans l’étape précédente, cette phase consiste à faire l’architecture du système et à en définir les spécifications fonctionnelles et techniques.
3. Mise en œuvre : cette étape consiste à faire le développement du logiciel en transformant les spécifications en code exécutable.
4. Validation : dans cette phase, la solution fait l’objet de tests pour s’assurer que le logiciel fonctionne comme prévu. C’est l’occasion d’identifier et de corriger les erreurs et les bogues.
5. Déploiement ou mise en service : c’est durant cette étape que le logiciel est mis en production, documenté et les utilisateurs sont formés pour l’utiliser....

Le cycle de développement logiciel agile

À partir des années 2000, le modèle en cascade commence à être remis en question avec l’introduction des méthodes agiles et d’autres techniques telles le pair programming ou l’extreme programming.

Le pair programming est une technique de développement où deux développeurs travaillent ensemble sur le même code : un « pilote » écrit le code et un « copilote » qui le révise en temps réel. Cette pratique améliore la qualité du code et favorise la collaboration et le partage des connaissances entre les développeurs.

L’extreme programming (XP) se concentre sur l’amélioration de la qualité du code et la réactivité aux besoins changeants des clients. Cette approche encourage des pratiques telles que les tests automatisés, la programmation en binôme, les itérations courtes et la refactorisation fréquente du code. L’objectif du XP est de livrer des logiciels de haute qualité de manière rapide et flexible.

Cette première vague de changements a lieu à la suite du constat des limites du modèle en cascade et du fait qu’il est jugé inadapté à la conception et au déploiement de logiciels. En effet, il s’agit d’un processus dynamique qui implique des interactions constantes avec le client et une forte collaboration entre les membres des équipes participant aux projets.

1. Le manifeste pour le développement agile de logiciels

C’est ce que vont promouvoir les signataires du « Manifeste pour le développement agile de logiciels » (Manifesto for Agile Software Development) mis en ligne en 2001 (https://agilemanifesto.org/). Ce texte propose une méthode de travail qui s’appuie sur quatre principes :

les individus et leurs interactions plus que les processus et les outils ;
des logiciels opérationnels plus qu’une documentation exhaustive ;
la collaboration avec les clients plus que la négociation contractuelle ;
l’adaptation au changement plus que le suivi d’un plan.

Selon les auteurs du manifeste, le modèle en cascade était trop axé sur une longue...

Le DevOps

Le DevOps (concaténation des trois premières lettres de Développement et Opérations) peut être défini à la fois comme une culture et une philosophie de l’informatique qui met l’accent sur la collaboration, l’automatisation et l’amélioration continue dans la livraison des produits.

Cette approche tente de faire le pont entre les équipes de développement, de QA et des opérations.

1. Les origines du mouvement DevOps

Le mouvement DevOps prend forme à partir de 2007 alors que l’efficacité de la division traditionnelle entre développement et opérations commence à être remise en cause au sein de l’industrie.

La réflexion sur une nouvelle approche qui pourrait rapprocher les deux camps a été amorcée par Patrick Debois, un consultant belge. En 2009, il organise des conférences nommées « DevOpsDays » à Gand où les contributeurs s’interrogent notamment sur la possibilité d’appliquer les méthodes agiles au monde des opérations.

À la suite de cet événement, le terme « DevOps » est resté et, au fil des années, il a donné lieu à un mouvement qui fait la promotion d’une culture de responsabilité partagée et de la collaboration entre le développement et l’opérationnel. Au lieu d’être considérés comme deux sphères indépendantes, ces deux domaines sont plutôt vus comme étant imbriqués et faisant partie d’une approche complémentaire.

L’année 2009 est aussi notable en raison de la conférence de John Allspaw et Paul Hammond intitulée « 10+ Deploys Per Day : Dev and Ops Cooperation at Flickr » présentée à l’événement O’Reilly Velocity. Le co-directeur des opérations et le directeur de l’ingénierie chez Flickr viennent renforcer la nécessité d’une collaboration entre Dev et Ops en suggérant qu’elle contribue à la rapidité des déploiements.

a. Le Site Reliability Engineering

Une réflexion semblable à celle du DevOps avait aussi donné...

Le DevSecOps

Les changements culturels et organisationnels suscités par le DevOps ont souvent négligé un point essentiel à tout cycle de développement logiciel : le volet sécurité. C’est dans cette perspective que le DevSecOps fait son apparition, d’où l’ajout du « Sec » entre « Dev » et « Ops » pour en souligner l’importance. Cette préoccupation pour la sécurité dans une perspective DevOps commence à émerger au milieu des années 2010.

Bien qu’il n’existe pas de manifeste officiel du DevSecOps, le plus connu a été rédigé par une communauté des spécialistes dans le domaine et il est accessible sur le site suivant : https://www.devsecops.org/. Les auteurs décrivent leur approche comme relevant de ce qu’ils nomment Security as Code (SaC).

1. Les neuf principes du DevSecOps

Le manifeste du DevSecOps que nous venons d’évoquer s’articule autour de neuf principes fondamentaux que nous pouvons traduire ainsi :

S’engager plutôt que de dire toujours « non ».
La science des données et de la sécurité plutôt que la peur, l’incertitude et le doute (Fear, Uncertainty, and Doubt, FUD).
La contribution et la collaboration ouvertes plutôt que des exigences orientées uniquement sécurité.
Des services de sécurité qui peuvent être consommés avec des API plutôt que des contrôles de sécurité imposés et de la paperasse.
Des indicateurs de sécurité orientés par les besoins de l’entreprise plutôt que des règles de sécurité formelles.
Des tests d’exploitation effectués par les Red et Blue Teams plutôt que de se fier aux analyses et aux vulnérabilités théoriques.

Les Red Teams sont des groupes de sécurité offensive spécialisés dans la simulation d’attaques réelles contre les systèmes d’une organisation pour identifier les vulnérabilités et tester les défenses en place. Leur objectif est de penser et d’agir comme des attaquants potentiels pour trouver des failles...

Conclusion

Dans ce chapitre, nous avons commencé par voir en quoi consiste le cycle de développement logiciel. Après avoir présenté le modèle en cascade et le processus de livraison de logiciels traditionnel, nous avons examiné trois approches : les méthodes agiles, le DevOps et le DevSecOps.

Ce parcours visait à mieux comprendre les fonctionnalités offertes par GitLab dont la conception s’inspire de ces méthodologies modernes. Nous avons examiné des notions essentielles comme l’intégration et la livraison ou le déploiement continus qui, comme nous le verrons dans la suite de cet ouvrage, comptent parmi les principales pratiques que GitLab permet d’automatiser et de simplifier.

À mesure que vous progresserez dans votre lecture, vous verrez que le contenu de ce chapitre va se clarifier et devenir plus concret lorsque vous passerez à la pratique.

Avant de nous pencher sur les pipelines CI/CD, il nous reste toutefois un certain nombre d’éléments à aborder. Nous devons d’abord faire un détour du côté de Git, l’outil autour duquel GitLab est construit.

En effet, il est essentiel d’avoir une bonne compréhension de Git puisque GitLab en adopte la terminologie et implémente de nombreux concepts issus de ce gestionnaire de version. Tel sera le sujet du chapitre...