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
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments"></a>

*Mike Stephens e Abhilash Vinod, Amazon Web Services*

## Riepilogo
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-summary"></a>

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](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html) e [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html). Se non l'hai già fatto, ti consigliamo di leggere [Scelta di una strategia di ramificazione Git per DevOps ambienti multi-account](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) 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](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) Guidance per esaminare le best practice. Questo modello include attività, passaggi e restrizioni consigliati per ogni fase del DevOps processo.

## Prerequisiti e limitazioni
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-prereqs"></a>

**Prerequisiti**
+ Git, [installato](https://git-scm.com/downloads). Viene utilizzato come strumento di archiviazione del codice sorgente.
+ [Draw.io, installato.](https://github.com/jgraph/drawio-desktop/releases) Questa applicazione viene utilizzata per visualizzare e modificare il diagramma.

## Architecture
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-architecture"></a>

**Architettura Target**

Il diagramma seguente può essere usato come un [quadrato di Punnett](https://en.wikipedia.org/wiki/Punnett_square) (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.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/images/pattern-img/780a5bce-3cd2-4092-8537-b7a77c3d6b8d/images/8a2a774a-cd85-466e-838e-a9a1f3b58a63.png)


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 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach).

**Automazione e scalabilità**

L'integrazione continua e la distribuzione continua (CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CDpipeline) forniscono inoltre governance e barriere ai team di sviluppo, applicando coerenza, standard, best practice e livelli minimi di accettazione per l'accettazione e l'implementazione delle funzionalità. Per ulteriori informazioni, consulta [Practicing Continuous Integration and Continuous Delivery](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html) su. AWS

AWS offre una suite di servizi per sviluppatori progettati per aiutarti a creare CI/CD pipeline. Ad esempio, [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)è 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 CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)compila il codice sorgente, esegue test e produce ready-to-deploy pacchetti software. Per ulteriori informazioni, consulta [Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/).

## Tools (Strumenti)
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-tools"></a>

**AWS servizi e strumenti**

AWS fornisce una suite di servizi per sviluppatori che è possibile utilizzare per implementare questo modello:
+ [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html)è 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](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)è un servizio di compilazione completamente gestito che consente di compilare codice sorgente, eseguire test unitari e produrre artefatti pronti per la distribuzione.
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)automatizza le distribuzioni su Amazon Elastic Compute Cloud (Amazon EC2) o istanze AWS Lambda , funzioni o servizi Amazon Elastic Container Service (Amazon ECS) in locale.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)ti 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](https://github.com/jgraph/drawio-desktop/releases) è un'applicazione per creare diagrammi di flusso e diagrammi. Il repository di codice contiene modelli in formato.drawio per Draw.io.
+ [Figma](https://www.figma.com/design-overview/) è 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](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow). Include file nei formati PNG, draw.io e Figma. È possibile modificare questi diagrammi per supportare i processi dell'organizzazione.

## Best practice
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-best-practices"></a>

Segui le best practice e i consigli contenuti in [AWS DevOps Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) Guidance e Choosing [a Git branching](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) 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
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-epics"></a>

### Revisione dei GitHub flussi di lavoro Flow
<a name="reviewing-the-github-flow-workflows"></a>


| Operazione | Description | Competenze richieste | 
| --- | --- | --- | 
| Esamina la procedura standard di GitHub Flow. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps ingegnere | 
| Esamina il processo bugfix GitHub Flow. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | 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.`Hotfix`le 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
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-troubleshooting"></a>


| Problema | Soluzione | 
| --- | --- | 
| conflitti tra filiali | Un problema comune che può verificarsi con il modello GitHub Flow è rappresentato dalla necessità di applicare un hotfix in produzione `feature``bugfix`, 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
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-resources"></a>

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](https://git-scm.com/doc).

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

**AWS DevOps guida**
+ [AWS DevOps Linee guida](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS Architettura di riferimento della pipeline di distribuzione](https://pipelines.devops.aws.dev/)
+ [Che cos'è DevOps?](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps resources](https://aws.amazon.com/devops/resources/)

**GitHub Guida al flusso**
+ [GitHub Tutorial di avvio rapido di Flow](https://docs.github.com/en/get-started/using-github/github-flow) () GitHub
+ [Perché GitHub Flow?](https://githubflow.github.io/)

**Altre risorse**
+ [Metodologia delle app a dodici fattori (](https://12factor.net/)12factor.net)