Oefening: een pull-aanvraag maken

12 minuten

In deze les oefent u het proces voor het indienen van een pull-aanvraag en het samenvoegen van uw wijzigingen in de main vertakking, zodat iedereen kan profiteren van uw werk.

In Een build-pijplijn maken met Azure Pipelines hebt u een Git-vertakking gemaakt met de naam build-pipeline, waar u een eenvoudige build-pijplijn hebt gedefinieerd voor de Space Game-website . Zoals u weet, bevindt uw builddefinitie zich in een bestand met de naam azure-pipelines.yml.

Hoewel uw vertakking een build-artefact produceert, bestaat dat alleen in de build-pipeline vertakking. U moet uw vertakking samenvoegen in de main vertakking.

Zoals u weet, vertelt een pull-aanvraag de andere ontwikkelaars dat u code hebt die u zo nodig kunt controleren en wilt dat uw wijzigingen worden samengevoegd in een andere vertakking, zoals de main vertakking.

Maar eerst gaan we nog eens kijken bij Mara en Andy.

Andy: Hallo Mara. Ik weet dat er een build-pipeline wordt uitgevoerd in Azure. Ik voeg een functie toe aan de website en ik wil het buildproces voor mezelf zien. Is dat mogelijk?

Mara: Absoluut. Ik heb de pipeline gemaakt in een vertakking. Waarom maken we geen pull-aanvraag en laten we deze samenvoegen main zodat u ook de pijplijn kunt gebruiken?

Andy: Klinkt geweldig. We gaan eens kijken.

Een vertakking maken en starterscode toevoegen

Hoewel u de build-pijplijn kunt gebruiken die u in de vorige module hebt gemaakt, gaan we een nieuwe vertakking maken met de naam code-workflow. Deze vertakking is gebaseerd op main, zodat u het proces vanaf het begin kunt oefenen.

Open in Visual Studio Code de geïntegreerde terminal.
Overschakelen naar de main vertakking:
```
git checkout main
```
Zorg ervoor dat u de nieuwste versie van de code van GitHub hebt:
```
git pull origin main
```
Maak een vertakking met de naam code-workflow:
```
git checkout -B code-workflow
```
Met het argument -b bepaalt u dat u een nieuwe vertakking wilt maken als de vertakking nog niet bestaat. Laat het argument -b achterwege als u wilt overschakelen naar een bestaande vertakking.

Standaard wordt de nieuwe vertakking gebaseerd op de vertakking van waaruit u de opdracht git checkout uitvoert. Hier is mainde bovenliggende vertakking, maar de bovenliggende vertakking kan een andere zijn, zoals een functiebranch waarmee iemand anders is begonnen en waarmee u wilt bouwen of experimenteren.

Het is nu veilig om wijzigingen aan te brengen die u nodig hebt, omdat u zich in uw eigen lokale vertakking bevindt. Als u wilt zien in welke vertakking u zich bevindt, voert u de opdracht uit git branch -v.

Open azure-pipelines.yml vanuit de Verkenner en vervang de inhoud door:

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

Deze configuratie lijkt op de basisconfiguratie die u in de vorige module hebt gemaakt. Ter beknoptheid wordt alleen de releaseconfiguratie van uw project gebouwd.

De vertakking pushen naar GitHub

Hier pusht u uw code-workflow vertakking naar GitHub en bekijkt u hoe Azure Pipelines de toepassing bouwt.

Voer in de terminal uit git status om te zien wat er niet-verzonden werk in uw vertakking bestaat:
```
git status
```
U ziet dat azure-pipelines.yml is gewijzigd. U gaat dit zo snel doorvoeren in uw vertakking, maar eerst moet u ervoor zorgen dat Git dit bestand bijhoudt. Dit bestand wordt staging van het bestand genoemd.

