Övning – Skapa en pull-begäran

Slutförd

I den här lektionen övar du på att skicka en pull-begäran och slå samman ändringarna i grenen main så att alla kan dra nytta av ditt arbete.

I Skapa en byggpipeline med Azure Pipelines skapade du en Git-gren med namnet build-pipeline, där du definierade en grundläggande byggpipeline för webbplatsen Space Game . Kom ihåg att versionsdefinitionen finns i en fil med namnet azure-pipelines.yml.

Även om grenen skapar en byggartefakt finns det bara på grenen build-pipeline . Du måste slå samman grenen till grenen main .

Kom ihåg att en pull-begäran talar om för de andra utvecklarna att du har kod som är redo att granska, om det behövs, och att du vill att dina ändringar ska sammanfogas i en annan gren, till exempel grenen main .

Innan vi börjar ska vi se hur det går för Mara och Andy.

Hej, Mara. Jag vet att du har en bygg-pipeline som körs på Azure. Jag lägger till en funktion på webbplatsen och vill se byggprocessen själv. Är vi redo att göra det?

Mara: Absolut. Jag skapade pipelinen på en gren. Varför skapar vi inte en pull-begäran och sammanfogar den main så att du också kan använda pipelinen?

Andy: Låter bra. Vi tar oss en titt.

Skapa en gren och lägg till startkod

Även om du kan använda bygg-pipelinen som du skapade i föregående modul ska vi skapa en ny gren med namnet code-workflow. Den här grenen baseras på main, så du kan öva processen från början.

1. Öppna den integrerade terminalen i Visual Studio Code.

2. Växla till grenen main :

   git checkout main
   

3. Kontrollera att du har den senaste versionen av koden från GitHub:

   git pull origin main
   

4. Skapa en gren med namnet code-workflow:

   git checkout -B code-workflow
   

   Argumentet -b anger skapande av en ny gren om en sådan inte finns. Utelämna argumentet -b när du vill växla till en befintlig gren.

   Som standard bygger din nya gren på den föregående grenen, där du körde kompilerat git checkout. Här är mainden överordnade grenen , men den överordnade grenen kan vara en annan, till exempel en funktionsgren som någon annan har startat som du vill bygga vidare på eller experimentera med.

   Det är nu säkert att göra de ändringar du behöver, eftersom du är på din egen lokala gren. Om du vill se vilken gren du är på kör git branch -vdu .

5. Öppna azure-pipelines.yml från utforskaren och ersätt innehållet med följande:

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

   Den här konfigurationen liknar den grundläggande som du skapade i föregående modul. För korthet bygger det bara projektets versionskonfiguration.

Skicka grenen till GitHub

Här skickar du din code-workflow gren till GitHub och ser hur Azure Pipelines skapar programmet.

1. I terminalen kör du git status för att se vilket obekräftade arbete som finns på din gren:

   git status
   

   Du ser att azure-pipelines.yml har ändrats. Du kommer att checka in det till din gren inom kort, men du måste först se till att Git spårar den här filen som kallas mellanlagring av filen.

   Endast mellanlagrade ändringar utförs när du kör git commit. git add Kör sedan kommandot för att lägga till azure-pipelines.yml till mellanlagringsområdet eller indexet.

2. Kör följande git add kommando för att lägga till azure-pipelines.yml i mellanlagringsområdet:

   git add azure-pipelines.yml
   

3. Kör följande git commit kommando för att checka in den mellanlagrade filen till grenen code-workflow :

   git commit -m "Add the build configuration"
   

   Argumentet -m anger incheckningsmeddelandet. Incheckningsmeddelandet blir en del av historiken för en ändrad fil. Den hjälper granskare att förstå ändringen och hjälper framtida underhållare att förstå hur filen har ändrats över tid.

   Dricks

   De bästa incheckningsmeddelandena slutför meningen "Om du tillämpar den här incheckningen kommer du ..."

   Om du utelämnar argumentet -m öppnar Git ett redigeringsprogram där du kan beskriva ändringen. Det här alternativet är användbart när du vill ange ett incheckningsmeddelande som sträcker sig över flera rader. Texten upp till den första tomma raden anger incheckningsrubriken.

4. Kör det här git push kommandot för att skicka eller ladda upp grenen code-workflow till din lagringsplats på GitHub:

   git push origin code-workflow
   

5. Som ett valfritt steg går du till projektet i Azure Pipelines och spårar bygget när det körs.

   Den här versionen kallas för en CI-version. Din pipelinekonfiguration använder det som kallas en utlösare för att styra vilka grenar som deltar i byggprocessen. Här anger "*" alla grenar.

   trigger:
   - '*'
   

   Senare får du se hur du styr pipelinekonfigurationen för att endast skapa från de grenar som du behöver.

   Du ser att bygget har slutförts och skapar en artefakt som innehåller det byggda webbprogrammet.

Skapa en pull-begäran

Här skapar du en pull-begäran för din gren:

1. Logga in på GitHub i en webbläsare.

