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

12 min

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.

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.

Ondra: 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?

Ondra: Zní to 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.

V editoru Visual Studio Code otevřete integrovaný terminál.
Přepněte do main větve:
```
git checkout main
```
Ujistěte se, že máte nejnovější verzi kódu z GitHubu:
```
git pull origin main
```
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 .

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.

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 byla změněna. Za chvíli tuto větev přidáte do svého branch, ale nejprve musíte zajistit, aby Git sledoval tento soubor, který se nazývá staging.

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

Návod

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í.
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
```
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á spouštěč, 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:

V prohlížeči se přihlaste k GitHubu.
Otevřete své úložiště mslearn-tailspin-spacegame-web.
V rozevíracím seznamu Větev vyberte svoji code-workflow větev.
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.
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.
Zadejte název a popis žádosti o přijetí změn.
- Název:
  
  Konfigurace Azure Pipelines
- Popis:
  
  Tato konfigurace potrubí sestaví aplikaci a vytvoří sestavení pro konfiguraci Release.
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.

Návod

Pokud se stav buildu nezobrazuje hned, chvíli počkejte nebo stránku aktualizujte.
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í.
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.
Vyberte Sloučit žádost o sloučení a pak vyberte Potvrdit sloučení.
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í. Azure Pipelines umožňuje definovat spouštěče, které určují, které události vyvolají 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í, které se spustí, když provedete změnu na větev, se nazývá sestavení kontinuální integrace (CI).

Sestavení pull requestu (PR) je sestavení, které se spustí, když otevřete pull request nebo když přidáte další změny do stávajícího pull requestu.

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 pomohou ověřit, že navrhované změny budou fungovat správně po jejich sloučení do main nebo 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.

Váš názor

Byla tato stránka užitečná?