Alleen gefaseerde wijzigingen worden doorgevoerd wanneer u deze uitvoert git commit. Vervolgens voert u de git add opdracht uit om azure-pipelines.yml toe te voegen aan het faseringsgebied of de index.
Voer de volgende git add opdracht uit om azure-pipelines.yml toe te voegen aan het faseringsgebied:
```
git add azure-pipelines.yml
```
Voer de volgende git commit opdracht uit om het gefaseerde bestand door te voeren naar de code-workflow vertakking:
```
git commit -m "Add the build configuration"
```
Met het argument -m geeft u het doorvoerbericht op. Het doorvoerbericht maakt deel uit van de geschiedenis van een gewijzigd bestand. Het helpt revisoren inzicht te krijgen in de wijziging en toekomstige onderhouders begrijpen hoe het bestand in de loop van de tijd is gewijzigd.

Fooi

De beste doorvoerberichten vullen de zin 'Als u deze doorvoering toepast, zult u ...' voltooien

Als u het argument -m weglaat, opent Git een teksteditor waarin u de wijziging kunt toelichten. Deze optie is handig voor het opgeven van een doorvoerbericht dat uit meerdere regels bestaat. De tekst tot aan de eerste lege regel is de titel van de doorvoering.
Voer deze git push opdracht uit om de code-workflow vertakking naar uw opslagplaats op GitHub te pushen of uploaden:
```
git push origin code-workflow
```
Als optionele stap gaat u naar uw project in Azure Pipelines en traceert u de build terwijl deze wordt uitgevoerd.

Deze build wordt een CI-build genoemd. Uw pijplijnconfiguratie maakt gebruik van een trigger om te bepalen welke vertakkingen deelnemen aan het buildproces. Hier geeft '*' alle vertakkingen op.
```
trigger:
- '*'
```
Later ziet u hoe u de pijplijnconfiguratie kunt beheren om alleen te bouwen vanaf de vertakkingen die u nodig hebt.

U ziet dat de build is voltooid en een artefact produceert dat de ingebouwde webtoepassing bevat.

Een pull-aanvraag maken

Hier maakt u een pull-aanvraag voor uw vertakking:

Meld u in een browser aan bij GitHub.
Ga naar uw opslagplaats mslearn-tailspin-spacegame-web .
Selecteer uw code-workflow vertakking in de vervolgkeuzelijst Vertakking.
Als u uw pull-aanvraag wilt starten, selecteert u Bijdragen en opent u vervolgens een pull-aanvraag.
Zorg ervoor dat de basis uw geforkte opslagplaats opgeeft en niet de Microsoft-opslagplaats.

Uw selectie ziet er als volgt uit:

Belangrijk

Deze stap is belangrijk omdat u uw wijzigingen niet kunt samenvoegen in de Microsoft-opslagplaats. Zorg ervoor dat de basisopslagplaats verwijst naar uw GitHub-account en niet naar MicrosoftDocs.

Als u uiteindelijk een pull-aanvraag tegen MicrosoftDocs hebt, sluit u de pull-aanvraag en herhaalt u deze stappen.

Dit proces omvat een extra stap omdat u werkt vanuit een geforkte opslagplaats. Wanneer u rechtstreeks met uw eigen opslagplaats werkt en niet met een fork, wordt uw main-vertakking standaard geselecteerd.
Voer een titel en beschrijving in voor uw pull-aanvraag.
- Titel:
  
  Azure Pipelines configureren
- Beschrijving:
  
  Deze pijplijnconfiguratie bouwt de toepassing en produceert een build voor de releaseconfiguratie.
Selecteer Pull-aanvraag maken om uw pull-aanvraag te voltooien.

Met deze stap wordt er geen code samengevoegd. Hiermee wordt aan anderen aangegeven dat u wijzigingen hebt voorgesteld die moeten worden samengevoegd in de main vertakking.

Het venster pull-aanvraag wordt weergegeven. U kunt zien dat de buildstatus in Azure Pipelines is geconfigureerd om te worden weergegeven als onderdeel van de pull-aanvraag. Op die manier kunnen u en anderen de status van de build bekijken terwijl deze wordt uitgevoerd.

Net zoals wanneer u een vertakking naar GitHub pusht, activeert een pull-aanvraag standaard Microsoft Azure Pipelines om uw toepassing te bouwen.

Fooi

