Rileva automaticamente le modifiche e avvia diverse CodePipeline pipeline per un monorepo in CodeCommit - Prontuario AWS
RiepilogoPrerequisiti e limitazioniArchitetturaStrumentiBest practiceEpicheRisoluzione dei problemiRisorse correlate

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

Rileva automaticamente le modifiche e avvia diverse CodePipeline pipeline per un monorepo in CodeCommit

Creato da Helton Ribeiro (AWS), Petrus Batalha () e Ricardo Morais () AWS AWS

Archivio di AWS CodeCommit codice: trigger monorepo multi-pipeline

Ambiente: PoC o pilota

Tecnologie: infrastruttura DevOps; Serverless

AWSservizi: AWS CodeCommit AWS CodePipeline; AWS Lambda

Riepilogo

Questo modello consente di rilevare automaticamente le modifiche al codice sorgente di un'applicazione basata su monorepo AWS CodeCommit e quindi di avviare una pipeline AWS CodePipeline che esegue l'automazione dell'integrazione continua e della distribuzione continua (CI/CD) per ogni microservizio. Questo approccio significa che ogni microservizio dell'applicazione basata su monorepo può avere una pipeline CI/CD dedicata, che garantisce una migliore visibilità, una condivisione più semplice del codice e una migliore collaborazione, standardizzazione e reperibilità.

La soluzione descritta in questo modello non esegue alcuna analisi delle dipendenze tra i microservizi all'interno del monorepo. Rileva solo le modifiche nel codice sorgente e avvia la pipeline CI/CD corrispondente.

Il pattern viene utilizzato AWS Cloud9 come ambiente di sviluppo integrato (IDE) e AWS Cloud Development Kit (AWS CDK) per definire un'infrastruttura utilizzando due stack: e. AWS CloudFormation MonoRepoStack PipelinesStack Lo MonoRepoStack stack crea il monorepo in AWS CodeCommit e la AWS Lambda funzione che avvia le pipeline CI/CD. Lo stack definisce l'infrastruttura della pipeline. PipelinesStack

Importante: il flusso di lavoro di questo pattern è un proof of concept (PoC). Si consiglia di utilizzarlo solo in un ambiente di test. Se desideri utilizzare l'approccio di questo modello in un ambiente di produzione, consulta le migliori pratiche di sicurezza IAM nella documentazione AWS Identity and Access Management (IAM) e apporta le modifiche necessarie ai tuoi IAM ruoli e Servizi AWS. 

Prerequisiti e limitazioni

Prerequisiti

Architettura

Il diagramma seguente mostra come utilizzare per definire un'infrastruttura con due AWS CDK stack: e. AWS CloudFormation MonoRepoStack PipelinesStack

Flusso di lavoro da utilizzare AWS CDK per definire un'infrastruttura con due CloudFormation stack.

Il diagramma mostra il flusso di lavoro seguente:

  1. Il processo di bootstrap utilizza AWS CDK per creare gli AWS CloudFormation MonoRepoStack stack e. PipelinesStack

  2. Lo MonoRepoStack stack crea il CodeCommit repository per l'applicazione e la funzione monorepo-event-handler Lambda che viene avviata dopo ogni commit.

  3. Lo PipelinesStack stack crea le pipeline CodePipeline avviate dalla funzione Lambda. Ogni microservizio deve avere una pipeline di infrastruttura definita.

  4. La pipeline for microservice-n viene avviata dalla funzione Lambda e avvia le sue fasi CI/CD isolate basate sul codice sorgente in. CodeCommit

  5. La pipeline for microservice-1 viene avviata dalla funzione Lambda e avvia le sue fasi CI/CD isolate basate sul codice sorgente in. CodeCommit

Il diagramma seguente mostra la distribuzione degli stack e in un account. AWS CloudFormation MonoRepoStack PipelinesStack

