Implementa una strategia di ramificazione GitHub Flow per ambienti con più account DevOps - 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à.

Implementa una strategia di ramificazione GitHub Flow per ambienti con più account DevOps

Creato da Mike Stephens (AWS) e Abhilash Vinod (AWS)

Archivio di git-branching-strategies-for codice: -multiaccount-devops

Ambiente: produzione

Tecnologie: DevOps; DevelopmentAndTesting; Strategia multiaccount

Servizi AWS: AWS CodeArtifact; AWS CodeBuild; AWS CodeCommit; AWS CodeDeploy; AWS CodePipeline

Riepilogo

Quando si gestisce un repository di codice sorgente, diverse strategie di ramificazione influiscono sui processi di sviluppo e rilascio del software utilizzati dai team di sviluppo. Esempi di strategie di ramificazione comuni includono Trunk, GitHub Flow e Gitflow. Queste strategie utilizzano rami diversi e le attività svolte in ciascun ambiente sono diverse. Organizations che stanno implementando DevOps processi trarrebbero vantaggio da una guida visiva per aiutarle a comprendere le differenze tra queste strategie di ramificazione. L'utilizzo di questa immagine nell'organizzazione aiuta i team di sviluppo ad allineare il proprio lavoro e a seguire gli standard organizzativi. Questo modello fornisce questa immagine e descrive il processo di implementazione di una strategia di ramificazione GitHub Flow nell'organizzazione.

Questo modello fa parte di una serie di documentazione sulla scelta e l'implementazione di strategie di DevOps ramificazione per organizzazioni con più membri. Account AWS Questa serie è progettata per aiutarti ad applicare la strategia e le migliori pratiche corrette sin dall'inizio, per semplificare la tua esperienza nel cloud. GitHub Flow è solo una delle possibili strategie di ramificazione che l'organizzazione può utilizzare. Questa serie di documentazione copre anche i modelli di ramificazione Trunk e Gitflow. Se non l'hai già fatto, ti consigliamo di leggere Scelta di una strategia di ramificazione Git per DevOps ambienti multi-account prima di implementare le linee guida di questo modello. Utilizza la due diligence per scegliere la strategia di ramificazione giusta per la tua organizzazione.

Questa guida fornisce un diagramma che mostra come un'organizzazione potrebbe implementare la GitHub strategia Flow. Si consiglia di consultare la AWS DevOps Well-Architected Guidance per esaminare le best practice. Questo modello include attività, passaggi e restrizioni consigliati per ogni fase del DevOps processo.

Prerequisiti e limitazioni

Prerequisiti

  • Git, installato. Viene utilizzato come strumento di archiviazione del codice sorgente.

  • Draw.io, installato. Questa applicazione viene utilizzata per visualizzare e modificare il diagramma.

Architettura

Architettura Target

Il diagramma seguente può essere usato come un quadrato di Punnett (Wikipedia). Allineate i rami sull'asse verticale con gli AWS ambienti sull'asse orizzontale per determinare quali azioni eseguire in ogni scenario. I numeri indicano la sequenza delle azioni nel flusso di lavoro. In questo esempio si passa da una feature filiale all'implementazione in produzione.

Riepilogo delle attività di GitHub Flow in ogni filiale e ambiente.

Per ulteriori informazioni sugli ambienti e sui Account AWS rami di un approccio GitHub Flow, vedi Scelta di una strategia di ramificazione Git per ambienti con più account DevOps .

Automazione e scalabilità

L'integrazione continua e la distribuzione continua (CI/CD) sono il processo di automazione del ciclo di vita delle release del software. Automatizza gran parte o tutti i processi manuali tradizionalmente necessari per trasferire il nuovo codice da un commit iniziale alla produzione. Una pipeline CI/CD comprende gli ambienti sandbox, di sviluppo, di test, di staging e di produzione. In ogni ambiente, la pipeline CI/CD fornisce qualsiasi infrastruttura necessaria per distribuire o testare il codice. Utilizzando CI/CD, i team di sviluppo possono apportare modifiche al codice che vengono poi testate e distribuite automaticamente. Le pipeline CI/CD forniscono inoltre governance e barriere ai team di sviluppo, garantendo coerenza, standard, best practice e livelli minimi di accettazione per l'accettazione e l'implementazione delle funzionalità. Per ulteriori informazioni, vedere Practicing Continuous Integration and Continuous Delivery su. AWS

