Előző

Következő

Gyakorlat – Lekéréses kérelem létrehozása

Befejeződött

Ebben a leckében egy lekéréses kérelem elküldésének és a módosítások ágba main egyesítésének folyamatát fogja gyakorolni, hogy mindenki kihasználhassa a munkáját.

Az Azure Pipelines buildelési folyamatának létrehozása során létrehozott egy Git-ágat, build-pipelineamely egy alapszintű buildelési folyamatot definiált a Space Game webhelyéhez. Ne feledje, hogy a builddefiníció egy azure-pipelines.yml nevű fájlban található.

Bár az ág létrehoz egy buildösszetevőt, ez a munka csak az build-pipeline ágon létezik. Egyesítenie kell az ágat az main ágban.

Ne feledje, hogy egy lekéréses kérelem tájékoztatja a többi fejlesztőt, hogy szükség esetén készen áll a kód áttekintésére, és azt szeretné, hogy a módosítások egy másik ágba, például az main ágba egyesüljenek.

Mielőtt belevágnánk, vessünk egy pillantást Marára és Andyre.

Andy: Szia, Mara. Tudom, hogy van egy Azure-ban futó buildfolyamatod. Hozzáadok egy funkciót a webhelyhez, és szeretném látni magamnak a buildelési folyamatot. Készen állunk erre?

Mara: Abszolút. A folyamatot az egyik ágon hoztam létre. Miért nem hozunk létre lekéréses kérelmet, és egyesítjük a folyamatba main , hogy Ön is használhassa?

Andy: Jól hangzik. Lássuk.

Ág létrehozása és kezdőkód hozzáadása

Bár használhatja az előző modulban létrehozott buildelési folyamatot, hozzunk létre egy új ágat.code-workflow Ez az ág alapul main, így az elejétől kezdve gyakorolhatja a folyamatot.

1. Nyissa meg az integrált terminált a Visual Studio Code-ban.

2. Váltás az ágra main :

   git checkout main
   

3. Győződjön meg arról, hogy a kód legújabb verzióját használja a GitHubról:

   git pull origin main
   

4. Hozzon létre egy ágat:code-workflow

   git checkout -B code-workflow
   

   A -b argumentum meghatározza, hogy új ágat kell létrehozni, ha még nem létezik. Ha egy meglévő ágra kíván váltani, hagyja el a -b argumentumot.

   Alapértelmezés szerint az új ág arra a korábbi ágra épül, ahonnan futtatta a git checkout parancsot. Itt a szülőág a mainkövetkező, de a szülőág lehet egy másik, például egy szolgáltatáság, amelyet valaki más indított el, akire építeni szeretne, vagy kísérletezni szeretne vele.

   Most már nyugodtan elvégezheti a szükséges módosításokat, mert a saját helyi ágán van. Ha meg szeretné tekinteni, hogy melyik ágon van, futtassa a parancsot git branch -v.

5. A fájlkezelőben nyissa meg az azure-pipelines.yml fájlt, és cserélje le a tartalmát a következőre:

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

   Ez a konfiguráció hasonlít az előző modulban létrehozott alapszintűre. A rövidség kedvéért csak a projekt kiadási konfigurációját hozza létre.

Az ág leküldése a GitHubba

Itt leküldheti az ágat a code-workflow GitHubra, és megnézheti, ahogy az Azure Pipelines létrehozza az alkalmazást.

1. Futtassa git status a terminálban, hogy lássa, milyen nem véglegesített munka található az ágon:

   git status
   

   Látni fogja, hogy az azure-pipelines.yml módosult. Ezt hamarosan véglegesíteni fogja az ágon, de először meg kell győződnie arról, hogy a Git nyomon követi ezt a fájlt, amelyet átmeneti fájlnak neveznek.

   Futtatáskor git commitcsak szakaszos módosítások lesznek véglegesítettek. Ezután futtassa a parancsot az git add azure-pipelines.yml előkészítési területhez vagy indexhez való hozzáadásához.

2. Futtassa a következő git add parancsot az azure-pipelines.yml előkészítési területhez való hozzáadásához:

   git add azure-pipelines.yml
   

