Livraison continue

Un pipeline de livraison continue pourrait avoir une « porte » manuelle juste avant l'environnement de production. Une telle porte requiert une intervention humaine, et certains scénarios dans votre organisation pourraient nécessiter des portes manuelles dans les pipelines. Certaines portes manuelles peuvent être remises en question, alors que d'autres peuvent être légitimes. Un scénario légitime permet à l'équipe business de décider de livrer à la dernière minute. L'équipe d'ingénierie conserve une version livrable du produit après chaque print, et l'équipe business prend la décision finale de livrer le produit à tous les clients (ou à un échantillon de la population, voire à des personnes résidant dans une certaine zone géographique).

L'architecture du produit qui parcourt le pipeline est un facteur clé qui détermine l'anatomie du pipeline de livraison continue. Une architecture de produit à couplage fort génère un modèle graphique complexe de pipelines, dans lequel de multiples pipelines s'enchevêtrent avant que le produit ne soit finalement mis en production.

L'architecture du produit affecte également les différentes phases du pipeline et les artefacts produits dans chaque phase. Le pipeline génère d'abord les composants (les plus petites unités distribuables et testables du produit). Par exemple, une bibliothèque conçue par le pipeline peut être qualifiée de composant. C'est la phase Composant.

Les composants à couplage lâche constituent des sous-systèmes (les plus petites unités déployables et exploitables). Par exemple, un serveur est un sous-système. Un microservice fonctionnant dans un conteneur est également un exemple de sous-système. C'est la phase Sous-système. Contrairement aux composants, les sous-systèmes peuvent être mis en place et testés.

Par conséquent, il est possible d'apprendre au pipeline à assembler un système à partir de sous-systèmes à couplage lâche quand tout le système doit être livré en un bloc. C'est la phase Système.

Cette approche du tout ou rien force le sous-système le plus rapide à s'adapter à la vitesse de celui le plus lent. Nous utilisons le cliché « Une chaîne est aussi solide que le plus faible de ses maillons » pour avertir les équipes qui tombent dans le piège de ce modèle d'architecture.

Une fois validé, le système assemblé est alors promu en production sans autre modification. Il entre alors dans la phase finale appelée Production.

Remarque : ces phases sont plus logiques que physiques. Elles sont uniquement créées pour répartir un grand problème en plus petits sous-problèmes. Vous pouvez avoir plus ou moins de phases, en fonction de votre architecture et de vos exigences.

Sans la qualité, la vitesse n'a aucun intérêt pour nos clients. Les tests continus constituent une technique dans laquelle des tests automatisés sont intégrés au pipeline de livraison de logiciels et valident chaque changement entrant. Les tests s'exécutent durant chaque phase du pipeline pour valider les artefacts produits dans cette phase. Les tests unitaires et l'analyse de code statique valident les composants dans la phase Composant du pipeline. Les tests fonctionnels, de performance et de sécurité valident les sous-systèmes dans la phase Sous-système. Les tests d'intégration, de performance et de sécurité valident les systèmes dans la phase Système. Enfin, les smoke tests valident le produit dans la phase Production.