Etapes et tâches

Le tableau suivant répertorie les tâches exécutées dans un CD Pipeline. En outre, le tableau fournit également une vue d'ensemble de chacune de ces étapes:

• Tâche ou étape: fait référence au nom de l'étape tel qu'il est défini dans le fichier de configuration .pipeline-config.yaml.

• Brève description: fournit une explication concise des actions effectuées lors de l'exécution de l'étape.

• Customisation admissible: indique si les utilisateurs ont la possibilité de modifier ou de remplacer le comportement par défaut de l'étape en insérant un script personnalisé dans le fichier .pipeline-config.yaml.

• Implémentation de référence par défaut: Ceci indique si les pipelines DevSecOps sont livrés avec une implémentation prédéfinie ou par défaut pour l'étape. Notamment, pour certaines étapes telles que " unit-tests ou " setup, le pipeline DevSecOps n'offre pas d'implémentation prête à l'emploi. Au lieu de cela, les utilisateurs doivent fournir des scripts personnalisés ou du code adapté aux exigences de leur application.

• Collecte des informations collectées: indique si l'étape effectue la collecte des informations collectées standard. Lorsque DevSecOps Pipeline fournit une implémentation de référence pour une étape, la collecte de preuves est effectuée de manière prête à l'emploi. Toutefois, si l'utilisateur choisit de modifier ou de remplacer ces étapes prédéfinies, il doit s'assurer que leurs implémentations personnalisées incluent une collecte d'informations collectées appropriée. La même responsabilité incombe aux utilisateurs pour les étapes où le pipeline DevSecOps ne fournit pas d'implémentation prête à l'emploi, ce qui les oblige à collecter des preuves. La colonne indique l'entité (Utilisateur / Pipeline) chargée de la collecte des informations collectées.

• Ignorer autorisé (applicable à la version > = v10): indique si les utilisateurs peuvent refuser d'exécuter cette étape en définissant la propriété Ignorer sur true dans .pipeline-config.yaml. Toutefois, il est conseillé de faire preuve de prudence lors de l'utilisation de cette fonction, en particulier pour les étapes conçues pour collecter des preuves. L'omission de ces étapes peut entraîner l'absence d'informations collectées essentielles pour la génération.

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier .pipeline-config.yaml, voir Scripts personnalisés et Listes de paramètres de pipeline.

Ecart de déploiement

Lorsque la promotion de l'inventaire est prête, le pipeline de déploiement continu 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.

Pour accéder au delta de déploiement dans vos scripts de déploiement, vous pouvez utiliser les commandes suivantes:

# return a JSON file path with an array of inventory entries that were changed
get_env DEPLOYMENT_DELTA_PATH

# return a JSON file path with an array of inventory entries that were deleted
get_env DEPLOYMENT_DELTA_DELETIONS_PATH

# returns a JSON file path with an array of all inventory entries
get_env INVENTORY_ENTRIES_PATH

Calcul de la nomenclature de déploiement

La nomenclature de déploiement représente tous les les artefacts qui sont déployés dans le cadre d'une demande de changement. Une fois l'écart de déploiement calculé, le pipeline crée la nomenclature de déploiement en fonction de ces éléments.

Collecte du récapitulatif de preuves

Un récapitulatif de preuves est créé à partir de toutes les preuves qui ont été créées durant la génération pertinente ayant abouti à un déploiement. Les preuves créées lors du déploiement proprement dit sont également ajoutées au récapitulatif. Le récapitulatif de preuves est ajouté à la description de la demande de changement. Par défaut, le récapitulatif des informations collectées comprend les informations collectées au moment de la génération collectées dans le pipeline d'EC ainsi que les informations collectées collectées lors de l'exécution du pipeline CD en cours.

Les instructions suivantes s'appliquent exclusivement aux pipelines de CD ciblant les environnements de production. Utilisez l'indicateur target-environment-purpose pour déterminer si l'environnement est désigné comme pre_prod ou production.

Prérequis: dans le pipeline CD ciblant l'environnement pre_prod, définissez l'indicateur pre-prod-preuve-collection sur 1. Cela permet la collecte et le stockage des informations collectées de génération dans le casier d'informations collectées pour tous les actifs déployés par le pipeline CD, en effectuant le déploiement dans l'environnement de préproduction. Par défaut, pour les environnements désignés comme pre_prod, l'indicateur pre-prod-preuve-collection est défini sur 1.

Dans le pipeline CD ciblant l'environnement de production, définissez l'indicateur pre-prod-evidence-collection sur 1. Cela permet au pipeline CD ciblant l'environnement de production d'extraire les informations collectées collectées lors du déploiement dans l'environnement de préproduction. Par défaut, pour les environnements de production, l'indicateur pre-prod-evidence-collection est défini sur 0.

Une fois que l'indicateur pre-prod-evidence-collection est défini sur 1, les demandes de changement générées par le pipeline CD destiné à l'environnement de production incluent des références aux ID de demande de changement provenant des environnements de préproduction dans la zone Enregistrement de validation.

Pour plus d'informations, voir Récapitulatif des informations collectées.

Préparation et création d'une demande de changement