3. Futtassa a következő git commit parancsot a szakaszos fájl ághoz való véglegesítéséhez code-workflow :

   git commit -m "Add the build configuration"
   

   A -m argumentum határozza meg a véglegesítési üzenetet. A véglegesítési üzenet a módosított fájl előzménytörténetének részévé válik. Segít a véleményezőknek megérteni a módosítást, és segít a jövőbeli karbantartóknak megérteni, hogyan változott a fájl az idő múlásával.

   Tipp.

   A legjobb véglegesítési üzenetek befejezik a mondatot: "Ha alkalmazza ezt a véglegesítést, akkor ..."

   Ha elhagyja a -m argumentumot, a Git megjelenít egy szövegszerkesztőt, amelynek segítségével részletezhető a módosítás. Ez a lehetőség akkor hasznos, ha többsoros véglegesítési üzenetet kíván megadni. Az első üres sor előtti szöveg lesz a véglegesítés címe.

4. Futtassa ezt a git push parancsot az ág leküldéséhez vagy feltöltéséhez a code-workflow GitHubon található adattárba:

   git push origin code-workflow
   

5. Opcionális lépésként lépjen a projekthez az Azure Pipelinesban, és futtasd a buildet.

   Ezt a buildet CI-buildnek nevezzük. A folyamatkonfiguráció az úgynevezett eseményindítót használja annak szabályozására, hogy mely ágak vesznek részt a buildelési folyamatban. Itt a "*" az összes ágat megadja.

   trigger:
   - '*'
   

   Később megtudhatja, hogyan szabályozhatja a folyamatkonfigurációt, hogy csak a szükséges ágakból hozzon létre.

   Látni fogja, hogy a build sikeresen befejeződött, és létrehoz egy összetevőt, amely tartalmazza az épített webalkalmazást.

Lekéréses kérelem létrehozása

Itt egy lekéréses kérelmet fog létrehozni az ághoz:

1. Egy böngészőben jelentkezzen be a GitHubra.

2. Nyissa meg az mslearn-tailspin-spacegame-web adattárat.

3. Az Ág legördülő listában válassza ki az ágatcode-workflow.

   

4. A lekéréses kérelem elindításához válassza a Közreműködés , majd a Lekéréses kérelem megnyitása lehetőséget.

   

5. Győződjön meg arról, hogy az alap az elágazott adattárat adja meg, nem pedig a Microsoft-adattárat.

   A kijelölés a következőképpen néz ki:

   

   Fontos

   Ez a lépés azért fontos, mert nem egyesítheti a módosításokat a Microsoft-adattárban. Győződjön meg arról, hogy az alapadattár a GitHub-fiókra mutat, és nem a MicrosoftDocsra.

   Ha végül lekéréses kérelmet küld a MicrosoftDocshoz, egyszerűen zárja be a lekéréses kérelmet, és ismételje meg ezeket a lépéseket.

   Ez a folyamat egy további lépéssel jár, mivel egy elágazott adattárból dolgozik. Ha közvetlenül a saját adattárával dolgozik, és nem egy elágaztatással, alapértelmezés szerint a saját main ága lesz kiválasztva.

6. Adja meg a lekéréses kérelem címét és leírását.

   • Cím:

     Az Azure Pipelines konfigurálása

   • Description:

     Ez a folyamatkonfiguráció létrehozza az alkalmazást, és létrehoz egy buildet a kiadási konfigurációhoz.

7. A lekéréses kérelem befejezéséhez válassza a Lekéréses kérelem létrehozása lehetőséget.

   Ez a lépés nem egyesít semmilyen kódot. Azt jelzi másoknak, hogy javasolt módosításokat az ágba main egyesíteni.

   

   Megjelenik a lekéréses kérelem ablaka. Láthatja, hogy az Azure Pipelines buildállapota úgy van konfigurálva, hogy a lekéréses kérelem részeként jelenjen meg. Így Ön és mások is megtekinthetik a build állapotát futás közben.

   

   Ugyanúgy, mint amikor leküld egy ágat a GitHubra, egy lekéréses kérelem alapértelmezés szerint aktiválja a Microsoft Azure Pipelinest az alkalmazás létrehozásához.

   Tipp.

   Ha nem látja azonnal a build állapotát, várjon néhány percet, vagy frissítse az oldalt.

