Release- und Versionskontrolle für Konstrukte verwenden

Versionskontrolle für AWS CDK

AWS CDK Gemeinsame Konstrukte können von mehreren Teams erstellt und von der gesamten Organisation gemeinsam genutzt werden. In der Regel veröffentlichen Entwickler neue Funktionen oder Fehlerkorrekturen in ihren gemeinsamen AWS CDK Konstrukten. Diese Konstrukte werden von AWS CDK Anwendungen oder anderen vorhandenen AWS CDK Konstrukten als Teil einer Abhängigkeit verwendet. Aus diesem Grund ist es wichtig, dass Entwickler ihr Konstrukt unabhängig voneinander aktualisieren und mit den richtigen semantischen Versionen veröffentlichen. AWS CDK Downstream-Anwendungen oder andere AWS CDK Konstrukte können ihre Abhängigkeit aktualisieren, um die neu veröffentlichte AWS CDK Konstruktversion zu verwenden.

Semantische Versionsverwaltung (Semver) ist ein Regelwerk oder eine Methode zur Bereitstellung eindeutiger Softwarenummern für Computersoftware. Versionen sind wie folgt definiert:

• Eine HAUPT-Version besteht aus inkompatiblen API-Änderungen oder einer bahnbrechenden Änderung.

• Eine MINOR-Version besteht aus Funktionen, die abwärtskompatibel hinzugefügt wurden.

• Eine PATCH-Version besteht aus abwärtskompatiblen Bugfixes.

Weitere Informationen zur semantischen Versionierung finden Sie unter Semantic Versioning Specification (SemVer) in der Semantic Versioning-Dokumentation.

Repository AWS CDK und Paketierung für Konstrukte

Da AWS CDK Konstrukte von verschiedenen Teams entwickelt und von mehreren AWS CDK Anwendungen verwendet werden, können Sie für jedes AWS CDK Konstrukt ein separates Repository verwenden. Dies kann Ihnen auch dabei helfen, die Zugriffskontrolle durchzusetzen. Jedes Repository könnte den gesamten Quellcode enthalten, der sich auf dasselbe AWS CDK Konstrukt bezieht, zusammen mit all seinen Abhängigkeiten. Indem Sie eine einzelne Anwendung (d. h. ein AWS CDK Konstrukt) in einem einzigen Repository speichern, können Sie den Umfang der Auswirkungen von Änderungen während der Bereitstellung verringern.

Das generiert AWS CDK nicht nur CloudFormation Vorlagen für die Bereitstellung der Infrastruktur, sondern bündelt auch Laufzeitressourcen wie Lambda-Funktionen und Docker-Images und stellt sie zusammen mit Ihrer Infrastruktur bereit. Es ist nicht nur möglich, den Code, der Ihre Infrastruktur definiert, und den Code, der Ihre Laufzeitlogik implementiert, in einem einzigen Konstrukt zu kombinieren — das ist eine bewährte Methode. Diese beiden Arten von Code müssen sich nicht in separaten Repositorys oder sogar in separaten Paketen befinden.

Um Pakete über Repository-Grenzen hinweg nutzen zu können, benötigen Sie ein privates Paket-Repository — ähnlich wie npm oder Maven Central PyPi, aber unternehmensintern. Sie benötigen außerdem einen Release-Prozess, der das Paket erstellt, testet und im privaten Paket-Repository veröffentlicht. Sie können private Repositorys, z. B. PyPi Server, mithilfe einer lokalen virtuellen Maschine (VM) oder Amazon S3 erstellen. Wenn Sie eine private Paketregistrierung entwerfen oder erstellen, müssen Sie unbedingt das Risiko einer Serviceunterbrechung aufgrund der hohen Verfügbarkeit und Skalierbarkeit berücksichtigen. Ein serverloser verwalteter Service, der zum Speichern von Paketen in der Cloud gehostet wird, kann den Wartungsaufwand erheblich reduzieren. Sie können ihn beispielsweise AWS CodeArtifactzum Hosten von Paketen für die gängigsten Programmiersprachen verwenden. Sie können es auch verwenden CodeArtifact , um externe Repository-Verbindungen einzurichten und diese innerhalb CodeArtifact zu replizieren.

Abhängigkeiten von Paketen im Paket-Repository werden vom Paketmanager Ihrer Sprache verwaltet (z. B. npm for TypeScript oder JavaScript applications). Ihr Paketmanager stellt sicher, dass Builds wiederholbar sind, indem er die spezifischen Versionen jedes Pakets aufzeichnet, von dem Ihre Anwendung abhängt, und Ihnen dann ermöglicht, diese Abhängigkeiten kontrolliert zu aktualisieren, wie das folgende Diagramm zeigt.

Erstellen Sie das Releasing für AWS CDK

Wir empfehlen Ihnen, Ihre eigene automatisierte Pipeline zu erstellen, um neue AWS CDK Construct-Versionen zu erstellen und zu veröffentlichen. Wenn Sie ein geeignetes Genehmigungsverfahren für Pull-Requests eingerichtet haben, kann die Pipeline, sobald Sie Ihren Quellcode festgeschrieben und in den Hauptzweig des Repositorys übertragen haben, eine Release-Candidate-Version erstellen und veröffentlichen. Auf diese Version kann gepusht CodeArtifact und getestet werden, bevor die produktionsreife Version veröffentlicht wird. Optional können Sie Ihre neue AWS CDK Construct-Version lokal testen, bevor Sie den Code mit dem Hauptzweig zusammenführen. Dies veranlasst die Pipeline, die produktionsreife Version zu veröffentlichen. Beachten Sie, dass gemeinsam genutzte Konstrukte und Pakete unabhängig von der nutzenden Anwendung getestet werden müssen, als ob sie der Öffentlichkeit zugänglich gemacht würden.

Das folgende Diagramm zeigt ein Beispiel für eine AWS CDK Versions-Release-Pipeline.

Sie können die folgenden Beispielbefehle verwenden, um npm-Pakete zu erstellen, zu testen und zu veröffentlichen. Melden Sie sich zunächst beim Artefakt-Repository an, indem Sie den folgenden Befehl ausführen.

aws codeartifact login --tool npm --domain <Domain Name> --domain-owner $(aws sts get-caller-identity --output text --query 'Account')  \
--repository <Repository Name> --region <AWS Region Name>

Führen Sie dann die folgenden Schritte aus:

1. Installieren Sie die erforderlichen Pakete auf der package.json Datei: npm install

2. Erstellen Sie die Release-Candidate-Version: npm version prerelease --preid rc

3. Erstellen Sie das npm-Paket: npm run build

4. Testen Sie das npm-Paket: npm run test

5. Veröffentlichen Sie das npm-Paket: npm publish