Questa è la AWS CDK v2 Developer Guide. Il vecchio CDK v1 è entrato in manutenzione il 1° giugno 2022 e ha terminato il supporto il 1° giugno 2023.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
AWS Controllo delle versioni CDK
Questo argomento fornisce informazioni di riferimento su come il AWS Cloud Development Kit (AWS CDK) gestisce il controllo delle versioni.
I numeri di versione sono costituiti da tre parti numeriche: principale. minore. correggi e segui ampiamente i principi del controllo delle versioni semantiche
Le versioni secondarie e le patch sono retrocompatibili. Il codice scritto in una versione precedente con la stessa versione principale può essere aggiornato a una versione più recente all'interno della stessa versione principale. Continuerà a essere compilato ed eseguito, producendo un risultato funzionalmente equivalente. Per alcuni casi d'uso avanzati, saranno necessarie piccole modifiche al codice, come indicato nell'argomento successivo.
AWS Compatibilità con CDK Toolkit
Ogni versione della AWS Construct Library principale (aws-cdk-lib) è compatibile con la versione AWS CDK Toolkit CLI aws-cdk-cli () e Toolkit Library @aws-cdk/toolkit-lib () corrente al momento del rilascio della AWS Construct Library. È anche compatibile con qualsiasi versione più recente di CDK Toolkit. AWS Ogni versione della AWS Construct Library mantiene questa compatibilità fino alla data di fine del ciclo di vita della libreria. Pertanto, purché si utilizzi una versione supportata di AWS Construct Library, è sempre sicuro aggiornare la versione di AWS CDK Toolkit.
Ogni versione di AWS Construct Library potrebbe funzionare anche con versioni di AWS CDK Toolkit precedenti alla versione corrente al momento del rilascio della Construct Library. AWS Tuttavia, ciò non è garantito. La compatibilità dipende dalla versione dello schema di assemblaggio cloud di AWS Construct Library. Il AWS CDK genera un assemblaggio cloud durante la sintesi e il AWS CDK Toolkit lo utilizza per la distribuzione. Lo schema che definisce il formato dell'assembly cloud è rigorosamente specificato e versionato. Pertanto, una versione precedente di AWS CDK Toolkit dovrebbe supportare la versione dello schema di assemblaggio cloud di AWS Construct Library per essere compatibile.
Quando la versione di cloud assembly richiesta dalla AWS Construct Library non è compatibile con la versione supportata da AWS CDK Toolkit, viene visualizzato un messaggio di errore simile al seguente:
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.
Per risolvere questo errore, aggiorna AWS CDK Toolkit a una versione compatibile con la versione di cloud assembly richiesta o all'ultima versione disponibile. L'alternativa (il downgrade dei moduli di AWS Construct Library utilizzati dall'app) è generalmente sconsigliata.
Nota
Per ulteriori informazioni sulle combinazioni esatte di versioni che funzionano insieme, consultate la tabella di compatibilità nel repository
AWS Controllo delle versioni di Construct Library
I moduli della AWS Construct Library attraversano varie fasi man mano che vengono sviluppati dall'idea all'API matura. Le diverse fasi offrono diversi gradi di stabilità dell'API nelle versioni successive del AWS CDK.
Ad eccezione degli scenari in cui valgono le avvertenze documentate nel prossimo argomento, APIs nella AWS Construct Library principale (aws-cdk-lib) sono stabili e la libreria segue sostanzialmente i principi del controllo semantico delle versioni. La libreria include costrutti AWS CloudFormation (L1) per tutti i AWS servizi, che vengono generati automaticamente dagli schemi dei provider di CloudFormation risorse e talvolta possono includere aggiornamenti incompatibili con le versioni precedenti. Include anche costrutti di livello superiore (L2 e L3) e le classi CDK principali come e, che sono tutte stabili. App Stack APIs non verranno rimossi da questo pacchetto (anche se potrebbero essere obsoleti) fino alla prossima versione principale del CDK. Quando è necessaria una modifica sostanziale a un'API stabile, verrà aggiunta un'API completamente nuova.
Le novità in APIs fase di sviluppo per un servizio già incorporato aws-cdk-lib vengono identificate utilizzando un Beta<N> suffisso, che N parte da 1 e viene incrementato a ogni modifica sostanziale apportata alla nuova API. Beta<N> APIs non vengono mai rimossi, ma solo obsoleti, quindi l'app esistente continua a funzionare con le versioni più recenti di. aws-cdk-lib Quando l'API è considerata stabile, viene aggiunta una nuova API senza il Beta<N> suffisso.
Quando si APIs inizia a sviluppare un livello superiore (L2 o L3) per un AWS servizio che in precedenza aveva solo L1 APIs, questi APIs vengono inizialmente distribuiti in un pacchetto separato. Il nome di tale pacchetto ha il suffisso «Alpha» e la sua versione corrisponde alla prima versione compatibile con aws-cdk-lib una versione secondaria. alpha Quando il modulo supporta i casi d'uso previsti, viene aggiunto a. APIs aws-cdk-lib
AWS Chiarimenti sul controllo delle versioni semantiche di Construct Library
Sebbene la AWS Construct Library segua ampiamente i principi del controllo semantico delle versioni, ci sono alcuni importanti avvertimenti specifici per la nostra implementazione. In generale, la AWS Construct Library mantiene la stabilità per gli utenti delle API, ma a volte aggiunge ulteriori oneri agli autori delle costruzioni per consentire la necessaria evoluzione del framework.
-
Modifiche che influiscono sulla sicurezza
Per soddisfare i nostri standard di sicurezza, potrebbe essere necessario modificarle APIs in modi non compatibili con le versioni precedenti o rimuoverle completamente. Ciò impedisce l'utilizzo APIs degli effetti e impone l'aggiornamento delle implementazioni.
-
Le funzionalità sono descritte per intento
Il nostro obiettivo è ridurre al minimo le modifiche impreviste, ma preferiremo l'intento rispetto alla stabilità dell'implementazione. La AWS Construct Library non garantisce che i costrutti si sintetizzino sempre nello stesso identico CloudFormation modello o utilizzino lo stesso identico set di risorse. Ciò vale soprattutto per i costrutti di livello superiore, in cui lo stesso obiettivo può spesso essere raggiunto in modi diversi.
-
Implementazione di interfacce e classi astratte
Le interfacce e le classi astratte nella libreria AWS Construct sono stabili per i consumatori, ma non per gli implementatori. Ciò significa che potete fare affidamento in modo sicuro su interfacce che forniscono almeno
s3.IBucketle stesse funzionalità del momento (versione di AWS Construct Library) in cui avete iniziato a utilizzare l'interfaccia o la classe astratta. Tuttavia, periodicamente, verranno aggiunti nuovi membri (astratti) alle interfacce e alle classi astratte. Per chiunque li implementi, ciò comporta un ulteriore onere di implementazione da considerare durante l'aggiornamento, poiché l'implementazione non comporterebbe ancora l'implementazione dei nuovi membri. Trattare rigorosamente le aggiunte alle interfacce e alle classi astratte per gli implementatori come modifiche sostanziali limiterebbe indebitamente l'evolvibilità della Construct Library. AWS Nella maggior parte dei casi, gli implementatori dovrebbero preferire estendere classi concrete come.s3.Bucket -
Costrutti L1, codice generato e altro APIs contrassegnato come esterno
Parti della AWS Construct Library vengono generate da fonti di dati provenienti direttamente dai servizi. AWS Per mantenerle APIs allineate alla realtà, il codice generato potrebbe contenere modifiche incompatibili con le versioni precedenti. La maggior parte delle volte, le fonti di dati vengono aggiornate per riflettere correttamente la realtà e correggere la rappresentazione errata. I tuoi IDE IntelliSense verranno visualizzati all'esterno APIs con l'
@stability — externalannotazione. -
Associazioni linguistiche specifiche
Le associazioni linguistiche possono contenere modifiche incompatibili con le versioni precedenti in un numero molto limitato di situazioni. Queste sono causate da modifiche tipografiche originarie che sono retrocompatibili in altre lingue supportate. Le modifiche a questi tipi sono consentite, poiché altrimenti limiterebbe fortemente l'evolvibilità della libreria.
L'elenco seguente descrive tutte le istanze note:
-
Golang - Passaggio da una slice digitata a una qualsiasi slice: un elenco di un singolo tipo sta cambiando in un elenco di più tipi (inclusi i tipi di unione). TypeScript In
Go, questi vengono digitati come una fetta di any ().*[]anyA causa delle regole di assegnazione della digitazione di Go, il passaggio da*[]stringa nonè una conversione automatica. Pertanto, questo ampliamento del tipo richiede la modifica del codice del consumatore. Vedi Working with any slice per le strategie.
-
Stabilità del legame linguistico
Nel corso del tempo, potremmo aggiungere il supporto al AWS CDK per linguaggi di programmazione aggiuntivi. Sebbene l'API descritta in tutte le lingue sia la stessa, il modo in cui viene espressa varia a seconda della lingua e potrebbe cambiare con l'evoluzione del supporto linguistico. Per questo motivo, le associazioni linguistiche sono considerate sperimentali per un certo periodo, fino a quando non vengono considerate pronte per l'uso in produzione.
| Lingua | Stabilità |
|---|---|
|
TypeScript |
Stabile |
|
JavaScript |
Stabile |
|
Python |
Stabile |
|
Java |
Stabile |
|
C#/.NET |
Stabile |
|
Go |
Stabile |
