Cvičení – vytvoření žádosti o přijetí změn

Dokončeno

V této lekci si procvičíte proces odeslání žádosti o přijetí změn a sloučení změn do main větve, aby všichni mohli těžit z vaší práce.

V části Vytvoření kanálu buildu pomocí Azure Pipelines jste vytvořili větev Git s názvem build-pipeline, ve které jste definovali základní kanál buildu pro web Space Game . Vzpomeňte si, že definice sestavení je v souboru s názvem azure-pipelines.yml.

I když vaše větev vytvoří artefakt sestavení, tato práce existuje pouze ve build-pipeline větvi. Větev musíte sloučit do main větve.

Vzpomeňte si, že žádost o přijetí změn informuje ostatní vývojáře, že máte kód připravený ke kontrole, a v případě potřeby chcete, aby se vaše změny sloučily do jiné větve, například do main větve.

Než začneme, pojďme se podívat za Marou a Andym.

Andy: Ahoj, Mara. Vím, že máš kanál buildu, který běží v Azure. Přidávám funkci na web a osobně chci vidět proces sestavení. Jsme na to připravení?

Mara: Naprosto. Vytvořila jsem kanál ve větvi. Proč nevytvoříme žádost o přijetí změn a sloučíme main ji, abyste mohli kanál použít i?

Andy: Zní skvěle. Pojďme se na to podívat.

Vytvoření větve a přidání počátečního kódu

I když byste mohli použít kanál buildu, který jste vytvořili v předchozím modulu, vytvoříme novou větev s názvem code-workflow. Tato větev je založená na main, takže si můžete proces procvičit od začátku.

1. V editoru Visual Studio Code otevřete integrovaný terminál.

2. Přepněte do main větve:

   git checkout main
   

3. Ujistěte se, že máte nejnovější verzi kódu z GitHubu:

   git pull origin main
   

4. Vytvořte větev s názvem code-workflow:

   git checkout -B code-workflow
   

   Argument -b určuje, že se má vytvořit nová větev, pokud neexistuje. Vynecháním argumentu -b byste mohli přepnout na existující větev.

   Ve výchozím nastavení nová větev vychází z předchozí větve, ze které jste spustili příkaz git checkout. V tomto případě je mainnadřazená větev , ale nadřazená větev může být jiná, například větev funkce, se kterou někdo jiný začal pracovat, nebo s ním experimentovat.

   Teď je bezpečné udělat jakékoli změny, které potřebujete, protože jste ve své vlastní místní větvi. Pokud chcete zjistit, kterou větev používáte, spusťte git branch -vpříkaz .

5. V Průzkumníku souborů otevřete azure-pipelines.yml a nahraďte jeho obsah tímto:

   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()
   

   Tato konfigurace se podobá základní konfiguraci, kterou jste vytvořili v předchozím modulu. Kvůli stručnosti sestaví pouze konfiguraci vydané verze vašeho projektu.

Nasdílení větve do GitHubu

Tady nasdílíte svoji code-workflow větev do GitHubu a budete sledovat, jak Azure Pipelines sestaví aplikaci.

1. V terminálu spusťte příkaz git status , abyste zjistili, co ve vaší větvi existuje nepotvrzená práce:

   git status
   

   Uvidíte, že azure-pipelines.yml byl změněn. Tuto větev potvrdíte za chvíli, ale nejprve musíte zajistit, aby Git sledoval tento soubor, který se nazývá přípravný soubor.

   Při spuštění git commitse potvrdí pouze fázované změny. Potom spuštěním git add příkazu přidáte azure-pipelines.yml do pracovní oblasti nebo indexu.

2. Spuštěním následujícího git add příkazu přidejte azure-pipelines.yml do pracovní oblasti:

   git add azure-pipelines.yml
   

3. Spuštěním následujícího git commit příkazu potvrďte fázovaný soubor do code-workflow větve:

   git commit -m "Add the build configuration"
   

   Argument -m určuje zprávu potvrzení. Zpráva potvrzení se stane součástí historie změněného souboru. Pomáhá revidujícím pochopit změnu a pomáhá budoucím správci pochopit, jak se soubor v průběhu času změnil.

   Tip

   Nejlepší zprávy potvrzení dokončí větu: "Pokud použijete toto potvrzení, budete ..."

   Pokud argument -m vynecháte, Git zobrazí textový editor, ve kterém můžete podrobně popsat změnu. Tato možnost je užitečná, pokud chcete zadat zprávu potvrzení, která zahrnuje více řádků. Text po první prázdný řádek určuje název potvrzení.

4. Spuštěním tohoto git push příkazu nasdílejte nebo nahrajte větev do úložiště na GitHubu code-workflow :

   git push origin code-workflow
   

5. Jako volitelný krok přejděte do projektu ve službě Azure Pipelines a sledujte sestavení při jeho spuštění.

   Toto sestavení se nazývá sestavení CI. Konfigurace kanálu používá aktivační událost , která určuje, které větve se účastní procesu sestavení. V této části určuje "*" všechny větve.

   trigger:
   - '*'
   

   Později se dozvíte, jak řídit konfiguraci kanálu pro sestavování jenom z větví, které potřebujete.

   Uvidíte, že se sestavení úspěšně dokončí a vytvoří artefakt, který obsahuje vytvořenou webovou aplikaci.

Vytvoření žádosti o přijetí změn

Tady vytvoříte žádost o přijetí změn pro vaši větev:

1. V prohlížeči se přihlaste k GitHubu.