AWS offre una suite di servizi per sviluppatori progettati per aiutarti a creare pipeline CI/CD. Ad esempio, AWS CodePipelineè un servizio di distribuzione continua completamente gestito che consente di automatizzare le pipeline di rilascio per aggiornamenti rapidi e affidabili di applicazioni e infrastrutture. AWS CodeCommitè progettato per ospitare in modo sicuro repository Git scalabili, AWS CodeBuildcompila codice sorgente, esegue test e produce pacchetti software. ready-to-deploy Per ulteriori informazioni, consulta Developer Tools on. AWS

Strumenti

AWS servizi e strumenti

AWS fornisce una suite di servizi per sviluppatori che è possibile utilizzare per implementare questo modello:

  • AWS CodeArtifactè un servizio di repository di artefatti gestito e altamente scalabile che consente di archiviare e condividere pacchetti software per lo sviluppo di applicazioni.

  • AWS CodeBuildè un servizio di compilazione completamente gestito che consente di compilare codice sorgente, eseguire test unitari e produrre artefatti pronti per la distribuzione.

  • AWS CodeCommitè un servizio di controllo delle versioni che consente di archiviare e gestire in modo privato gli archivi Git, senza dover gestire il proprio sistema di controllo del codice sorgente.

  • AWS CodeDeployautomatizza le distribuzioni su Amazon Elastic Compute Cloud (Amazon EC2) o su istanze, AWS Lambda funzioni o servizi Amazon Elastic Container Service (Amazon ECS) locali.

  • AWS CodePipelineti aiuta a modellare e configurare rapidamente le diverse fasi di un rilascio del software e ad automatizzare i passaggi necessari per rilasciare continuamente le modifiche al software.

Altri strumenti

  • Draw.io Desktop è un'applicazione per creare diagrammi di flusso e diagrammi. Il repository di codice contiene modelli in formato.drawio per Draw.io.

  • Figma è uno strumento di progettazione online progettato per la collaborazione. Il repository di codice contiene modelli in formato.fig per Figma.

Deposito di codice

Questo file sorgente per il diagramma in questo modello è disponibile nel GitHub repository Git Branching Strategy for GitHub Flow. Include file nei formati PNG, draw.io e Figma. È possibile modificare questi diagrammi per supportare i processi dell'organizzazione.

Best practice

Segui le migliori pratiche e i consigli contenuti in AWS DevOps Well-Architected Guidance e Choosing a Git branching strategy per ambienti multi-account. DevOps Questi consentono di implementare efficacemente lo sviluppo GitHub basato su Flow, promuovere la collaborazione, migliorare la qualità del codice e semplificare il processo di sviluppo.

Epiche

AttivitàDescrizioneCompetenze richieste

Esamina la procedura standard di GitHub Flow.

  1. Nell'ambiente sandbox, lo sviluppatore crea un feature ramo dal main ramo e utilizza lo schema di denominazione. feature/<ticket>_<initials>_<short description>

  2. Lo sviluppatore aggiunge uno o più commit al feature ramo, ognuno dei quali rappresenta una modifica o un miglioramento discreto.

  3. Lo sviluppatore apre una richiesta di unione (MR) per unire le modifiche nel ramo. main Questo avvia un processo di revisione.

  4. Durante il processo di revisione, gli sviluppatori discutono delle modifiche al codice e forniscono feedback. L'obiettivo è garantire che le modifiche siano di alta qualità e soddisfino gli standard del progetto.

  5. Dopo che lo sviluppatore ha creato la richiesta di unione, viene avviato un processo di compilazione automatizzato che distribuisce le modifiche nel feature ramo nell'ambiente di sviluppo.

  6. I test automatici verificano l'integrità e la qualità delle modifiche incluse nella richiesta di unione. Per completare la richiesta di unione sono necessari una compilazione, una distribuzione e un test di successo.

  7. Una volta completato il processo di revisione, le modifiche vengono unite alla main filiale.

  8. Un approvatore approva manualmente la distribuzione degli elementi di rilascio nell'ambiente di test.

  9. Un approvatore approva manualmente la distribuzione degli elementi di rilascio nell'ambiente di staging.

  10. Un approvatore approva manualmente la distribuzione degli elementi di rilascio nell'ambiente di produzione.