2. Gå till lagringsplatsen mslearn-tailspin-spacegame-web .

3. I listrutan Gren väljer du din code-workflow gren.

   

4. Starta pull-begäran genom att välja Bidra och sedan Öppna pull-begäran.

   

5. Kontrollera att basen anger din förgrenade lagringsplats och inte Microsoft-lagringsplatsen.

   Ditt val ser ut så här:

   

   Viktigt!

   Det här steget är viktigt eftersom du inte kan sammanfoga ändringarna till Microsoft-lagringsplatsen. Se till att baslagringsplatsen pekar på ditt GitHub-konto och inte MicrosoftDocs.

   Om du får en pull-begäran mot MicrosoftDocs bör du stänga pull-begäran och upprepa de här stegen.

   Den här processen innebär ett extra steg eftersom du arbetar från en förgrenad lagringsplats. När du arbetar direkt med din egen lagringsplats, och inte en förgrening, väljs din main-gren som standard.

6. Ange en rubrik och beskrivning för pull-begäran.

   • Titel:

     Konfigurera Azure Pipelines

   • Beskrivning:

     Den här pipelinekonfigurationen skapar programmet och skapar en version för versionskonfigurationen.

7. Slutför pull-begäran genom att välja Skapa pull-begäran.

   Det här steget sammanfogar ingen kod. Den talar om för andra att du har föreslagit att ändringar ska sammanfogas i grenen main .

   

   Fönstret pull-begäran visas. Du kan se att byggstatusen i Azure Pipelines är konfigurerad för att visas som en del av pull-begäran. På så sätt kan du och andra visa status för bygget när det körs.

   

   Precis som när du skickar en gren till GitHub utlöser en pull-begäran som standard Microsoft Azure Pipelines för att skapa ditt program.

   Dricks

   Om du inte ser att byggstatusen visas direkt väntar du en stund eller uppdaterar sidan.

8. Du kan också välja länken Information och sedan spåra bygget när det rör sig genom pipelinen.

   Du kan lämna över bygget till nästa steg i processen, till exempel kvalitetskontroll. Senare kan du konfigurera pipelinen för att skicka din ändring hela vägen ut till labbet för kvalitetskontroll eller till produktion.

9. Gå tillbaka till din pull-begäran på GitHub.

   Vänta tills bygget har slutförts. Nu är du redo att sammanslå pull-begäran.

   

10. Välj Koppla pull-begäran och välj sedan Bekräfta sammanslagning.

11. Om du vill ta bort grenen code-workflow från GitHub väljer du Ta bort gren.

    

    Det är helt säkert att ta bort en gren från GitHub när du har slagit samman pull-begäran. Det är faktiskt vanligt eftersom grenen inte längre behövs. Ändringarna sammanfogas och du kan fortfarande hitta information om ändringarna på GitHub eller från kommandoraden. Om du tar bort en sammanslagen gren kan andra bara se det arbete som för närvarande är aktivt.

    Git-grenar är avsedda att vara kortlivade. När du har sammanfogat en gren skickar du inte ytterligare incheckningar till den eller sammanfogar den en andra gång. I de flesta fall börjar du varje gång du börjar med en ny funktion eller buggkorrigering med en ren gren som baseras på grenen main .

    När en gren tas bort på GitHub tas den inte bort från ditt lokala system. Om du vill göra det skickar du -d-växeln till kommandot git branch.

Hur många gånger byggs en ändring?

Svaret beror på hur din byggkonfiguration är definierad. Med Azure Pipelines kan du definiera utlösare som anger vilka händelser som gör att byggen skapas. Du kan styra vilka grenar som skapas och till och med vilka filer som utlöser bygget.

Anta till exempel att du vill att en version ska ske när en ändring skickas till GitHub på valfri Git-gren. Men du vill inte att bygget ska ske när de enda ändringarna är filer i projektets dokumentmapp . Du kanske vill ta med det här trigger avsnittet i byggkonfigurationen:

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

Som standard utlöses en version när en ändring skickas till alla filer på en gren.

En kontinuerlig integreringsversion (CI) är en version som körs när du push-överför en ändring till en gren.

En pull-begärandeversion (PR) är en version som körs när du öppnar en pull-begäran eller när du skickar ytterligare ändringar till en befintlig pull-begäran.

De ändringar du gör via grenen code-workflow skapas under tre villkor:

• Ett KI-bygge sker när du skickar ändringar till code-workflow-grenen.
• Ett PR-bygge sker när du öppnar en pull-begäran på code-workflow-grenen mot main-grenen.
• En slutlig CI-version sker när pull-begäran har sammanfogats till grenen main .

PR-versioner hjälper dig att kontrollera att de föreslagna ändringarna fungerar korrekt när de har sammanfogats till main eller en annan målgren.

Det slutliga KI-bygget verifierar att ändringarna fortfarande är korrekta efter att PB-bygget har sammanslagits.

Som ett valfritt steg går du till Azure Pipelines och ser den slutliga CI-versionen ske på grenen main .