Esercizio - Creare una richiesta pull

12 minuti

In questa unità ci si eserciterà con il processo di invio di una richiesta pull e di merge delle modifiche nel ramo main, in modo che tutti possano trarre vantaggio dal lavoro.

In Creare una pipeline di compilazione con Azure Pipelines è stato creato un ramo Git denominato build-pipeline, in cui è stata definita una pipeline di compilazione di base per il sito Web Space Game. Ricordare che la definizione di compilazione è disponibile in un file denominato azure-pipelines.yml.

Sebbene il ramo produca un artefatto di compilazione, questo lavoro esiste solo sul ramo build-pipeline. È necessario eseguire il merge del ramo nel ramo main.

Tenere presente che una richiesta pull indica agli altri sviluppatori che il codice è pronto per l'eventuale revisione e che si vuole eseguire il merge delle modifiche in un altro ramo, ad esempio il ramo main.

Prima di iniziare, ecco che cosa dicono Mara e Andy.

Andy: Ciao, Mara. So che hai una pipeline di compilazione in esecuzione in Azure. Sto aggiungendo una funzionalità al sito Web e vorrei visualizzare il processo di compilazione. Siamo pronti?

Mara: Assolutamente. Ho creato la pipeline in un ramo. Perché non creiamo una richiesta pull e ne eseguiamo il merge in main in modo da poter usare anche la pipeline?

Andy: Eccellente. Vediamo.

Creare un ramo e aggiungere un codice di avvio

Anche se si potrebbe usare la pipeline di compilazione compilata nel modulo precedente, creeremo un nuovo ramo denominato code-workflow. Questo ramo si basa su main, in modo da poter fare pratica con il processo dall'inizio.

Aprire il terminale integrato in Visual Studio Code.
Passare al ramo main:
```
git checkout main
```
Assicurarsi di avere la versione più recente del codice da GitHub:
```
git pull origin main
```
Creare un ramo denominato code-workflow:
```
git checkout -B code-workflow
```
L'argomento -b specifica di creare un nuovo ramo se non esiste. Omettere l'argomento -bquando si vuole passare a un ramo esistente.

Per impostazione predefinita, il nuovo ramo si basa sul ramo precedente dal quale è stato eseguito il comando git checkout. In questo caso il ramo padre è main, ma il ramo padre può essere diverso, ad esempio un ramo di funzionalità avviato da un altro utente che si vuole usare come base per compilazioni o sperimentazioni.

È ora possibile apportare tutte le modifiche necessarie in tutta sicurezza, perché ci si trova nel proprio ramo locale. Per capire in quale ramo ci si trova, eseguire git branch -v.

Da Esplora file aprire azure-pipelines.yml e sostituirne il contenuto con quanto segue:

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Questa configurazione è simile a quella di base creata nel modulo precedente. Per brevità, compilare solo la configurazione di versione del progetto.

Eseguire il push del ramo in GitHub

Qui è possibile eseguire il push del ramo code-workflow in GitHub e osservare Azure Pipelines mentre compila l'applicazione.

Nel terminale eseguire git status per verificare il lavoro di cui non è stato eseguito il commit nel ramo:
```
git status
```
Si noterà che azure-piplines.yml è stato modificato. A breve verrà eseguito il commit nel ramo, ma è prima necessario assicurarsi che Git stia monitorando questo file, operazione nota come staging del file.

Quando si esegue git commit, viene eseguito il commit delle sole modifiche preparate per il commit. Eseguire quindi il comando git add per aggiungere azure-pipelines.yml all'area di gestione temporanea o all'indice.
Eseguire il comando git add seguente per aggiungere azure-piplines.yml all'area di gestione temporanea:
```
git add azure-pipelines.yml
```
Eseguire il comando git commit seguente per eseguire il commit del file di staging nel ramo code-workflow:
```
git commit -m "Add the build configuration"
```
L' argomento -m specifica il messaggio di commit. Il messaggio di commit viene incluso nella cronologia di un file modificato. Consente ai revisori di comprendere la modifica, oltre a permettere ai gestori futuri di comprendere il modo in cui il file è cambiato nel tempo.

Suggerimento

I migliori messaggi di commit completano la frase "Se si applica questo commit, allora..."

Se si omette l'argomento -m, Git visualizza un editor di testo in cui è possibile descrivere in dettaglio la modifica. Questa opzione è utile quando si vuole specificare un messaggio di commit che si estende su più righe. Il testo fino alla prima riga vuota specifica il titolo del commit.
Eseguire questo comando git push per eseguire il push o il caricamento del ramo code-workflow nel repository in GitHub:
```
git push origin code-workflow
```
Come passaggio facoltativo, passare al progetto in Azure Pipelines e tracciare la compilazione durante l'esecuzione.

Questa compilazione è nota come Compilazione CI. La configurazione della pipeline usa un elemento noto come trigger per controllare quali rami partecipano al processo di compilazione. In questo caso, "*" specifica tutti i rami.
```
trigger:
- '*'
```
Successivamente, verrà illustrato come controllare la configurazione della pipeline per la compilazione dai soli rami necessari.

Si noterà che la compilazione viene completata correttamente e produce un artefatto che contiene l'app Web compilata.

Crea una richiesta pull

Verrà qui creata una richiesta pull per il ramo:

In un browser accedere a GitHub.
Passare al repository mslearn-tailspin-spacegame-web.
Nell'elenco a discesa Ramo selezionare il ramo code-workflow.
Per avviare la richiesta pull, selezionare Collaborazione e quindi Apri richiesta pull.
Verificare che la base specifichi il repository di cui è stata creata una copia tramite fork e non il repository di Microsoft.