DevOps ingegnere

Esamina il processo bugfix GitHub Flow.

  1. Lo sviluppatore crea un bugfix ramo dal main ramo e utilizza lo schema di denominazione. bugfix/<ticket number>_<developer initials>_<descriptor>

  2. Lo sviluppatore risolve il problema, esegue la correzione e crea il ramo. bugfix

  3. Lo sviluppatore apre una richiesta di unione per unire il ramo nel bugfix ramo. main Questo avvia un processo di revisione.

  4. Durante il processo di revisione, gli sviluppatori discutono delle modifiche al codice e forniscono feedback.

  5. Dopo il completamento e l'approvazione della revisione, lo sviluppatore completa la richiesta di fusione della bugfix filiale nella main filiale.

  6. Un approvatore approva manualmente l'implementazione degli elementi di rilascio in ambienti superiori.

DevOps ingegnere

Esamina il processo di hotfix GitHub Flow.

GitHub Flow è progettato per consentire la distribuzione continua, in cui le modifiche al codice vengono implementate frequentemente e in modo affidabile in ambienti superiori. La chiave è che ogni feature filiale è implementabile in qualsiasi momento.

Hotfixle filiali, che sono simili alle nostre feature bugfix filiali, possono seguire lo stesso processo di entrambe le altre filiali. Tuttavia, data la loro urgenza, gli hotfix hanno in genere una priorità più elevata. A seconda delle politiche del team e dell'immediatezza della situazione, alcune fasi del processo potrebbero essere accelerate. Ad esempio, le revisioni del codice per gli hotfix potrebbero essere rapide. Pertanto, sebbene il processo di hotfix sia parallelo al processo relativo a funzionalità o bugfix, l'urgenza relativa agli hotfix può giustificare modifiche nell'aderenza procedurale. È fondamentale stabilire linee guida sulla gestione degli hotfix per garantire che vengano gestiti in modo efficiente e sicuro.

DevOps ingegnere

Risoluzione dei problemi

ProblemaSoluzione

conflitti tra filiali

Un problema comune che può verificarsi con il modello GitHub Flow è rappresentato dalla necessità di applicare un hotfix in produzione featurebugfix, mentre una modifica corrispondente deve avvenire in un hotfix ramo in cui vengono modificate le stesse risorse. Si consiglia di unire frequentemente le modifiche provenienti dai main rami inferiori per evitare conflitti significativi durante l'unione a. main

Maturità del team

GitHub Flow incoraggia le implementazioni quotidiane in ambienti superiori, adottando una vera integrazione continua e una distribuzione continua (CI/CD). È fondamentale che il team abbia la maturità ingegneristica necessaria per creare funzionalità e creare test di automazione per esse. Il team deve eseguire una revisione esaustiva della richiesta di unione prima dell'approvazione delle modifiche. Ciò favorisce una solida cultura ingegneristica che promuove la qualità, la responsabilità e l'efficienza nel processo di sviluppo.

Risorse correlate

Questa guida non include la formazione per Git; tuttavia, ci sono molte risorse di alta qualità disponibili su Internet se hai bisogno di questa formazione. Ti consigliamo di iniziare dal sito di documentazione di Git.

Le seguenti risorse possono aiutarti nel tuo percorso di ramificazione di GitHub Flow in. Cloud AWS

AWS DevOps guida

GitHub Guida al flusso

Altre risorse