Dies ist der AWS CDK v2-Entwicklerhandbuch. Das ältere CDK v1 wurde am 1. Juni 2022 in die Wartung aufgenommen und der Support wurde am 1. Juni 2023 eingestellt.
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.
AWS CDK-Versionierung
Dieses Thema enthält Referenzinformationen darüber, wie das AWS Cloud Development Kit (AWS CDK) mit der Versionierung umgeht.
Versionsnummern bestehen aus drei numerischen Versionsteilen: Hauptversion. geringfügig. patchen und weitgehend den Prinzipien der semantischen Versionierung
Neben- und Patch-Versionen sind abwärtskompatibel. Der in einer früheren Version mit derselben Hauptversion geschriebene Code kann innerhalb derselben Hauptversion auf eine neuere Version aktualisiert werden. Es wird weiter gebaut und ausgeführt, sodass ein funktionell gleichwertiges Ergebnis erzielt wird. Für einige fortgeschrittene Anwendungsfälle sind kleine Änderungen an Ihrem Code erforderlich, wie im nächsten Thema beschrieben.
AWS Kompatibilität mit dem CDK Toolkit
Jede Version der AWS Haupt-Construct-Bibliothek (aws-cdk-lib) ist mit der AWS CDK Toolkit-CLI (aws-cdk-cli) und der Toolkit-Bibliothek (@aws-cdk/toolkit-lib) kompatibel, die zum Zeitpunkt der Veröffentlichung der AWS Construct Library aktuell waren. Sie ist auch mit jeder neueren Version des CDK Toolkits kompatibel. AWS Jede Version der AWS Construct-Bibliothek behält diese Kompatibilität bis zum Ende der Lebensdauer der Bibliothek bei. Solange Sie eine unterstützte Version von AWS Construct Library verwenden, ist es daher immer sicher, Ihre AWS CDK Toolkit-Version zu aktualisieren.
Jede Version der AWS Construct Library funktioniert möglicherweise auch mit AWS CDK Toolkit-Versionen, die älter sind als die Version, die zum Zeitpunkt der Veröffentlichung der AWS Construct Library aktuell war. Dies ist jedoch nicht garantiert. Die Kompatibilität hängt von der Cloud-Assembly-Schemaversion der AWS Construct Library ab. Das AWS CDK generiert während der Synthese eine Cloud-Assembly und das AWS CDK Toolkit verwendet sie für die Bereitstellung. Das Schema, das das Format der Cloud-Assembly definiert, ist streng spezifiziert und versioniert. Daher müsste eine ältere Version des AWS CDK Toolkits die Cloud-Assembly-Schemaversion der AWS Construct Library unterstützen, damit sie kompatibel sind.
Wenn die von der AWS Construct Library benötigte Cloud-Assembly-Version nicht mit der vom AWS CDK Toolkit unterstützten Version kompatibel ist, erhalten Sie eine Fehlermeldung wie die folgende:
Cloud assembly schema version mismatch: Maximum schema version supported is 3.0.0, but found 4.0.0. Please upgrade your CLI in order to interact with this app.
Um diesen Fehler zu beheben, aktualisieren Sie das AWS CDK Toolkit auf eine Version, die mit der erforderlichen Cloud-Assembly-Version kompatibel ist, oder auf die neueste verfügbare Version. Die Alternative (Herabstufung der AWS Construct Library-Module, die Ihre App verwendet) wird im Allgemeinen nicht empfohlen.
Anmerkung
Weitere Informationen zu den genauen Kombinationen von Versionen, die zusammenarbeiten, finden Sie in der Kompatibilitätstabelle
AWS Versionsverwaltung der Construct-Bibliothek
Die Module in der AWS Construct Library durchlaufen bei ihrer Entwicklung vom Konzept bis zur ausgereiften API verschiedene Phasen. Verschiedene Phasen bieten unterschiedliche Grade an API-Stabilität in nachfolgenden Versionen des AWS CDK.
Mit Ausnahme von Szenarien, in denen die im nächsten Thema dokumentierten Vorbehalte gelten, ist die Hauptbibliothek AWS Construct Library (aws-cdk-lib) stabil und die Bibliothek folgt APIs im Großen und Ganzen den Prinzipien der semantischen Versionierung. Die Bibliothek enthält AWS CloudFormation (L1) -Konstrukte für alle AWS Dienste, die automatisch aus Schemas von CloudFormation Ressourcenanbietern generiert werden und manchmal abwärtsinkompatible Updates enthalten können. Sie enthält auch Konstrukte auf höherer Ebene (L2 und L3) und die CDK-Kernklassen wie und, die alle stabil sind. App Stack APIs werden erst mit der nächsten Hauptversion des CDK aus diesem Paket entfernt (obwohl sie möglicherweise veraltet sind). Wenn eine grundlegende Änderung an einer stabilen API erforderlich ist, wird eine völlig neue API hinzugefügt.
Neue APIs Dienste, die sich in der Entwicklung aws-cdk-lib befinden, werden anhand eines Beta<N> Suffixes identifiziert, das bei 1 N beginnt und bei jeder wichtigen Änderung an der neuen API inkrementiert wird. Beta<N> APIs werden nie entfernt, sondern nur als veraltet markiert, sodass Ihre bestehende App weiterhin mit neueren Versionen von funktioniert. aws-cdk-lib Wenn die API als stabil eingestuft wird, wird eine neue API ohne das Beta<N> Suffix hinzugefügt.
Wenn mit der Entwicklung einer höheren Ebene (L2 oder L3) für einen AWS Dienst APIs begonnen wird, für den zuvor nur L1 verfügbar war APIs, APIs werden diese zunächst in einem separaten Paket verteilt. Der Name eines solchen Pakets hat das Suffix „Alpha“, und seine Version entspricht der ersten Version, mit der aws-cdk-lib es kompatibel ist, mit einer Unterversion. alpha Wenn das Modul die vorgesehenen Anwendungsfälle unterstützt, APIs werden diese hinzugefügt. aws-cdk-lib
AWS Erläuterungen zur semantischen Versionierung von Construct Library
Die AWS Construct Library folgt zwar im Großen und Ganzen den Prinzipien der semantischen Versionierung, es gibt jedoch einige wichtige Vorbehalte, die sich speziell auf unsere Implementierung beziehen. Im Allgemeinen gewährleistet die AWS Construct-Bibliothek die Stabilität für API-Nutzer, fügt den Konstruktautoren jedoch manchmal zusätzliche Belastungen hinzu, um die notwendige Weiterentwicklung des Frameworks zu ermöglichen.
-
Änderungen, die sich auf die Sicherheit auswirken
Um unseren Sicherheitsanforderungen gerecht zu werden, müssen wir möglicherweise Änderungen APIs auf abwärtsinkompatible Weise vornehmen oder sie vollständig entfernen. Dadurch wird verhindert, dass Betroffene APIs verwendet werden, und es wird eine Aktualisierung der Implementierungen erzwungen.
-
Funktionen werden bewusst beschrieben
Wir sind bestrebt, unerwartete Änderungen so gering wie möglich zu halten, bevorzugen jedoch die Absicht gegenüber der Stabilität der Implementierung. Die AWS Construct-Bibliothek garantiert nicht, dass Konstrukte immer nach exakt derselben CloudFormation Vorlage synthetisiert werden oder exakt dieselben Ressourcen verwenden. Dies gilt insbesondere für Konstrukte auf höherer Ebene, bei denen dasselbe Ziel oft auf unterschiedliche Weise erreicht werden kann.
-
Implementierung von Schnittstellen und abstrakten Klassen
Schnittstellen und abstrakte Klassen in der AWS Construct Library sind für Verbraucher stabil, aber nicht für Implementierer. Das bedeutet, dass Sie sich darauf verlassen können, dass Schnittstellen mindestens die gleiche Funktionalität bieten wie
s3.IBucketzu dem Zeitpunkt (Version der AWS Construct-Bibliothek), als Sie mit der Nutzung der Schnittstelle oder abstrakten Klasse begonnen haben. Interfaces und abstrakten Klassen werden jedoch regelmäßig neue (abstrakte) Mitglieder hinzugefügt. Für jeden, der sie implementiert, bedeutet dies einen zusätzlichen Implementierungsaufwand, den es bei der Aktualisierung zu berücksichtigen gilt, da die Implementierung die neuen Mitglieder noch nicht implementieren würde. Ergänzungen zu Schnittstellen und abstrakten Klassen für Implementierer strikt als bahnbrechende Änderungen zu behandeln, würde die Entwicklungsfähigkeit der Construct-Bibliothek übermäßig einschränken. AWS In den meisten Fällen sollten Implementierer es vorziehen, konkrete Klassen wie zu erweitern.s3.Bucket -
L1-Konstrukte, generierter Code und andere APIs , die als extern gekennzeichnet sind
Teile der AWS Construct-Bibliothek werden aus Datenquellen generiert, die direkt von Diensten stammen AWS . Um diese mit der Realität in APIs Einklang zu bringen, kann der generierte Code rückwärtsinkompatible Änderungen enthalten. In den meisten Fällen werden Datenquellen aktualisiert, um die Realität korrekt wiederzugeben und falsche Darstellungen zu korrigieren. Ihre IDEs IntelliSense werden APIs zusammen mit der
@stability — externalAnmerkung extern angezeigt. -
Spezifische Sprachbindungen
Sprachbindungen können in einer sehr begrenzten Anzahl von Situationen rückwärtsinkompatible Änderungen enthalten. Diese werden durch Upstream-Typänderungen verursacht, die in anderen unterstützten Sprachen abwärtskompatibel sind. Diese Typänderungen sind zulässig, da andernfalls die Evolvierbarkeit der Bibliothek stark eingeschränkt würde.
In der folgenden Liste werden alle bekannten Instanzen beschrieben:
-
Golang - Von einem typisierten Slice zu einem beliebigen Slice wechseln: Eine Liste eines einzelnen Typs wird zu einer Liste mit mehreren Typen (Union-Typen in TypeScript).
GoIn werden diese als Slice von any () eingegeben.*[]anyAufgrund der Eingabezuweisungsregeln von Goist der Wechsel von*[]stringzu keine automatische Konvertierung. Daher erfordert diese Typerweiterung eine Änderung des Verbrauchercodes. Strategien finden Sie unter Arbeiten mit beliebigen Segmenten.
-
Stabilität der Sprachbindung
Im Laufe der Zeit könnten wir das AWS CDK um Unterstützung für weitere Programmiersprachen erweitern. Obwohl die in allen Sprachen beschriebene API dieselbe ist, variiert die Art und Weise, wie die API ausgedrückt wird, je nach Sprache und kann sich ändern, wenn sich die Sprachunterstützung weiterentwickelt. Aus diesem Grund gelten Sprachbindungen eine Zeit lang als experimentell, bis sie für den produktiven Einsatz als bereit erachtet werden.
| Sprache | Stabilität |
|---|---|
|
TypeScript |
Stabil |
|
JavaScript |
Stabil |
|
Python |
Stabil |
|
Java |
Stabil |
|
C#/.NET |
Stabil |
|
Go |
Stabil |