8. Ha szeretné, válassza a Részletek hivatkozást, majd kövesse nyomon a buildet a folyamat során.

   A buildet továbbíthatja a folyamat következő lépéséhez, például minőség-ellenőrzésre. Később konfigurálhatja a folyamatot úgy, hogy leküldje a módosítást egészen a minőségbiztosítási tesztkörnyezetbe vagy a gyártás számára.

9. Térjen vissza a lekéréses kérelemhez a GitHubon.

   Várjon, amíg a build befejeződik. Most már minden készen áll a lekéréses kérelem egyesítésére.

   

10. Válassza a Lekéréses kérelem egyesítése, majd az Egyesítés megerősítése lehetőséget.

11. Ha törölni szeretné az ágat a code-workflow GitHubról, válassza az Ág törlése lehetőséget.

    

    Teljesen biztonságosan törölhet egy ágat a GitHubról, miután egyesítette a lekéréses kérelmet. Valójában ez egy gyakori gyakorlat, mivel az ágra már nincs szükség. A módosítások egyesítése megtörtént. A módosítások részletei továbbra is megtekinthetők a GitHubon vagy a parancssorból. Az egyesített ág törlése azt is segíti, hogy mások csak az aktuálisan aktív munkát lássák.

    A Git-ágak rövid élettartamúak. Az ágak egyesítése után nem kell további véglegesítéseket leküldnie rá, és nem egyesítheti azt másodszor. A legtöbb esetben minden alkalommal, amikor új funkcióval vagy hibajavítással kezd, az ágon main alapuló tiszta ággal kezd.

    A GitHubról való történő törlésétől függetlenül az ág a helyi rendszerben továbbra is elérhető lesz. Ehhez át kell adni a -d kapcsolót a git branch parancs számára.

Hányszor eredményezi egy módosítás egy új build létrehozását?

A válasz a build konfigurációjától függ. Az Azure Pipelines lehetővé teszi olyan triggerek megadását, amelyek meghatározzák, milyen esemény válthatja ki buildek létrejöttét. Szabályozhatja, hogy melyik ág legyen aktív, vagy akár azt is, hogy milyen fájlok aktiválhatják a buildet.

Tegyük fel például, hogy azt szeretné, hogy a buildek akkor történjenek meg, amikor egy módosítást leküld a GitHubra bármely Git-ágon. Nem szeretné azonban, hogy a build akkor történjen meg, ha csak a projekt dokumentummappájában lévő fájlok módosulnak. Érdemes lehet ezt trigger a szakaszt belefoglalni a buildkonfigurációba:

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

Alapértelmezés szerint a build akkor aktiválódik, ha egy módosítást egy ág bármely fájljára leküld a rendszer.

A folyamatos integrációs (CI) buildek olyan buildek, amelyek akkor futnak, amikor módosítást küld egy ágba.

A lekéréses kérelmek (PR) összeállítása olyan build, amely lekéréses kérelem megnyitásakor vagy egy meglévő lekéréses kérelem további módosításainak leküldésekor fut.

Az ágon végzett code-workflow módosítások három feltétel szerint vannak létrehozva:

• CI-build akkor jön létre, ha a módosításokat leküldik a code-workflow ágra.
• PR-build akkor jön létre, ha megnyitnak egy leküldéses kérelmet a code-workflow ágon, a main ággal esetében.
• A lekéréses kérelem ágba való egyesítése után létrejön egy main végleges CI-build.

A pr-buildek segítségével ellenőrizheti, hogy a javasolt módosítások megfelelően fognak-e működni, miután egyesítették őket vagy egy másik célágat main .

A végső CI-build ellenőrzi, hogy a módosítások a PR egyesítése után sem befolyásolják a működést.

Opcionális lépésként nyissa meg az Azure Pipelinest, és figyelje meg, hogy a ci végleges buildje az ágon main történik.

Folytatás