Distribuzione degli CloudFormation stack MonoRepoStack e PipelinesStack in un account. AWS

  1. Un utente modifica il codice in uno dei microservizi dell'applicazione.

  2. L'utente invia le modifiche da un repository locale a un repository. CodeCommit

  3. L'attività push avvia la funzione Lambda che riceve tutti i push al repository. CodeCommit

  4. La funzione Lambda legge un parametro in Parameter Store, una funzionalità di AWS Systems Manager, per recuperare l'ID di commit più recente. Il parametro ha il formato di denominazione:. /MonoRepoTrigger/{repository}/{branch_name}/LastCommit Se il parametro non viene trovato, la funzione Lambda legge l'ultimo ID di commit dal CodeCommit repository e salva il valore restituito in Parameter Store.

  5. Dopo aver identificato l'ID di commit e i file modificati, la funzione Lambda identifica le pipeline per ogni directory di microservizi e avvia la pipeline richiesta. CodePipeline

Strumenti

  • AWS Cloud Development Kit (AWS CDK)è un framework di sviluppo software per definire l'infrastruttura cloud in codice e fornirla tramite. AWS CloudFormation

  • Python è un linguaggio di programmazione che consente di lavorare rapidamente e integrare i sistemi in modo più efficace.

Codice

Il codice sorgente e i modelli per questo pattern sono disponibili nel repository GitHub AWS CodeCommit monorepo multi-pipeline triggers.

Best practice

Epiche

AttivitàDescrizioneCompetenze richieste

Crea un ambiente Python virtuale.

Nel tuo AWS Cloud9 IDE, crea un ambiente Python virtuale e installa le dipendenze richieste eseguendo il seguente comando:

make install

Developer

Avvia il comando Account AWS e per. Regione AWS AWS CDK

Esegui il bootstrap di required Account AWS e Region eseguendo il seguente comando:

make bootstrap account-id=<your-AWS-account-ID> region=<required-region>

Developer
AttivitàDescrizioneCompetenze richieste

Aggiungi il codice di esempio alla directory dell'applicazione.

Aggiungi la directory che contiene il codice dell'applicazione di esempio alla monorepo-sample directory del repository GitHub AWS CodeCommit monorepo multi-pipeline triggers clonato.

Developer

Modificare il file monorepo-main.json.

Aggiungi il nome della directory del codice dell'applicazione e il nome della pipeline al file nel repository clonato. monorepo-main.json

Developer

Crea la pipeline.

Nella Pipelines directory del repository, aggiungi la pipeline class per la tua applicazione. La directory contiene due file di esempio e. pipeline_hotsite.py pipeline_demo.py Ogni file ha tre fasi: origine, compilazione e distribuzione.

È possibile copiare uno dei file e modificarlo in base ai requisiti dell'applicazione. 

Developer

Modificare il file monorepo_config.py.

Inservice_map, aggiungi il nome della directory per la tua applicazione e la classe che hai creato per la pipeline.

Ad esempio, il codice seguente mostra una definizione di pipeline nella Pipelines directory che utilizza un file denominato pipeline_mysample.py con una MySamplePipeline classe:

...
# Pipeline definition imports
from pipelines.pipeline_demo import DemoPipeline
from pipelines.pipeline_hotsite import HotsitePipeline
from pipelines.pipeline_mysample import MySamplePipeline

### Add your pipeline configuration here
service_map: Dict[str, ServicePipeline]  = {
    # folder-name -> pipeline-class
    'demo': DemoPipeline(),
    'hotsite': HotsitePipeline(),
    'mysample': MySamplePipeline()
}
Developer
AttivitàDescrizioneCompetenze richieste

Distribuisci lo AWS CloudFormation stack.

Distribuisci lo AWS CloudFormation MonoRepoStack stack con i valori dei parametri predefiniti nella directory principale del repository clonato eseguendo il comando. make deploy-core

È possibile modificare il nome del repository eseguendo il comando. make deploy-core monorepo-name=<repo_name>

