Le DevOps au service du SaaS

1. Pourquoi DevOps ?

Dans le premier chapitre, nous avons vu à quel point le DevOps est la clé de voûte de nombreuses pratiques qui sont essentielles pour la fabrication et la livraison d’un service SaaS. C’est pourquoi nous allons ici revenir sur cette pratique et expliquer en quoi elle est essentielle.

2. Vue d’ensemble

"You build it, you run it"

Contraction des fonctions de "Développement" et "Opérations", le terme DevOps décrit un ensemble de pratiques visant à fluidifier et automatiser les processus de développement, de fabrication, de livraison et de supervision d’un service logiciel. Il faut se rappeler et répéter qu’à son origine, DevOps est avant tout une façon de penser et d’agir, une culture, et non pas la description d’une fiche de poste à proprement parler. Il s’agit en somme de réunir les forces et les actions de deux types d’équipes qui fonctionnent historiquement en silos : les équipes de développeurs et les équipes d’infrastructure système. DevOps unifie les objectifs, les pratiques et les outils avec la finalité de rendre les développements et les opérations plus efficaces, plus innovants, davantage enclins à monter à l’échelle, en délivrant un service toujours disponible et de qualité optimale à l’utilisateur final. 

DevOps est donc en ce sens un levier majeur de la construction d’un produit SaaS centré sur la fourniture de valeur pour les utilisateurs.

3. Les bonnes pratiques DevOps

Agilité et DevOps sont deux pratiques intimement liées. On peut même considérer que le DevOps est une extension de l’Agilité et que l’Agilité sans DevOps ne tient pas complètement ses promesses. Construire, délivrer et déployer le maximum de valeurs à l’utilisateur final par de courtes itérations, récupérer du feedback en continu, pivoter, s’adapter aux changements sont les principaux patterns qui soutiennent les méthodes Agile. Pour atteindre ces objectifs, le DevOps est un must-have, en particulier pour supporter une offre de service SaaS. Une équipe Agile doit...

1. Pourquoi une CI/CD ?

Délivrer de la valeur en continu sur le marché, récolter des feedbacks et s’adapter en permanence aux besoins des utilisateurs sont, nous l’avons vu, un véritable mantra pour tout projet informatique moderne et a fortiori dans un modèle de distribution SaaS. Mais y parvenir de manière industrialisée et répétable n’est pas aussi simple qu’il n’y paraît, en particulier au vu de la complexité croissante des systèmes à délivrer.

Passer d’un modèle de release annuelle ou semestrielle à un modèle de release en continu exige des procédés et un outillage sans faille. C’est pour cela qu’à l’instar de n’importe quelle industrie, celle du logiciel s’est, depuis plusieurs années, tournée vers la mise en œuvre de véritables chaînes d’assemblage à flux tirés que l’on rassemble en général par l’acronyme "CI/CD", pour Continuous Integration/Continuous Delivery. Derrière ces acronymes se cache en réalité un ensemble de sous-processus et de pratiques visant à ce que la fabrication et le déploiement d’un produit logiciel soient une opération fluide, qualitative, consistante, répétable, avec des cycles rapides. La CI/CD est donc le support vital à la réussite d’un projet SaaS et doit de ce fait être mise en priorité absolue et non reléguée en tâche périphérique d’une R&D délivrant un produit SaaS. Elle est en effet génératrice de vélocité, de consistance du produit et même un enjeu RH dans le sens où chaque équipier doit se sentir parfaitement à l’aise avec une usine qui l’aide dans son travail et non pas qui le ralentit. Revenons en premier lieu sur quelques définitions.

2. L’intégration continue (CI)

L’intégration continue (CI) est l’ensemble des processus automatisés d’intégration des changements de code de plusieurs développeurs qui collaborent à la construction d’un même produit logiciel. Il s’agit...

1. Introduction

La qualité d’un logiciel a les mêmes exigences que pour n’importe quel autre produit manufacturé. Il s’agit d’un processus, d’une démarche ou d’un système visant à définir le point d’équilibre entre satisfaire le consommateur et optimiser ses coûts de production. La non-qualité désigne un produit qui a été délivré et ne répond pas aux attentes du consommateur. La sur-qualité désigne un produit pour lequel le coût de revient de l’amélioration de sa qualité est disproportionné par rapport aux attentes des clients/utilisateurs, ce qui se traduit par un surcoût et/ou des délais excessifs. Ces deux types d’anomalies ont un coût particulièrement élevé et donc un impact très négatif sur la vie d’un projet ou d’une entreprise.

Nous allons dans ce chapitre évoquer les bonnes pratiques qui contribuent à cet équilibre bénéfice/risque et qui permettent de faire en sorte que chaque membre de l’équipe se sente concerné par la qualité de son produit.

2. Les mécanismes de relecture de code

Dans l’article décrivant le modèle open source, appelé "la cathédrale et le bazar", Eric Raymond explique la métaphore entre une cathédrale correspondant au modèle supposé ordonné du développement sous licence propriétaire et le bazar, modèle supposé désordonné par le volume de contributeurs sans organisation hiérarchique. Il émet ainsi la phrase suivante, qui a ensuite été dénommée "Loi de Linus" : "Given enough eyeballs, all bugs are shallow", ce qui signifie "s’il y a suffisamment de paires d’yeux, tous les bugs deviennent évidents à trouver".

L’œil des coéquipiers et du développeur senior reste une valeur sûre encore aujourd’hui pour détecter les problèmes au plus tôt dans la chaîne de valeur. Cette pratique est en plus rapide avec les outils actuels et très efficiente dans la durée...

1. Introduction

L’approche DevOps consiste à rendre l’acte de développement et de mise en production d’une nouvelle fonctionnalité, bénéficiant à l’utilisateur final, la plus simple possible pour l’équipe de développement. En pratique, tout au long du développement (du clavier du développeur à la mise en production effective), il s’agit de faire bénéficier aux développeurs, aux automates (comme la CI/CD par exemple) et au produit lui-même, d’un socle d’infrastructure homogène, adapté et scalable. L’infrastructure se doit de représenter une opportunité pour le projet et non une contrainte ou une menace.

2. Les conteneurs

La conteneurisation est l’un des éléments facilitateurs et représentatifs de la mise à l’échelle de DevOps, que ce soit sur l’axe de la taille (et de complexité) de la base de code comme sur l’axe de la taille de l’équipe R&D. Les conteneurs sont la garantie de la cohérence d’exécution d’un programme, quelle que soit la machine physique sur laquelle il est exécuté.

Pour un nouvel arrivant, la conteneurisation est un enjeu de montée en compétence important puisqu’en quelques minutes celui-ci peut bénéficier d’un environnement d’exécution à qualité équivalente de celui de ses nouveaux coéquipiers, en restant isolé des environnements existants. Le conteneur résout ainsi l’un des plus vieux et horripilants problèmes de l’industrie logicielle, à savoir le fameux "ça ne marche pas sur ma machine", par l’instanciation d’un package répétable et statique de tout ce dont le code d’application a besoin pour s’exécuter.

Le conteneur a été l’élément clé de l’avènement des architectures microservices, car il a apporté la portabilité et l’isolation nécessaires et suffisantes. L’arrivée des plateformes d’orchestration de conteneurs rend enfin la mise à l’échelle dynamique, considérablement plus performante...

1. Introduction

Dans ce chapitre, un focus tout particulier sera donné sur quelques processus et techniques clés et différenciants sur la partie "Ops" de l’approche DevOps, dans un système SaaS.

2. Processus de mise à jour d’une version