Amazon CodeCatalyst ist nicht mehr offen für neue Kunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Wie migriert man von CodeCatalyst.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Als Blueprint-Benutzer mit Lifecycle Management arbeiten

Lifecycle Management ist die Fähigkeit, eine Codebasis aus aktualisierten Optionen oder Versionen eines Blueprints neu zu generieren. Auf diese Weise kann ein Blueprint-Autor den Softwareentwicklungszyklus jedes Projekts, das einen bestimmten Blueprint enthält, zentral verwalten. Wenn beispielsweise ein Sicherheitsupdate auf einen Webanwendungs-Blueprint übertragen wird, kann jedes Projekt, das den Webanwendungs-Blueprint enthält oder aus dem Webanwendungs-Blueprint erstellt wurde, diesen Fix automatisch übernehmen. Mit demselben Management-Framework können Sie als Blueprint-Benutzer auch Blueprint-Optionen ändern, nachdem sie ausgewählt wurden.

Verwendung des Lebenszyklusmanagements für bestehende Projekte

Sie können das Lebenszyklusmanagement für Projekte verwenden, die anhand von Blueprints oder für bestehende Projekte erstellt wurden, die keinen Blueprints zugeordnet sind. Beispielsweise können Sie einer fünf Jahre alten Java-Anwendung, die nie aus einem Blueprint erstellt wurde, einen Blueprint für Standardsicherheitspraktiken hinzufügen. Der Blueprint generiert einen Arbeitsablauf für Sicherheitsscans und anderen zugehörigen Code. Dieser Teil der Codebasis in der Java-Anwendung wird nun automatisch mit den Best Practices Ihres Teams auf dem neuesten Stand gehalten, sobald Änderungen am Blueprint vorgenommen werden.

Verwenden Sie das Lebenszyklusmanagement für mehrere Blueprints in einem Projekt

Da Blueprints architektonische Komponenten darstellen, können mehrere Blueprints häufig zusammen in demselben Projekt verwendet werden. Ein Projekt könnte beispielsweise aus einem zentralen Web-API-Blueprint bestehen, der von einem Plattformingenieur des Unternehmens erstellt wurde, zusammen mit einem Release-Check-Blueprint, der vom App-Sicherheitsteam erstellt wurde. Jeder dieser Blueprints kann unabhängig aktualisiert werden und merkt sich die in der Vergangenheit auf sie angewendeten Zusammenführungslösungen.

Arbeiten mit Konflikten in Lifecycle-Pull-Requests

Gelegentlich können Lifecycle-Pull-Requests zu Merge-Konflikten führen. Diese können manuell gelöst werden. Lösungen werden bei nachfolgenden Blueprint-Updates gespeichert.

Abmeldung von Änderungen im Lifecycle-Management

Benutzer können einen Blueprint aus einem Projekt entfernen, um alle Verweise auf den Blueprint aufzuheben und Lebenszyklus-Updates abzulehnen. Aus Sicherheitsgründen werden dadurch weder der Code noch die Ressourcen des Projekts entfernt oder beeinträchtigt, auch nicht das, was aus dem Blueprint hinzugefügt wurde. Weitere Informationen finden Sie unter Einen Blueprint von einem Projekt trennen, um Aktualisierungen zu stoppen.

Überschreiben des Lebenszyklusmanagements eines Blueprints in einem Projekt

Wenn Sie die Aktualisierungen eines Blueprints an bestimmten Dateien in Ihrem Projekt außer Kraft setzen möchten, können Sie eine Eigentümerdatei in Ihr Repository aufnehmen. GitLabDie Spezifikation „Code Owners“ ist die empfohlene Richtlinie. Der Blueprint respektiert immer die Code-Eigentümerdatei vor allem anderen und kann ein Beispiel wie das Folgende generieren:

new BlueprintOwnershipFile(sourceRepo, {
      resynthesis: {
        strategies: [
          {
            identifier: 'dont-override-sample-code',
            description: 'This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.',
            strategy: MergeStrategies.neverUpdate,
            globs: [
              '**/src/**',
              '**/css/**',
            ],
          },
        ],
      },
    });

Dadurch wird eine .ownership-file mit dem folgenden Inhalt generiert:

[dont-override-sample-code] @amazon-codecatalyst/blueprints.import-from-git
# This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.
# Internal merge strategy: neverUpdate
**/src/**
**/css/**