Gyakorlat – Több konfiguráció létrehozása sablonok használatával

11 perc

Az előző gyakorlatokban implementált egy folyamatot, amely létrehozza a Space Game webhelyét. Egy olyan szkripttel kezdett, amely minden buildelési műveletet végrehajtott, és az egyes műveleteket a megfelelő folyamatfeladatra képezte le. A folyamat kimenete egy .zip fájl, amely a lefordított webalkalmazást tartalmazza.

Ebben a gyakorlatban egy sablon használatával definiálhatja a projektfájlban definiált konfigurációkat összeállító buildelési feladatokat. A sablonok lehetővé teszik, hogy egyszer definiálja a logikát, majd többször újra felhasználja. A sablonok több YAML-fájl tartalmát egyesítik egyetlen folyamatban.

Tipp.

A modul ezen lépése nem kötelező. Ha jelenleg nem szeretne többet megtudni a sablonokról, folytassa a következő lépésekkel: Az Azure DevOps-környezet megtisztítása. A sablonokról további információt a Sablontípusok > használat című témakörben talál.

Először is nézzük meg, mit csinál Mara és Amita.

A bemutató

Mara alig várja, hogy megoszthassa az eredményeit, és megkeresi Amitát, hogy megmutassa neki a buildfolyamatot.

Amita: Lenyűgözött, hogy ilyen gyorsan dolgoztál! Valójában csak azért jöttem, hogy láthassam, mert kaptam egy e-mailt, hogy a build elkészült. Köszönjük Látom, hogy a folyamat csak a kiadási konfigurációt hozza létre. Hibakeresési buildeket is használunk, hogy további információkat rögzíthessünk, ha az alkalmazás összeomlik. Ezt is hozzá tudjuk adni?

Mara: Abszolút. Nem gondoltam a hibakeresési buildekre, amikor beállítottam. Mi lenne, ha együtt leülnénk és hozzáadnánk?

Amita: Megmutatta nekem a YAML-fájlt, amely meghatározza a build lépéseit, de nem vagyok benne biztos, hogy tudnám, hogyan kell módosítani.

Ez rendben van. Nézheted, ahogy gépelek. Majd együtt átvesszük.

Hogyan definiálná a két buildkonfigurációt?

Tekintse meg a következő feladatokat, amelyek létrehozzák és közzéteszik a Space Game webes projekt kiadási konfigurációját. (Ezt a kódot ne adja hozzá az azure-pipelines.yml fájlhoz.)

- task: DotNetCoreCLI@2
  displayName: 'Build the project - Release'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

A hibakeresési konfiguráció létrehozásához ismételje meg ezt a két feladatot, de cserélje le Release a következőre Debug: .

Ha így tesz, a keresett eredményt adja, de mi történik, ha a build összetettebbé válik, vagy megváltoznak a követelmények? Manuálisan kell megkeresnie és módosítania az egyes buildfeladatok mindkét változatát. A további buildelési követelmények hozzáadása után két feladatot is létre kell hoznia, egyet a hibakeresési konfigurációhoz, egyet pedig a kiadáshoz, hogy megfeleljen ezeknek a követelményeknek.

Jobb megoldás a sablon használata.

Mik azok a sablonok?

A sablonokkal egyszer definiálhatja a gyakori buildelési feladatokat, és többször is felhasználhatja őket.

Buildelési lépésként meghív egy sablont a szülőfolyamatból. A paramétereket a szülőfolyamatból lehet átadni a sablonnak.

Mara meghatározhatja az alkalmazás sablonként való létrehozásához és közzétételéhez szükséges feladatokat, majd alkalmazhatja a sablont minden szükséges konfigurációra.

A sablon meghatározása

Ne feledje, hogy egy sablon lehetővé teszi a gyakori buildelési feladatok egyszeri meghatározását, és ezeket a feladatokat többször is felhasználhatja. A sablont a szülősablonjából lehet meghívni buildelési lépésként, és a paramétereket a szülőfolyamatból lehet átadni a sablonnak.

Most létre fog hozni egy sablont, amely a projektfájlban definiált konfigurációkat képes létrehozni.

