Als Blueprint-Benutzer mit Lifecycle Management arbeiten

Lebenszyklusmanagement 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 anhand dessen erstellt wurde, diesen Fix automatisch übernehmen. Dasselbe Management-Framework ermöglicht es Ihnen als Blueprint-Benutzer auch, Blueprint-Optionen zu ändern, nachdem sie ausgewählt wurden.

Verwenden des Lebenszyklusmanagements für bestehende Projekte

Sie können das Lebenszyklusmanagement für Projekte verwenden, die anhand von Blueprints erstellt wurden, oder für bestehende Projekte, die keinen Blueprints zugeordnet sind. Sie können beispielsweise einer five-year-old Java-Anwendung, die nie anhand eines Blueprints erstellt wurde, einen Standard-Blueprint für Sicherheitspraktiken hinzufügen. Der Blueprint generiert einen Workflow für Sicherheitsscans und anderen zugehörigen Code. Dieser Teil der Codebasis in der Java-Anwendung wird nun bei jeder Änderung des Blueprints automatisch mit den Best Practices Ihres Teams auf dem neuesten Stand gehalten.

Verwenden des Lebenszyklusmanagements 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, sowie einem vom App-Sicherheitsteam erstellten Blueprint für die Versionsprüfung. Jeder dieser Blueprints kann unabhängig aktualisiert werden und erinnert sich an die in der Vergangenheit für ihn geltenden Zusammenführungslösungen.

Anmerkung

Da es sich um beliebige Architekturkomponenten handelt, sind nicht alle Blueprints zusammen sinnvoll oder funktionieren logisch zusammen, obwohl sie immer noch versuchen, miteinander zu verschmelzen.

Umgang mit Konflikten in Lifecycle-Pull-Requests

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

Abmeldung von Änderungen im Lebenszyklusmanagement

Benutzer können einen Blueprint aus einem Projekt entfernen, um alle Verweise auf den Blueprint aufzuheben und Lebenszyklus-Updates zu deaktivieren. 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 Trennen der Zuordnung eines Blueprints zu einem Projekt, um Aktualisierungen zu beenden.

Überschreiben des Lebenszyklusmanagements eines Blueprints in einem Projekt

Wenn Sie die Aktualisierungen eines Blueprints an bestimmten Dateien in Ihrem Projekt überschreiben möchten, können Sie eine Eigentümerdatei in Ihr Repository aufnehmen. GitLabDie Spezifikation von Code Owners entspricht den empfohlenen Richtlinien. Der Blueprint berücksichtigt immer die Datei mit den Code-Besitzern 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/**