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 GitHub d'outil 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ôts pour leurs propres problèmes. Cette option est applicable uniquement lorsque l'option GitHub issues est activée sur l'intégration d'outils.

• Le référentiel d'inventaire doit suffire en tant que référentiel consolidé unique pour enregistrer vos enregistrements de compilation, car ceux-ci sont déjà divisés par le paramètre app-name. Tant que ce paramètre est différent, rien ne sera perdu ni confondu. Cependant, vous pouvez consulter la documentation de l'inventaire pour obtenir des idées sur la manière de gérer ce référentiel, car sa fonction principale est de faciliter les déploiements dans le pipeline de déploiement continu.

1. Configurez un IBM Cloud® Object Storage bucket.

   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.

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

   Etant donné que l'intégration de l'outil HashiCorp Vault ne prend en charge qu'un seul chemin, vous pouvez en avoir besoin en fonction de la manière dont vos secrets HashiCorp Vault sont configurés. 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 et RP

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 chacun des déclencheurs pointe vers le référentiel et GitHub la branche 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. Cela est dû au fait que le nom de l'application est utilisé dans l'inventaire, DevOps Insights, et d'autres en tant qu'identificateur unique lorsqu'il est placé et enregistré avec des artefacts.
     • cos-bucket-name (texte): Nom du compartiment Object Storage dans lequel sont placées les preuves 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, utilisez les propriétés de déclenchement des déclencheurs de pipeline, qui remplacent les propriétés environnementales par les valeurs que vous avez choisies.
     • app-name (texte): Les noms des applications doivent toujours être uniques entre les différentes applications, car ils sont utilisés dans l'inventaire, DevOps les statistiques, etc., comme identifiant unique lors du placement et de l'enregistrement des artefacts.
     • cos-bucket-name (texte): Nom du compartiment Object Storage dans lequel sont placées les preuves 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 qui sert de coffre-fort de preuves pour l'application.
     • Facultatif : incident-repo (texte): URL du dépôt qui sert de dépôt de problèmes pour l'application.
     • Facultatif : inventory-repo (texte): URL du référentiel qui sert de référentiel d'inventaire pour l'application.

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

   • Techniquement, vous n'avez besoin que d'un seul déclencheur manuel, car ses propriétés peuvent être modifiées au moment de l'appel, mais il peut être utile pour les équipes de disposer de déclencheurs manuels pré-composés afin de leur éviter d'avoir à écrire 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 reconstruire et de revalider fréquemment une application afin de rester au fait des problèmes de conformité et de vulnérabilité, ainsi que des 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 qu'un déclencheur manuel sur une minuterie.
   • Échelonnez vos tâches cron les unes par rapport aux autres, sinon vous risquez de surcharger le cluster de travailleurs et vos tâches pourraient subir une augmentation des temps de compilation ou un retard 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.