Tout ce qui modifie la base de référence doit faire l'objet d'un suivi au moyen d'une demande de changement. Ces changements sont notamment les mises à jour apportées au niveau de code existant, les modifications apportées à la configuration et les mises à jour apportées aux noeuds worker. La collecte des données de conformité de l'évaluation par les pairs est basée sur les données accessibles dans l'inventaire, le casier de preuves et le référentiel des problèmes.

Utilisez get_env CHANGE_REQUEST_ID pour optimiser la valeur de l'ID de demande de changement dans les étapes suivantes.

Ne modifiez pas la valeur de la variable qui utilise set_env, car il s'agit d'une mise en œuvre interne uniquement.

Cette étape crée la demande de changement en connectant les données de conformité disponibles en fonction des zones de demande d'extraction de promotion. La disponibilité de déploiement est calculée en fonction des preuves disponibles dans l'état de conformité collecté.

Si les preuves pré-prod sont capturées dans le déploiement de la production, les demandes de changement pré-prod sont liées à la demande de changement de la production. Pour plus d'informations, voir Données incluses dans les demandes de changement.

Plusieurs demandes de modification peuvent être pré-créées à l'aide d'un écouteur de demandes de modification dédié pour différentes configurations de déploiement, y compris les déploiements vers plusieurs régions, cibles et clusters. Une fois approuvées, ces demandes de modification préétablies peuvent être transmises au pipeline de déploiement juste à temps, qui exploite les informations précalculées pour accélérer le déploiement proprement dit.

Vérification de l'approbation de la demande de changement

Si tous les contrôles de conformité, tels que les tests unitaires, les tâches de l'analyseur de risque de code, la protection des branches et la détection des secrets, sont réussis, la demande de modification est approuvée automatiquement et la tâche s'exécute avec succès. Pour plus d'informations, voir Automatisation de la gestion des changements.

Si une vérification de compatibilité échoue, l'état de demande de changement n'est pas approuvé. Vous pouvez approuver la demande de modification manuellement et ajouter l'adresse change-request-id aux propriétés de l'environnement afin d'utiliser la demande de modification précédemment créée lors de la prochaine exécution. Vous pouvez également approuver la demande de changement manuellement et ajouter une balise d'urgence.

Déploiement

Dans la phase de déploiement, le pipeline déploie les artefacts construits dans un environnement, tel que staging ou prod. Les variables et les données d'identification pour ces étapes peuvent être consultées dans les sources suivantes :

• Variables de l'interface utilisateur de pipeline (get_env)

• Webhook de déclencheur de pipeline

Pour plus d'informations sur l'accès à ces variables, voir Scripts personnalisés.

Test d'acceptation

Vous pouvez exécuter un ensemble de tests automatisés pour vérifier que le déploiement a abouti et qu'il fonctionne comme prévu. Pour des raisons de traçabilité, assurez-vous que le journal de test contient une référence au niveau de code ou à l'image en cours de test.

Fermeture de demande de changement

Les détails relatifs au déploiement sont téléchargés dans le récapitulatif de fermeture, puis la tâche ferme la demande de changement. La catégorie close_category est ajoutée à la tâche de fermeture de demande de changement, avec les valeurs suivantes :

• Réussi (si le déploiement est prêt et que le déploiement du CD a réussi)
• Réussite avec des problèmes (si le récapitulatif comporte des problèmes, il n'a pas été prêt pour le déploiement et le déploiement de CD a eu lieu en cas d'urgence)

Fin de l'inventaire

Pour plus d'informations sur la fin de l'inventaire, voir Inventaire.

Redéployer une application

Annuler un déploiement

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

Permettre la traçabilité du déploiement

Lorsqu'une RP ou une demande de fusion est fusionnée, le système améliore la transparence et la traçabilité en fournissant une visibilité claire sur ce qui se passe ensuite. Il met automatiquement à jour le PR avec l'état de déploiement, permettant aux parties prenantes de suivre facilement la progression d'une correction ou d'une fonctionnalité sans avoir besoin d'accéder aux détails du pipeline. Cette approche rationalisée permet non seulement d'améliorer la transparence, mais aussi de faciliter la traçabilité, en réduisant les efforts nécessaires à la collecte et à la vérification des informations. Après un déploiement réussi, une étiquette au format deploy:{region}:{env} est appliquée aux pull requests incluses dans le déploiement.

Un indicateur opt-in deployment-traceability, est disponible pour activer cette fonctionnalité dans le pipeline CD. Les utilisateurs peuvent activer la traçabilité des déploiements en paramétrant l'indicateur sur 1 lorsque cela est nécessaire.

Pour renforcer cette fonctionnalité, si l'utilisateur souhaite fournir un jeton spécifique pour ajouter des étiquettes aux PR dans le référentiel de l'application, il peut utiliser les propriétés d'environnement suivantes pour spécifier le jeton Git. L'ordre dans lequel le jeton Git est recherché est le suivant :

• Une propriété d'environnement existante pour un jeton spécifique au référentiel : git-token-$repo_name-$repo_org.
• Une nouvelle propriété d'environnement pour un jeton spécifique à une organisation : git-token-$repo_org.