Nota: è possibile distribuire contemporaneamente entrambe le pipeline utilizzando il comando. make deploy monorepo-name=<repo_name>

Developer

Convalida il repository. CodeCommit

Verifica che le tue risorse siano state create eseguendo il comando. aws codecommit get-repository --repository-name <repo_name>

Importante: poiché lo AWS CloudFormation stack crea il CodeCommit repository in cui è archiviato il monorepo, non eseguire il cdk destroy MonoRepoStack  comando se hai iniziato a inserire modifiche al suo interno.

Developer

Convalida i risultati dello stack. AWS CloudFormation

Verifica che lo AWS CloudFormation MonoRepoStack stack sia stato creato e configurato correttamente eseguendo il comando seguente:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
Developer
AttivitàDescrizioneCompetenze richieste

Distribuisci lo AWS CloudFormation stack.

Lo AWS CloudFormation PipelinesStack stack deve essere distribuito dopo aver distribuito lo stack. MonoRepoStack Lo stack aumenta di dimensioni quando vengono aggiunti nuovi microservizi alla base di codice di monorepo e viene ridistribuito quando viene integrato un nuovo microservizio.

Distribuisci lo stack PipelinesStack eseguendo il comando. make deploy-pipelines

Nota: puoi anche distribuire contemporaneamente entrambe le pipeline eseguendo il comando. make deploy monorepo-name=<repo_name>

Il seguente output di esempio mostra come la PipelinesStacks distribuzione stampa i dati URLs per i microservizi alla fine dell'implementazione:

Outputs:
PipelinesStack.demourl = .cloudfront.net
PipelinesStack.hotsiteurl = .cloudfront.net
Developer

Convalida i risultati dello AWS CloudFormation stack.

Verifica che lo AWS CloudFormation PipelinesStacks stack sia stato creato e configurato correttamente eseguendo il comando seguente:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
Developer
AttivitàDescrizioneCompetenze richieste

Elimina i tuoi AWS CloudFormation stack.

Esegui il comando make destroy.

Developer

Elimina i bucket S3 per le tue pipeline.

  1. Accedi AWS Management Consolee apri la console Amazon Simple Storage Service (Amazon S3).

  2. Elimina i bucket S3 associati alle tue pipeline e usa il seguente nome: pipelinesstack-codepipeline*

Developer

Risoluzione dei problemi

ProblemaSoluzione

Ho riscontrato dei problemi. AWS CDK

Vedi Risoluzione dei AWS CDK problemi più comuni nella AWS CDK documentazione.

Ho inviato il mio codice di microservizio, ma la pipeline dei microservizi non è stata eseguita.

Convalida della configurazione

Verifica la configurazione della filiale:

  • Assicurati di inviare il codice al ramo corretto. Questa pipeline è configurata per funzionare solo quando vengono apportate modifiche al main ramo. I push verso altri rami non avviano la pipeline a meno che non siano configurati in modo specifico.

  • Dopo aver inviato il codice, controlla se il commit è visibile in AWS CodeCommit per assicurarti che il push abbia avuto successo e che la connessione tra l'ambiente locale e il repository sia intatta. Aggiorna le credenziali se ci sono problemi con il push del codice.

Convalida i file di configurazione:

  • Verifica che la service_map variabile in rifletta monorepo_config.py accuratamente la struttura di directory corrente dei tuoi microservizi. Questa variabile svolge un ruolo cruciale nella mappatura del codice push sulla rispettiva pipeline.

  • Assicurati che monorepo-main.json sia aggiornato per includere la nuova mappatura per il tuo microservizio. Questo file è essenziale affinché la pipeline riconosca e gestisca correttamente le modifiche al microservizio.

Risoluzione dei problemi sulla console

