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 eigene Issues-Repos dienen. Dies gilt nur, wenn die Option für GitHub-Probleme in der Toolintegration aktiviert ist.

• Das Inventar-Repo muss als einziges konsolidiertes Repository für die Aufzeichnung Ihrer Build-Datensätze ausreichen, da die Datensätze bereits durch den Parameter unterteilt sind. Solange dieser app-name Parameter unterschiedlich ist, geht nichts verloren und es kommt zu keiner Verwechslung. Sie sollten jedoch die Inventardokumentation zu Rate ziehen, um Ideen zum Umgang mit diesem Repository zu erhalten, da dessen Hauptfunktion darin besteht, Bereitstellungen in der kontinuierlichen Bereitstellungspipeline zu unterstützen.

1. 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.

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

   Da die Integration des HashiCorp-Vault-Tools nur einen Pfad unterstützt, benötigen Sie möglicherweise mehr davon, je nachdem, wie Ihre geheimen Schlüssel für HashiCorp Vault 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 erforderlichen 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 Bestand, DevOps-Insights und anderen als eindeutige ID verwendet wird, wenn Artefakte platziert und aufgezeichnet werden.
     • cos-bucket-name (Text): Der Name des Object Storage Buckets, in dem die Anwendungsnachweise abgelegt sind.

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 kann mithilfe der Triggereigenschaften der Pipeline-Trigger erreicht werden, die die Umgebungseigenschaften mit den von Ihnen gewählten Werten überschreiben.
     • app-name (Text): App-Namen müssen über die verschiedenen Anwendungen hinweg immer eindeutig sein, da der App-Name im Inventar, in DevOps den Insights usw. als eindeutige Kennung beim Platzieren und Aufzeichnen von Artefakten verwendet wird.
     • cos-bucket-name (Text): Der Name des Object Storage Buckets, in dem die Anwendungsnachweise abgelegt sind.
     • 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 Beweisspeicher für die Anwendung dient.
     • Optional: incident-repo (Text): URL des Repositorys, das als Issues-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 Auslöser für jede der Anwendungen ein.

   • Technisch gesehen benötigen Sie 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 zu haben, um sich einige Schritte beim Schreiben aller möglichen kleinen Unterschiede zwischen den Apps zu sparen.

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

   • Es empfiehlt sich, eine Anwendung regelmäßig neu zu erstellen und zu validieren, damit Sie stets über alle Compliance- und Sicherheitsprobleme sowie alle Probleme bei der Erstellung auf dem Laufenden sind.
   • Konfigurieren Sie die Triggereigenschaften auf dieselbe Weise wie den manuellen Trigger, da der Timer-Trigger lediglich ein manueller Trigger mit Zeitsteuerung ist.
   • Verteilen Sie Ihre Cron-Jobs zeitlich, da Sie sonst den Worker-Cluster überlasten könnten und Ihre Jobs unter längeren Build-Zeiten oder Verzögerungen zwischen den einzelnen Phasen leiden könnten.

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