2. Přejděte do svého úložiště mslearn-tailspin-spacegame-web .

3. V rozevíracím seznamu Větev vyberte svoji code-workflow větev.

   

4. Pokud chcete zahájit žádost o přijetí změn, vyberte Možnost Přispívat a pak Otevřít žádost o přijetí změn.

   

5. Ujistěte se, že základ určuje vaše forkované úložiště, a ne úložiště Microsoftu.

   Váš výběr vypadá takto:

   

   Důležité

   Tento krok je důležitý, protože nemůžete sloučit změny do úložiště Microsoftu. Ujistěte se, že základní úložiště odkazuje na váš účet GitHub, a ne Na MicrosoftDocs.

   Pokud skončíte s pull requestem vůči MicrosoftDocs, zavřete pull request a opakujte tyto kroky.

   Tento proces zahrnuje další krok, protože pracujete z forku úložiště. Pokud pracujete přímo s vlastním úložištěm a nepoužíváte fork, vybere se vaše větev main automaticky.

6. Zadejte název a popis žádosti o přijetí změn.

   • Název:

     Configure Azure Pipelines (Konfigurace Azure Pipelines)

   • Popis:

     Tato konfigurace kanálu sestaví aplikaci a vytvoří sestavení pro konfiguraci vydané verze.

7. Pokud chcete žádost o přijetí změn dokončit, vyberte Vytvořit žádost o přijetí změn.

   Tento krok nesloučí žádný kód. Ostatním říká, že jste navrhli změny, které se mají sloučit do main větve.

   

   Zobrazí se okno žádosti o přijetí změn. Můžete vidět, že stav sestavení ve službě Azure Pipelines je nakonfigurovaný tak, aby se zobrazoval jako součást žádosti o přijetí změn. Díky tomu můžete vy i ostatní zobrazit stav sestavení, když je spuštěný.

   

   Stejně jako když nasdílíte větev do GitHubu, ve výchozím nastavení žádost o přijetí změn aktivuje Microsoft Azure Pipelines k sestavení vaší aplikace.

   Tip

   Pokud se stav buildu nezobrazuje hned, chvíli počkejte nebo stránku aktualizujte.

8. Volitelně můžete vybrat odkaz Podrobnosti a pak trasovat sestavení, jak prochází kanálem.

   Svůj build můžete předat do dalšího kroku v procesu, kterým může být například kontrola kvality. Později můžete nakonfigurovat kanál tak, aby posunul vaše změny do oddělení kontroly kvality nebo produkčního prostředí.

9. Vraťte se ke své žádosti o přijetí změn na GitHubu.

   Počkejte, až se sestavení dokončí. Teď jste připravení svoji žádost o přijetí změn sloučit.

   

10. Vyberte Sloučit žádost o přijetí změn a pak vyberte Potvrdit sloučení.

11. Pokud chcete odstranit větev z GitHubu code-workflow , vyberte Odstranit větev.

    

    Po sloučení žádosti o přijetí změn je zcela bezpečné odstranit větev z GitHubu. Ve skutečnosti je to běžný postup, protože větev už není potřeba. Změny se sloučí a podrobnosti o změnách najdete na GitHubu nebo na příkazovém řádku. Odstranění sloučené větve také pomáhá ostatním zobrazit jenom práci, která je aktuálně aktivní.

    Větve Gitu mají být krátkodobé. Po sloučení větve do ní nenasdílíte další potvrzení ani ji sloučíte podruhé. Ve většině případů při každém spuštění nové funkce nebo opravy chyb začnete čistou větví, která je založená na main větvi.

    Odstraněním větve na GitHubu se daná větev neodstraní z vašeho místního systému. Pokud byste to chtěli udělat, přidejte k příkazu -d přepínač git branch.

Kolikrát se změna sestavuje?

Odpověď závisí na tom, jak máte nadefinovanou konfiguraci sestavení. V Azure Pipelines můžete definovat triggery, které určují, jaké události způsobí, že proběhne sestavení. Můžete určit, které větve se sestaví nebo které soubory aktivují sestavení.

Řekněme například, že chcete, aby se sestavení stalo, když se změna nasdílí do GitHubu v libovolné větvi GitHubu. Ale nechcete, aby se sestavení stalo, když jediné změny jsou soubory ve složce dokumentace projektu. Tuto část můžete chtít zahrnout trigger do konfigurace sestavení:

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

Ve výchozím nastavení se sestavení aktivuje při vložení změny do libovolného souboru v libovolné větvi.

Sestavení kontinuální integrace (CI) je sestavení, které se spustí při nasdílení změn do větve.

Sestavení žádosti o přijetí změn je sestavení, které se spustí při otevření žádosti o přijetí změn nebo při nasdílení dalších změn do existující žádosti o přijetí změn.

Změny, které provedete prostřednictvím code-workflow větve, se vytvářejí za tří podmínek:

• Sestavení CI proběhne, když nasdílíte změny do větve code-workflow.
• Sestavení PR proběhne, když ve větvi code-workflow otevřete žádost o přijetí změn do větve main.
• Konečné sestavení CI proběhne po sloučení žádosti o přijetí změn do main větve.

Sestavení pr vám pomůžou ověřit, že navrhované změny budou fungovat správně po jejich sloučení do main jiné cílové větve.

Finální sestavení CI ověřuje, jestli jsou změny pořád funkční i po sloučení žádosti o přijetí změn.

Jako volitelný krok přejděte do Azure Pipelines a sledujte, jak ve větvi probíhá main konečné sestavení CI.