AWS CodePipeline controlli:

  • In AWS Management Console, conferma di trovarti nel luogo in Regione AWS cui è ospitata la tua pipeline. Apri la CodePipeline console e controlla se la pipeline corrispondente al tuo microservizio è stata avviata.

    Analisi degli errori: se la pipeline è stata avviata ma non è riuscita, esamina eventuali messaggi di errore o log forniti da CodePipeline per capire cosa è andato storto.

AWS Lambda risoluzione dei problemi:

  • Sulla AWS Lambda console, apri la funzione monorepo-event-handler Lambda. Verifica che la funzione sia stata avviata in risposta al codice push.

    Analisi dei log: esamina i log della funzione Lambda per eventuali problemi. I log possono fornire informazioni dettagliate su ciò che è accaduto durante l'esecuzione della funzione e aiutare a identificare se la funzione ha elaborato l'evento come previsto.

Devo ridistribuire tutti i miei microservizi.

Esistono due approcci per forzare la ridistribuzione di tutti i microservizi. Scegliete l'opzione più adatta alle vostre esigenze.

Approccio 1: Eliminare un parametro in Parameter Store

Questo metodo prevede l'eliminazione di un parametro specifico in Systems Manager Parameter Store che tiene traccia dell'ultimo ID di commit utilizzato per la distribuzione. Quando si rimuove questo parametro, il sistema è costretto a ridistribuire tutti i microservizi al successivo trigger, perché lo percepisce come uno stato nuovo.

Fasi:

  1. Individuate la voce specifica del Parameter Store che contiene l'ID di commit o un indicatore di distribuzione correlato per il vostro monorepo. Il nome del parametro segue il formato: "/MonoRepoTrigger/{repository}/{branch_name}/LastCommit"

  2. Valuta la possibilità di eseguire il backup del valore del parametro se è fondamentale o se desideri mantenere un record dello stato di distribuzione prima di reimpostarlo.

  3. Utilizzate il AWS Management Console AWS CLI, o SDKs per eliminare il parametro identificato. Questa azione reimposta il marker di distribuzione.

  4. Dopo l'eliminazione, il successivo invio al repository dovrebbe far sì che il sistema distribuisca tutti i microservizi, in quanto cerca il commit più recente da prendere in considerazione per la distribuzione.

Vantaggi:

  • Semplice e veloce da implementare con passaggi minimi.

  • Non richiede modifiche arbitrarie al codice per avviare le distribuzioni.

Contro:

  • Controllo meno granulare sul processo di implementazione.

  • Potenzialmente rischioso se il Parameter Store viene utilizzato per gestire altre configurazioni critiche.

Approccio 2: invia un commit in ogni sottocartella monorepo

Questo metodo prevede di apportare una modifica minore e di inserirla in ciascuna sottocartella di microservizi all'interno del monorepo per avviare le relative pipeline individuali.

Fasi:

  1. Elenca tutti i microservizi all'interno del monorepo che devono essere ridistribuiti.

  2. Per ogni microservizio, apporta una modifica minima e senza impatto nella relativa sottocartella. Potrebbe trattarsi dell'aggiornamento di un README file, dell'aggiunta di un commento in un file di configurazione o di qualsiasi modifica che non influisca sulla funzionalità del servizio.

  3. Applica queste modifiche con un messaggio chiaro (ad esempio «Avvia la ridistribuzione dei microservizi») e inseriscile nell'archivio. Assicurati di inviare le modifiche al ramo che avvia la distribuzione.

  4. Monitora le pipeline per ogni microservizio per confermare che siano iniziate e completate correttamente.

Vantaggi:

  • Fornisce un controllo granulare sui microservizi che vengono ridistribuiti.

  • Più sicuro perché non comporta l'eliminazione di parametri di configurazione che potrebbero essere utilizzati per altri scopi.

Contro:

  • Richiede più tempo, soprattutto con un gran numero di microservizi.

  • Richiede di apportare modifiche al codice non necessarie che potrebbero ingombrare la cronologia dei commit.

Risorse correlate