Personnalisation de la chaîne d'outils

Personnalisez votre chaîne d'outils en ajoutant votre chaîne d'outils à plusieurs applications et augmentez ses fonctionnalités. Pour ce faire, procédez comme suit :

1. Ajoutez une intégration de l'outil GitHub pour chaque application que vous souhaitez développer sur les pipelines de la chaîne d'outils.

2. Ajoutez d'autres intégrations GitHub pour les problèmes, l'inventaire et les référentiels d'informations collectées supplémentaires qui peuvent être configurés pour certaines applications.

   • Consultez les pages de documentation et les meilleures pratiques pour comprendre si vous avez besoin de ces référentiels supplémentaires pour les applications.

   • Un sous-système est un ensemble de services connexes qui dépendent les uns des autres et qui sont développés et déployés ensemble.

     • Les services au sein d'un même sous-système doivent partager un référentiel d'inventaire et un coffre-fort communs. Chaque sous-système doit maintenir une relation 1:1 entre son référentiel d'inventaire et son coffre-fort de preuves. Les recherches de preuves dans plusieurs casiers ne sont pas prises en charge, car elles élargissent l'espace de recherche et augmentent le risque de conflit entre les données.
     • Vous pouvez également regrouper plusieurs sous-systèmes afin d'utiliser le même inventaire et le même casier partagés.
     • Exemple : regrouper les services connexes (tels que auth et user-profile) dans un seul sous-système. Ce modèle prend en charge la gestion évolutive des microservices dans Continuous Delivery les environnements.

   • Les dépôts d'applications peuvent également servir de dépôt de tickets à part entière. Cette option est applicable uniquement lorsque l'option GitHub issues est activée sur l'intégration d'outils.

   • Le dépôt Inventory doit suffire en tant que dépôt unique et consolidé pour l'enregistrement de vos historiques de compilation, car ceux-ci sont déjà classés par app-name. Tant que ce paramètre est différent, rien ne risque d'être perdu ou de prêter à confusion. Vous pouvez toutefois consulter la documentation relative à l'inventaire pour trouver des idées sur la manière de gérer ce dépôt, car sa fonction principale est de faciliter les déploiements dans le pipeline de déploiement continu.

3. Configurer un compartiment IBM Cloud® Object Storage.

   IBM Cloud Object Storage est la méthode de casier de preuves préférée pour les artefacts de preuve de pipeline et elle est obligatoire pour la conformité d'audit. Utilisez le même compartiment Object Storage pour chaque application que vous apportez dans la chaîne d'outils d'EC. Réutilisez également le même compartiment Object Storage lorsque vous intégrez votre chaîne d'outils d'EC à la chaîne d'outils CD ou CC.

4. Facultatif : Intégrations Hashicorp Vault supplémentaires.

   L'intégration de l'outil HashiCorp Vault ne prenant en charge qu'un seul chemin d'accès, vous pourriez en avoir besoin de plusieurs selon la configuration de vos secrets HashiCorp Vault. Des applications différentes peuvent avoir besoin de données d'identification différentes ou d'autres données d'identification les unes des autres.

Personnalisation du pipeline CI/PR

Personnalisez votre pipeline d'EC et de DA en les configurant en procédant comme suit:

1. Créez un déclencheur Git pour chaque application.

   • Copiez les déclencheurs existants pour sauvegarder certains éléments tedium lorsque vous créez des déclencheurs.
   • Assurez-vous que chaque déclencheur pointe vers le dépôt et la branche GitHub requis.
   • Assurez-vous que les propriétés de déclenchement suivantes sont définies :
     • app-name (texte): Les noms d'application doivent être uniques dans les différentes applications. En effet, le nom de l'application est utilisé dans l'inventaire, ainsi que dans d'autres contextes, comme identifiant unique lorsqu'elle est associée à des artefacts et enregistrée avec ceux-ci.
     • cos-bucket-name (texte): Nom du compartiment Object Storage dans lequel sont stockées les données de vérification des applications.

2. Modifications des propriétés d'environnement pour chaque application.

   • Il s'agit d'une liste des propriétés d'environnement dont les valeurs devront peut-être être modifiées pour chacune des applications. Pour ce faire, vous pouvez utiliser les propriétés des déclencheurs du pipeline; celles-ci remplacent les propriétés d'environnement par les valeurs de votre choix.
     • app-name (texte): Les noms d'application doivent toujours être uniques d'une application à l'autre, car ils sont utilisés dans l'inventaire, entre autres, comme identifiant unique lors du placement et de l'enregistrement des artefacts.
     • cos-bucket-name (texte): Nom du compartiment Object Storage dans lequel sont stockées les données de vérification des applications.
     • repository (texte) : Ce paramètre détermine le référentiel d'application qui est cloné sur le pipeline et sert de cible pour les pipelines d'intégration continue et de demande d'extraction pour les diverses tâches de conformité et de sécurité.
     • Facultatif : evidence-repo (texte): URL du dépôt servant de référentiel de preuves pour l'application.
     • Facultatif : incident-repo (texte): URL du dépôt servant de dépôt de tickets pour l'application.
     • Facultatif : inventory-repo (texte): URL du dépôt servant de dépôt d'inventaire pour l'application.

3. optional step Configurez des déclencheurs manuels pour chacune des applications.

   • Techniquement, un seul déclencheur manuel suffit, car ses propriétés peuvent être modifiées au moment de l'appel; toutefois, il peut être utile pour les équipes de disposer de déclencheurs manuels pré-configurés afin de leur éviter d'avoir à rédiguer toutes les petites différences possibles entre les applications.

4. optional step Créez des déclencheurs de minuterie pour vos applications.

   • Il est recommandé de recompiler et de revalider fréquemment une application, afin de rester à jour sur les problèmes de conformité et de vulnérabilité, ainsi que sur les éventuels problèmes de compilation.
   • Configurez les propriétés du déclencheur de la même manière que vous avez configuré le déclencheur manuel, car le déclencheur temporisé n'est rien d'autre qu'un déclencheur manuel activé par une minuterie.
   • Échelonnez vos tâches cron les unes par rapport aux autres, sinon vous risquez de surcharger le cluster de travail et vos tâches pourraient subir une augmentation des temps de compilation ou des retards entre les étapes.

Pour plus d'informations sur les autres propriétés pouvant être définies sur les déclencheurs de pipeline ou dans les propriétés d'environnement, consultez le catalogue des paramètres de pipeline.