A Visual Studio Code integrált konzolján, a projekt gyökerében hozzon létre egy sablonkönyvtárat .
```
mkdir templates
```
A gyakorlatban bármilyen helyre elhelyezhet sablonfájlt. Nem kell őket a sablonok könyvtárába helyeznie.
A Visual Studio Code-ban válassza az Új fájl fájlja > lehetőséget. Ezután ha build.yml fájlként szeretné menteni az üres fájlt a projekt sablonkönyvtárában, válassza a Fájl > mentése lehetőséget. Ilyen például a ~/mslearn-tailspin-spacegame-web/templates.

Fontos

A Korábbiakhoz hasonlóan a Windowsban a Mentés típusként listában válassza a YAML lehetőséget.

A Visual Studio Code-ban adja hozzá ezt a kódot a build.yml fájlhoz:

parameters:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
    zipAfterPublish: true

Ezek a feladatok úgy néznek ki, mint azok, amelyeket korábban definiált az alkalmazás létrehozásához és közzétételéhez. A sablonban azonban a bemeneti paraméterek másként működnek, mint a normál változókkal. Két különbség:

Egy sablonfájlban használja a szakaszt a parameters bemenetek definiálása helyett variables .
Egy sablonfájlban szintaxist használjon ${{ }} a paraméter értékének beolvasása helyett $() . Amikor beolvassa egy paraméter értékét, a szakaszt belefoglalja a parameters nevébe. For example, ${{ parameters.buildConfiguration }}.

A sablon meghívása a folyamatból

Ekkor meghívja a folyamatból most létrehozott sablont. Ezt meg kell tenni egyszer a hibakeresési konfigurációhoz, majd meg kell ismételni a folyamatot a kiadási konfigurációhoz.

A Visual Studio Code-ban módosítsa az azure-pipelines.yml-t az itt látható módon:

trigger:
- '*'

pool:
  vmImage: ubuntu-latest

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'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

trigger:
- '*'

pool:
  name: 'Default' #replace if needed with name of your agent pool

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'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Ez a fájl az eredetihez hasonlóan néz ki, azzal a kivétellel, hogy a buildelési és közzétételi feladatokat a sablonhoz intézett hívásokra cseréli, amelyek ugyanazokat a feladatokat végzik.

Látni fogja, hogy a sablont minden konfigurációhoz egyszer hívják meg. Ha át szeretné adni a konfiguráció nevét a sablonnak, minden template tevékenység az argumentumot parameters használja.

A folyamat futtatása

Ezután leküldi a módosításokat a GitHubra, és láthatja a folyamat futtatását.

Az integrált terminálban adja hozzá az indexhez az azure-pipelines.yml és a templates/build.yml fájlt, véglegesítse a módosításokat, majd továbbítsa őket a GitHubba.
```
git add azure-pipelines.yml templates/build.yml
git commit -m "Support build configurations"
git push origin build-pipeline
```
Az Azure Pipelinesban kövesse nyomon a buildet az egyes lépéseken, ahogy korábban is tette.

A folyamat futtatásakor látni fogja, hogy a folyamat kibontja a sablonon belüli tevékenységeket. A projektet összeállító és közzétevő tevékenységek két alkalommal futnak, mindegyik buildkonfigurációhoz egyszer.
Amikor a build befejeződött, térjen vissza az összefoglaló oldalra, és válassza ki a korábban közzétett összetevőt. Bontsa ki a drop mappát.

Látni fogja, hogy a folyamat létrehoz egy .zip fájlt a hibakeresési konfigurációhoz és a kiadási konfigurációhoz is.

Az ág egyesítése a főágba

Ezen a ponton egy működő buildelési folyamattal rendelkezik, amely mindent végrehajt, amire Mara most szüksége van.

A gyakorlatban egy lekéréses kérelmet kell küldenie, amely egyesíti az ágat build-pipeline az main ágban.

Mi most kihagyjuk ezt a lépést. A következő modulban megismerhet néhány módszert a csapattal való együttműködésre a GitHubon, beleértve a lekéréses kérelmek elküldését, áttekintését és egyesítését.

Folytatás