

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à.

# Consegna continua CNF
<a name="cnf-continuous-delivery"></a>

Questo passaggio consiste in una sequenza di passaggi che vengono eseguiti ripetutamente per implementare le modifiche che fanno parte delle container/configuration modifiche che danno luogo agli aggiornamenti. La consegna continua CNF è automatizzata tramite pipeline ed è specifica per le singole applicazioni. AWS utilizza grafici Helm standard per aggiornare specifici. CNFs La pipeline del codice prevede controlli preliminari e successivi per lo stato di aggiornamento dell'applicazione. La CI/CD pipeline aggiornata è inoltre integrata con un framework di automazione dei test per eseguire test automatizzati. Questa astrazione consente un'implementazione pulita delle funzioni di rete.

La fornitura e l'implementazione continue di CNF possono essere ampiamente classificate nelle seguenti categorie:
+ **Aggiornamenti delle applicazioni**: la maggior parte degli aggiornamenti delle applicazioni sono modifiche all'interno dell'applicazione Kuberbetes. PODs Questi aggiornamenti possono essere applicati automaticamente tramite la pipeline del codice. La maggior parte CNFs supporta gli aggiornamenti in loco fornendo più istanze di applicazione. PODs Le istanze multiple consentono un approccio di aggiornamento continuo. Non tutte le modifiche al POD dell'applicazione supportano l'aggiornamento di Helm. Le pipeline tengono conto di queste variazioni e utilizzano Helm secondo necessità. install/delete 
+ **Aggiornamenti importanti: gli aggiornamenti** principali sono principalmente modifiche allo schema del database. Questa modifica non può essere applicata senza causare tempi di inattività. L'approccio standard a queste modifiche consiste nell'eliminare l'applicazione e ricreare i relativi pod. Durante il processo l'applicazione potrebbe non essere disponibile. Per gli aggiornamenti vengono utilizzati i seguenti strumenti:
+  [**AWS CloudFormation**](https://aws.amazon.com/cloudformation/) consente ai clienti di descrivere e fornire tutte le risorse dell'infrastruttura in modelli JSON o YAML. CloudFormation fornisce un potente meccanismo di estensione tramite risorse personalizzate supportate da Lambda. I clienti possono AWS CloudFormation andare oltre le risorse AWS e fornire la risorsa richiesta in altri ambienti, ad esempio risorse locali in ambienti ibridi. AWS CDK offre agli sviluppatori la possibilità di creare codice utilizzando linguaggi di programmazione familiari di livello superiore come Python, TypeScript JavaScript, Java e C\#, quindi compilare il codice in un formato CloudFormation JSON di livello inferiore, che può quindi essere distribuito. 
+ **BlueGreen implementazione**: AWS supporta e consiglia le implementazioni basate su blue/green Canary in ambienti di test e di produzione. [ Blue/green le implementazioni](https://aws.amazon.com/quickstart/architecture/blue-green-deployment/) consentono ai clienti di testare una nuova versione dell'applicazione in un ambiente contenuto. Forniscono un metodo semplice e intuitivo per passare al traffico di produzione. [ Le implementazioni con sede a Canary](https://wa.aws.amazon.com/wat.concept.canary-deployment.en.html) estendono questo concetto consentendo di testare l'ambiente verde non di produzione con una piccola parte del traffico di produzione per scoprire eventuali problemi causati dal traffico di produzione. La nuova versione dell'applicazione viene testata rispetto al traffico di test simulato interno e a piccole quantità di traffico di produzione, il che dà fiducia all'utente prima di passare al traffico di produzione. Il traffico di produzione viene gradualmente aumentato fino al completamento del passaggio. L'implementazione prevede DNS ponderati e gruppi target ELB ponderati.
+ **L'automazione** può essere ottenuta configurando le fasi di implementazione basate su AWS CodePipeline Canary. blue/green La fase di approvazione può essere gestita manualmente inizialmente durante il provisioning, ma successivamente dovrebbe essere completamente automatizzata. Negli ambienti di test, è buona norma eseguire sempre i test con un'azione di rollback per convalidare la compatibilità con le versioni precedenti e successive, prima di passare alla produzione. L' blue/green implementazione su cluster con service mesh dipende dal supporto fornito dall'applicazione finale e dal gateway di routing affinché la service mesh effettui una transizione senza intoppi.
+  [**AWS Systems Manager**](https://aws.amazon.com/systems-manager/) fornisce un'interfaccia utente unificata che consente di visualizzare i dati operativi da più servizi AWS utilizzati dalle funzioni di rete distribuite da CI/CD. Systems Manager consente di automatizzare le attività operative tra le AWS risorse. 

![Un diagramma che illustra l'implementazione di Canary.](http://docs.aws.amazon.com/it_it/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g10.png)


*Implementazione delle Canarie*