Als de buildstatus niet meteen wordt weergegeven, wacht u even of vernieuwt u de pagina.
Selecteer eventueel de koppeling Details en traceer de build terwijl deze door de pijplijn wordt verplaatst.

U kunt uw build doorgeven aan de volgende stap in het proces, bijvoorbeeld QA. Later kunt u de pipeline configureren om uw wijziging helemaal uit uw QA-lab of productie te pushen.
Ga terug naar uw pull-aanvraag op GitHub.

Wacht tot de compilatie is voltooid. Nu kunt u uw pull-aanvraag samenvoegen.
Selecteer Pull-aanvraag samenvoegen en selecteer Samenvoegen bevestigen.
Als u de code-workflow vertakking wilt verwijderen uit GitHub, selecteert u Vertakking verwijderen.

Het is volledig veilig om een vertakking te verwijderen uit GitHub nadat u uw pull-aanvraag hebt samengevoegd. In feite is het gebruikelijk, omdat de vertakking niet meer nodig is. De wijzigingen worden samengevoegd en u kunt de details van de wijzigingen nog steeds vinden in GitHub of vanaf de opdrachtregel. Als u een samengevoegde vertakking verwijdert, kunnen anderen ook alleen het werk zien dat momenteel actief is.

Git-vertakkingen zijn bedoeld om kort te leven. Nadat u een vertakking hebt samengevoegd, pusht u er geen extra doorvoeringen naartoe of voegt u deze een tweede keer samen. In de meeste gevallen begint u, telkens wanneer u begint met een nieuwe functie of foutoplossing, met een schone vertakking die is gebaseerd op de main vertakking.

Wanneer u een vertakking in GitHub verwijdert, verwijdert u deze vertakking niet van uw lokale systeem. Als u dat wilt doen, geeft u de schakeloptie -d door aan de git branch-opdracht.

Hoe dikwijls wordt een wijziging gebouwd?

Het antwoord is afhankelijk van hoe uw buildconfiguratie is gedefinieerd. Met Azure Pipelines kunt u triggers definiëren om op te geven welke gebeurtenissen builds veroorzaken. U kunt bepalen welke vertakkingen worden gebouwd en zelfs welke bestanden de build activeren.

Stel dat u een build wilt laten plaatsvinden wanneer een wijziging wordt gepusht naar GitHub in een Willekeurige Git-vertakking. Maar u wilt niet dat de build wordt uitgevoerd wanneer de enige wijzigingen zijn in bestanden in de documentmap van uw project. Mogelijk wilt u deze trigger sectie opnemen in uw buildconfiguratie:

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

Standaard wordt een build geactiveerd wanneer een wijziging naar een bestand in een vertakking wordt gepusht.

Een CI-build (continue integratie ) is een build die wordt uitgevoerd wanneer u een wijziging naar een vertakking pusht.

Een pull-aanvraag -build (PR) is een build die wordt uitgevoerd wanneer u een pull-aanvraag opent of wanneer u aanvullende wijzigingen naar een bestaande pull-aanvraag pusht.

De wijzigingen die u via de code-workflow vertakking aanbrengt, worden gebouwd onder drie voorwaarden:

Er vindt een CI-build plaats wanneer u wijzigingen in de code-workflow-vertakking pusht.
Er vindt een PR-build plaats wanneer u op de code-workflow-vertakking een pull-aanvraag opent voor de main-vertakking.
Er wordt een definitieve CI-build uitgevoerd nadat de pull-aanvraag is samengevoegd met de main vertakking.

Pr-builds helpen u te controleren of uw voorgestelde wijzigingen correct werken nadat ze zijn samengevoegd met main of een andere doelvertakking.

Met de definitieve CI-build controleert u of de wijzigingen nog steeds goed zijn nadat de pull-aanvraag is samengevoegd.

Als optionele stap gaat u naar Azure Pipelines en bekijkt u hoe de uiteindelijke CI-build op de main vertakking plaatsvindt.

Doorgaan

Een vertakking maken en starterscode toevoegen

De vertakking pushen naar GitHub

Een pull-aanvraag maken

Hoe dikwijls wordt een wijziging gebouwd?

Feedback