La selezione avrà l'aspetto seguente:

Importante

Questo passaggio è importante perché non è possibile eseguire il merge delle modifiche nel repository Microsoft. Assicurarsi che il repository di base punti all'account GitHub e non a MicrosoftDocs.

Se si apre una richiesta pull per MicrosoftDocs, è sufficiente chiudere la richiesta pull e ripetere questi passaggi.

Questo processo comporta un passaggio aggiuntivo perché si sta lavorando da un repository di cui è stata creata una copia tramite fork. Quando si lavora direttamente con il proprio repository e non un fork, il ramo main è selezionato per impostazione predefinita.
Immettere un titolo e una descrizione per la richiesta pull.
- Titolo:
  
  Configurare Azure Pipelines
- Descrizione:
  
  Questa configurazione della pipeline compila l'applicazione e produce una compilazione per la configurazione della versione.
Per completare la richiesta pull, selezionare Crea richiesta pull.

In questo passaggio non viene eseguito il merge di alcun codice, Indica ad altri utenti che sono state proposte modifiche di cui eseguire il merge nel main ramo.

Verrà visualizzata la finestra Richiesta pull. È possibile osservare che lo stato di compilazione in Azure Pipelines è configurato per essere incluso nella richiesta pull. In questo modo, l'utente e altri utenti possono visualizzare lo stato della compilazione mentre è in esecuzione.

Proprio come quando si esegue il push di un ramo a GitHub, per impostazione predefinita una richiesta pull attiva Microsoft Azure Pipelines per compilare l'applicazione.

Suggerimento

Se lo stato della compilazione non viene visualizzato immediatamente, attendere qualche minuto o aggiornare la pagina.
Facoltativamente, selezionare il collegamento Dettagli, quindi tracciare la compilazione mentre viene spostata nella pipeline.

È possibile passare dalla compilazione al passaggio successivo del processo, ad esempio il controllo di qualità. In un secondo momento, è possibile configurare la pipeline per eseguire il push della modifica fino al lab di controllo di qualità o alla produzione.
Tornare alla richiesta pull su GitHub.

Attendere il completamento del processo di compilazione. A questo punto si è pronti per eseguire il merge della richiesta pull.
Selezionare Esegui il merge della richiesta pull, quindi selezionare Conferma merge.
Per eliminare il ramo code-workflow da GitHub, selezionare Elimina ramo.

È possibile eliminare un ramo da GitHub in completa sicurezza dopo aver eseguito il merge della richiesta pull. Si tratta in effetti di una pratica comune, perché il ramo non è più necessario. Viene eseguito il merge delle modifiche, ma è comunque possibile trovare i relativi dettagli in GitHub o dalla riga di comando. L'eliminazione di un ramo sottoposto a merge consente anche ad altri utenti di visualizzare solo il lavoro attualmente attivo.

I rami Git sono progettati per essere di breve durata. Dopo aver eseguito il merge di un ramo non è possibile eseguire il push di commit aggiuntivi su di esso o unirlo una seconda volta. Nella maggior parte dei casi, ogni volta che si avvia una nuova funzionalità o l'aggiornamento di un bug, si inizia con un ramo pulito basato sul ramo main.

L'eliminazione di un ramo in GitHub non comporta l'eliminazione del ramo dal sistema locale. A tale scopo, passare l'opzione -d al comando git branch.

Quante volte viene compilata una modifica?

La risposta dipende dalla modalità di definizione della configurazione della compilazione. Azure Pipelines consente di definire trigger che specificano quali eventi comportano la generazione di compilazioni. È possibile controllare quali rami vengono compilati o anche quali file attivano la compilazione.

Si immagini ad esempio di voler eseguire una compilazione quando viene effettuato il push di una modifica in GitHub in qualsiasi ramo Git e di non volere che la compilazione avvenga quando le uniche modifiche sono apportate ai file nella cartella docs del progetto. Può essere utile includere questa sezione trigger nella configurazione della build:

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

Per impostazione predefinita, viene attivata una compilazione quando viene effettuato il push di una modifica in qualsiasi file in qualsiasi ramo.

Una compilazione di integrazione continua (Continuous Integration, CI) è una compilazione eseguita quando si effettua il push di una modifica in un ramo.

Una compilazione di richiesta pull è una compilazione che viene eseguita quando si apre una richiesta pull o quando si effettua il push di altre modifiche a una richiesta pull esistente.

Le modifiche apportate tramite il ramo code-workflow sono compilate in tre condizioni:

Una compilazione CI si verifica quando si esegue il push delle modifiche nel ramo code-workflow.
Una compilazione di richiesta pull si verifica quando si apre una richiesta pull nel ramo code-workflow rispetto al ramo main.
Una compilazione CI finale viene eseguita dopo il merge della richiesta pull nel ramo main.

Le compilazioni di richiesta pull consentono di verificare che le modifiche proposte funzionino correttamente dopo il merge con main o con un altro ramo di destinazione.

La compilazione CI finale verifica che le modifiche siano ancora valide dopo il merge della richiesta pull.

Come passaggio facoltativo, passare ad Azure Pipelines e osservare l'ultima compilazione CI eseguita nel ramo main.

Continua

Esercizio - Creare una richiesta pull

Creare un ramo e aggiungere un codice di avvio

Eseguire il push del ramo in GitHub

Crea una richiesta pull

Quante volte viene compilata una modifica?

Commenti e suggerimenti