Présentation des pipelines DevSecOps
Les différents pipelines fournis dans les chaînes d'outils d'intégration et de déploiement continus de référence sont basés sur le support Continuous Delivery pour Tekton Pipelines. Pour en savoir plus sur les pipelines Tekton, voir Utilisation des pipelines Tekton.
Il n'est pas nécessaire d'être un expert Tekton pour utiliser les pipelines de référence. Les pipelines de référence sont prédéfinis avec une structure de base qui inclut des emplacements pour des scripts personnalisés pour des étapes telles que la construction, les tests automatisés et le déploiement. Les utilisateurs peuvent déclarer leurs scripts personnalisés pour leurs propres pipelines et définir des valeurs pour différentes propriétés d'environnement pour un pipeline donné.
Types de statut de pipeline
Il est important de comprendre les incidents ou les défaillances qui se produisent pour un pipeline de référence à certains stades. En théorie, deux types de statut différents résultent d'une exécution de tâche dans un pipeline de conformité :
- Statut de conformité: L'état de réussite ou d'échec d'un contrôle ou d'un ensemble de contrôles sur le site
some. - Statut de pipeline : Etat de réussite ou d'échec d'une exécution de tâche proprement dite.
Si un test, une analyse ou une vérification échoue, cela n'entraîne pas l'échec ou l'arrêt du pipeline proprement dit. La tâche qui exécute le test est signalée en vert.
Du point de vue de la conformité, le résultat de l'unité de test ayant échoué n'a aucun impact sur le déploiement. Vous pouvez déployer des artefacts avec des vérifications ayant échoué, mais le processus conserve la preuve de cette activité.
Le flux de conformité ne vous empêche pas de publier un correctif lorsqu'une indisponibilité se produit. Par exemple, le message généré pour une exécution signalée en vert pour une tâche de test d'unité qui a détecté des tests défectueux est
le suivant : The task ran successfully and found the following issues.
Lorsqu'une tâche échoue et est signalée en rouge, le pipeline ne peut pas ou ne doit pas continuer. Voici des exemples de défaillance :
- Erreurs dans une tâche ou dans le pipeline.
- Il s'est passé quelque chose et la poursuite de l'exécution du pipeline n'a aucun sens.
Par exemple, si une génération d'artefact échoue au cours de l'intégration continue, l'objectif du processus d'intégration continue proprement dit disparaît.
Pour maintenir le statut de pipeline final synchronisé avec les résultats de conformité, une tâche est utilisée à la fin du pipeline pour vérifier les résultats de conformité et définir la valeur red ou green pour le
statut d'exécution du pipeline.
Pipeline de demande d'extraction
Le pipeline de demande d'extraction exécute des vérifications de statut de conformité prédéfinies sur une demande d'extraction pour le référentiel d'application spécifié. Ces vérifications de statut peuvent vous empêcher de fusionner la pull
request dans la branche active par défaut, habituellement master, si les vérifications n'aboutissent pas. Ouvrir ou mettre à jour une demande d'extraction sur la branche active par défaut pour déclencher l'exécution du pipeline
de demandes d'extraction. Les utilisateurs peuvent exécuter leur propre configuration pour le pipeline et les tests dans des étapes personnalisées. Pour plus d'informations sur le pipeline de demande d'extraction, voir Pipeline de demande d'extraction.
Pipeline d'intégration continue
Le pipeline d'intégration continue génère les artefacts déployables à partir des référentiels d'applications. Avant de générer des artefacts, le pipeline vérifie que le code est analysé et testé, comme pour le traitement des demandes d'extraction. Les artefacts générés sont également analysés pour vérifier la présence de vulnérabilités et signés dans le pipeline avant d'être marqués prêts pour la publication et le déploiement dans l'inventaire. Contrairement au pipeline de demande d'extraction, le pipeline d'intégration continue collecte des preuves et des artefacts de résultat à chaque étape de la génération, telle que le test, l'analyse et la signature. Ces données sont en corrélation avec les artefacts de génération et peuvent faire l'objet d'un suivi via le processus de déploiement et la gestion des changements. Pour plus d'informations sur le pipeline d'intégration continue, voir Pipeline d'intégration continue.
Pipeline de déploiement continu
Le pipeline de déploiement continu génère toutes les preuves et le contenu du résumé de la demande de changement. Le pipeline déploie les artefacts de génération dans un environnement spécifique, par exemple, préproduction ou production, puis collecte, crée et télécharge la totalité des fichiers journaux, preuves et artefacts existants dans le casier de preuves. Pour plus d'informations sur le pipeline de déploiement continu, voir Pipeline de déploiement continu.
Pipeline de conformité continue
Le pipeline de conformité continue analyse périodiquement les artefacts déployés et leurs référentiels source à la recherche de vulnérabilités plus récentes depuis que les artefacts ont été déployés en production. Le pipeline permet également de suivre automatiquement les écarts par rapport à la date d'échéance et de prendre conscience de l'application. Pour plus d'informations, voir Pipeline de conformité continue.
Flux de travaux d'inventaire
Voir Preuves.
Voir Inventaire.
L'intégration continue écrit dans l'inventaire
L'inventaire contient plusieurs branches, dont la branche par défaut. Ces branches peuvent représenter des étapes, des environnements ou des régions de déploiement ou un mélange de ces options, en fonction de la configuration et de l'utilisation.
La branche par défaut est alimentée par les constructions d'intégration continue. La dernière validation dans la cible, par exemple, staging, contient une étiquette indiquant qu'il s'agit du dernier déploiement effectué.
Si la branche par défaut pour l'inventaire est remplacée par une autre branche, vous devez rebaser les commits de la branche par défaut précédente vers la nouvelle branche par défaut afin de rendre l'historique des commits de l' Git e linéaire.
Promotion
Pour promouvoir vers une branche cible, créez une demande d'extraction. Le contenu de la demande d'extraction remplit les zones de demande de changement. Une fois la demande d'extraction de promotion révisée, vous pouvez la fusionner.
Ecart de déploiement
Une fois la demande d'extraction de promotion fusionnée, le pipeline de déploiement peut démarrer. L'écart de déploiement est la différence entre le contenu du dernier déploiement effectué et celui du déploiement en cours. L'écart de déploiement répertorie les éléments d'inventaire en cours de déploiement.
Fin
Lorsque le déploiement se termine, l'étiquette latest est déplacée vers l'avant.
Au cours du déclencheur dev-mode, les balises ne seront pas avancées, le but du déclencheur dev-mode est uniquement de tester le pipeline CD et il n'est pas recommandé de l'utiliser dans l'environnement de production.
Promotion vers d'autres environnements
Vous pouvez effectuer une promotion et un déploiement à partir de n'importe quelle branche vers une autre branche.
Paysage d'inventaire
L'état actuellement déployé contient le contenu à déployer dans un environnement. Chaque validation promue dans les branches cible contient l'ID d'exécution de pipeline et l'ID de demande de changement appropriés comme étiquette. Certaines validations peuvent comporter plusieurs étiquettes, par exemple, lorsque vous relancez un déploiement ayant échoué. L'inventaire contient tous les éléments d'information nécessaires pour réexécuter les déploiements.
Configuration pour une cible avec plusieurs régions
La configuration pour une cible avec plusieurs régions est une itération sur ce modèle qui introduit plusieurs étiquettes latest pour un environnement cible unique. Ce modèle permet à plusieurs pipelines continus de fonctionner
sur la même cible pour différents types de cas d'utilisation.
Par exemple, vous pouvez utiliser le même environnement cible pour plusieurs régions (par exemple, us-south et eu-de) dans l'environnement cible de production et la branche d'inventaire.
Pour spécifier la région de déploiement par le pipeline de déploiement continu, utilisez le paramètre region. Pour plus d'informations sur ce paramètre, voir Paramètres de pipeline de déploiement continu.
Les équipes n'ont pas besoin de créer une branche différente pour chaque région, comme us-south-prod et eu-de-prod, et de gérer la promotion de manière redondante. A la place, indiquez ces cibles supplémentaires pour
la même branche d'inventaire, puis utilisez-les en tant qu'étiquettes Git.
Dans cette configuration, la branche prod a plusieurs tags latest sur la même branche, tels que us-south_prod_latest et eu-de_prod_latest, et chaque pipeline de déploiement continu responsable de chaque
région peut utiliser ces tags pour déployer.
Exemple de scénario
Un jeu de changements, qui pourra ensuite être déployé partout, peut être publié au départ dans une seule région. Vous pouvez ensuite déployer progressivement cet ensemble de modifications dans d'autres régions en utilisant des pipelines de déploiement continu qui ciblent ces régions.