Toolchain-Anpassung

Passen Sie Ihre Toolchain an, indem Sie Ihre Toolchain mehreren Apps hinzufügen und ihre Funktionalität erweitern. Die Schritte sehen wie folgt aus:

1. Fügen Sie für jede Anwendung, die Sie auf den Toolchain-Pipelines erstellen möchten, eine GitHub-Tool-Integration hinzu.

2. Fügen Sie weitere GitHub-Integrationen für zusätzliche issue-, inventory-und evidence-Repositorys hinzu, die für bestimmte Anwendungen konfiguriert werden können.

   • Ob Sie diese zusätzlichen Repositorys für die Anwendungen benötigen, können Sie auf den Dokumentationsseiten und bei den bewährten Verfahren nachlesen.

   • Ein Subsystem ist eine Gruppe miteinander verbundener Dienste, die voneinander abhängig sind und gemeinsam entwickelt und bereitgestellt werden.

     • Dienste innerhalb eines einzelnen Subsystems müssen ein gemeinsames Inventar-Repository und einen gemeinsamen Evidenzspeicher nutzen. Jedes Subsystem muss eine 1:1-Beziehung zwischen seinem Inventar-Repository und seinem Evidenz-Speicher aufrechterhalten. Die Suche nach Beweismitteln über mehrere Schließfächer hinweg wird nicht unterstützt, da dies den Suchbereich erweitert und das Risiko von Datenkonflikten erhöht.
     • Sie können auch mehrere Subsysteme gruppieren, um denselben gemeinsamen Bestand und Schrank zu verwenden.
     • Beispiel: Gruppieren Sie verwandte Dienste (wie auth und user-profile) in einem Subsystem. Dieses Modell unterstützt skalierbares Microservice-Management in Continuous Delivery Umgebungen.

   • Die Anwendungs-Repos können auch als eigenes Issue-Repo dienen. Dies gilt nur, wenn die Option für GitHub-Probleme in der Toolintegration aktiviert ist.

   • Das Inventory-Repo sollte als einziges konsolidiertes Repository für die Speicherung Ihrer Build-Datensätze ausreichen, da die Datensätze bereits nach dem Parameter unterteilt sind app-name; solange sich dieser Parameter unterscheidet, geht nichts verloren und es kommt zu keinen Verwechslungen. Vielleicht möchten Sie jedoch die Dokumentation zum Inventar zu Rate ziehen, um Ideen für den Umgang mit diesem Repository zu erhalten, da dessen Hauptfunktion darin besteht, Bereitstellungen in der Continuous-Deployment-Pipeline zu unterstützen.

3. Richten Sie einen IBM Cloud® Object Storage-Bucket ein.

   IBM Cloud Object Storage ist die bevorzugte Nachweissegmentmethode für die Nachweisartefakte der Pipeline und für die Audit-Compliance erforderlich. Verwenden Sie dasselbe Object Storage-Bucket für jede Anwendung, die Sie in die CI-Toolchain einbringen. Verwenden Sie dasselbe Bucket Object Storage erneut, wenn Sie Ihre CI-Toolchain mit CD oder CC-Toolchain integrieren.

4. Optional: Zusätzliche Hashicorp-Vault-Integrationen

   Da die Integration des HashiCorp Vault-Tools nur einen Pfad unterstützt, benötigen Sie möglicherweise mehrere davon, je nachdem, wie Ihre HashiCorp Vault-Geheimnisse konfiguriert sind. Unterschiedliche Anwendungen benötigen möglicherweise unterschiedliche oder andere Berechtigungsnachweise voneinander.

Anpassung der CI- und PR-Pipeline

Passen Sie Ihre CI-und PR-Pipeline an, indem Sie sie mit den folgenden Schritten konfigurieren:

1. Erstellen Sie einen Git-Auslöser für jede Anwendung.

   • Kopieren Sie die vorhandenen Trigger, um einige Tedium-Trigger zu speichern, wenn Sie Trigger erstellen.
   • Stellen Sie sicher, dass jeder der Trigger auf das erforderliche GitHub-Repository und den entsprechenden Branch verweist.
   • Stellen Sie sicher, dass die folgenden Trigger-Eigenschaften festgelegt sind:
     • app-name (Text): App-Namen müssen innerhalb der verschiedenen Anwendungen eindeutig sein. Dies liegt daran, dass der App-Name im Inventar und in anderen Zusammenhängen als eindeutige Kennung verwendet wird, wenn die App platziert und zusammen mit Artefakten erfasst wird.
     • cos-bucket-name (Text): Der Name des Object Storage-Buckets, in dem sich die Anwendungsnachweise befinden.

2. Änderungen an den Umgebungseigenschaften für die einzelnen Anwendungen.

   • Die folgende Liste enthält die möglichen Umgebungseigenschaften, die für jede einzelne Anwendung in einen anderen Wert geändert werden müssen. Dies lässt sich durch die Verwendung der Trigger-Eigenschaften bei den Pipeline-Triggern erreichen; dadurch werden die Umgebungseigenschaften durch die von Ihnen gewählten Werte überschrieben.
     • app-name (Text): App-Namen müssen über die verschiedenen Anwendungen hinweg stets eindeutig sein, da der App-Name im Inventar usw. als eindeutige Kennung beim Platzieren und Erfassen von Artefakten verwendet wird.
     • cos-bucket-name (Text): Der Name des Object Storage-Buckets, in dem sich die Anwendungsnachweise befinden.
     • repository (Text): Dieser Parameter steuert, welches Anwendungsrepository für die Pipeline geklont wird und bei den unterschiedlichen Compliance- und Sicherheitstasks als Ziel für die CI- und die PR-Pipeline dient.
     • Optional: evidence-repo (Text): URL des Repositorys, das als Evidence Locker für die Anwendung dient.
     • Optional: incident-repo (Text): URL des Repositorys, das als Issue-Repository für die Anwendung dient.
     • Optional: inventory-repo (Text): URL des Repositorys, das als Inventar-Repository für die Anwendung dient.

3. optional step Richten Sie manuelle Trigger für jede der Anwendungen ein.

   • Technisch gesehen benötigen Sie eigentlich nur einen manuellen Trigger, da dessen Eigenschaften zum Zeitpunkt des Aufrufs bearbeitet werden können. Für Teams kann es jedoch nützlich sein, vorgefertigte manuelle Trigger zur Verfügung zu haben, um sich einige Schritte beim Erstellen aller möglichen kleinen Unterschiede zwischen den Apps zu ersparen.

4. optional step Erstellen Sie Timer-Trigger für Ihre Anwendungen.

   • Es empfiehlt sich, eine Anwendung regelmäßig neu zu erstellen und erneut zu validieren, damit Sie etwaige Compliance- und Sicherheitslücken sowie Probleme beim Erstellen im Blick behalten können.
   • Konfigurieren Sie die Trigger-Eigenschaften genauso wie beim manuellen Trigger, da der Timer-Trigger lediglich ein manueller Trigger mit einem Timer ist.
   • Verteilen Sie Ihre Cron-Jobs zeitlich, da es sonst zu einer Überlastung des Worker-Clusters kommen kann, was längere Build-Zeiten oder Verzögerungen zwischen den einzelnen Phasen zur Folge haben könnte.

Informationen zu den weiteren Eigenschaften, die für die Pipeline-Trigger oder innerhalb der Umgebungseigenschaften festgelegt werden können, finden Sie im Pipeline-Parameterkatalog.