Sablonkifejezések támogatása az adattárban és a tárolóerőforrás-definíciókban

Ezzel a frissítéssel támogattuk a sablonkifejezéseket az adattárban és a tárolóerőforrás-definíciókban. Most már sablonkifejezéseket is használhat egy ref repository YAML-folyamatban lévő erőforrás tulajdonságának meghatározásához egy adattárerőforrás ágának kiválasztásához. Emellett egy YAML-folyamat erőforrásánakcontainer, volumesportsoptions és tulajdonságainak meghatározásakor endpointa sablonkifejezések is támogatottak.

Részletekért tekintse meg a kibocsátási megjegyzéseket.

Azure Boards

• Munkaelem-hivatkozástípusok szerkesztése
• Ideiglenes lekérdezési REST-végpont létrehozása
• Batch delete API (Privát előzetes verzió)
• @CurrentIteration makró a kézbesítési csomagokban

Azure Pipelines

• Sablonkifejezések az adattár erőforrásdefiníciójában
• Sablonkifejezések a tárolóerőforrás-definícióban
• A jóváhagyások változásainak naplózása
• A feladattár elérhetővé teszi az ügynök üzemeltetési modelljét

Azure Boards

Munkaelem-hivatkozástípusok szerkesztése

Korábban a munkaelem-hivatkozás módosításához legalább három lépésre van szükség. Ha például egy szülőhivatkozást egy kapcsolódó hivatkozásra szeretne módosítani, át kell másolnia a munkaelem-azonosítót, el kell távolítania a szülőhivatkozást, hozzá kell adnia egy új, kapcsolódó típusú hivatkozást, majd be kell illesztenie a másolt azonosítót, és mentenie kell. Ez egy nehézkes folyamat.

A problémát úgy oldottuk meg, hogy lehetővé tettük a hivatkozástípus közvetlen szerkesztését és módosítását. A hivatkozástípust egyetlen lépésben gyorsan módosíthatja.

Feljegyzés

Ez a funkció csak a New Boards Hubs előzetes verziójával lesz elérhető.

Ideiglenes lekérdezési REST-végpont létrehozása

Több bővítménykészítőt is láthattunk, amelyek nem mentett lekérdezéseket próbáltak futtatni a munkaelem lekérdezési nyelvének (WIQL) utasításának lekérdezési sztringen keresztüli átadásával. Ez akkor működik jól, ha nem rendelkezik egy nagy WIQL-utasítással, amely eléri a lekérdezési hosszra vonatkozó böngészőkorlátot. Ennek megoldásához létrehoztunk egy új REST-végpontot, amely lehetővé teszi, hogy az eszközszerzők ideiglenes lekérdezést generáljanak. Ha a válaszból származó azonosítót lekérdezési kapcsolaton keresztül adja át, az megszünteti ezt a problémát.

További információ a temp-lekérdezések REST API dokumentációs oldalán.

Batch delete API (privát előzetes verzió)

Jelenleg a munkaelemek a lomtárból való eltávolításának egyetlen módja az, ha a REST API használatával egyenként törli őket. Ez lassú folyamat lehet, és sebességkorlátozásra van szükség, amikor bármilyen tömeges tisztítást próbál végrehajtani. Válaszul hozzáadtunk egy új REST API-végpontot a kötegelt munkaelemek törléséhez és/vagy megsemmisítéséhez.

Ha szeretne részt venni az új végpont privát előzetes verziójában, kérjük, küldjön nekünk e-mailt közvetlenül.

@CurrentIteration makró a Kézbesítési csomagokban

Ezzel a frissítéssel hozzáadtuk a stílusok makrójának támogatását a @CurrentIteration kézbesítési csomagokban. Ez a makró lehetővé teszi az aktuális iteráció lekérését a terv egyes sorainak csapatkörnyezetéből.

Azure Pipelines

Sablonkifejezések az adattár erőforrásdefiníciójában

A YAML-folyamatban lévő erőforrás tulajdonságának repository meghatározásakor ref a sablonkifejezések támogatása is hozzáadva. Ez a fejlesztői közösség által erősen kért funkció volt.

Vannak használati esetek, amikor azt szeretné, hogy a folyamat azonos adattárerőforrás különböző ágait tekintse át.

Tegyük fel például, hogy van egy folyamat, amely saját adattárat hoz létre, és ehhez ki kell vennie egy erőforrástárat egy erőforrástárból. Tegyük fel továbbá, hogy azt szeretné, hogy a folyamat ugyanazt a tárágat tekintse át, mint amelyet maga is használ. Ha például a folyamat az main ágon fut, akkor ki kell néznie a main tár-adattár ágát. Ha a folyamatok az dev ágon futnak, akkor ki kell néznie az erőforrástár ágát dev .

A mai napig explicit módon meg kellett adnia a kivételhez használandó ágat, és módosítania kellett a folyamatkódot, amikor az ág megváltozik.

Most már sablonkifejezésekkel választhatja ki az adattár-erőforrás ágát. Tekintse meg a folyamat nem fő ágaihoz használandó YAML-kód alábbi példáját:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

A folyamat futtatásakor megadhatja az adattárhoz library kiveendő ágat.

A buildelési várakozási idő alatt kiterjesztendő sablon verziójának megadása

A sablonok nagyszerű módot jelentenek a kódismétlések csökkentésére és a folyamatok biztonságának javítására.

Az egyik népszerű használati eset a sablonok saját adattárban való tárolására. Ez csökkenti a sablon és az azt kiterjesztő folyamatok közötti kapcsolatot, és megkönnyíti a sablon és a folyamatok egymástól függetlenül történő fejlődését.

Tekintse meg az alábbi példát, amelyben egy sablon segítségével figyelheti a lépések listáját. A sablonkód az Templates adattárban található.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Tegyük fel, hogy rendelkezik egy YAML-folyamatsal, amely kibővíti FabrikamFiberezt a sablont, amely az adattárban található. A mai napig nem lehetett dinamikusan megadni az ref templates adattár-erőforrás tulajdonságát, amikor sablonforrásként használja az adattárat. Ez azt jelentette, hogy módosítania kellett a folyamat kódját, ha azt szeretné, hogy a folyamat: egy sablon kiterjesztése egy másik ágból a folyamat nevével megegyező ágból, függetlenül attól, hogy melyik ágon futtatta a folyamatot

A sablonkifejezések adattárbeli erőforrásdefinícióban való bevezetésével a következő módon írhatja a folyamatot:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Ezzel a folyamat kiterjeszti a sablont ugyanabban az ágban, amelyen a folyamat fut, így meggyőződhet arról, hogy a folyamat és a sablon ágai mindig egyeznek. Vagyis ha a folyamatot egy ágon devfuttatja, az kibővíti az template.yml adattár ágában dev lévő fájl által megadott sablont templates .

Vagy a következő YAML-kód megírásával kiválaszthatja, hogy melyik sablontárfiókot használja a buildelési várakozási idő alatt.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Mostantól az ágon main lévő folyamat kiterjeszthet egy sablont egy ágból dev egy futtatás során, és kibővítheti a sablont egy másik futtatásban lévő ágból main anélkül, hogy módosítaná a folyamat kódját.

Amikor sablonkifejezést ad meg egy ref adattár-erőforrás tulajdonságához, használhat parameters és rendszer által előre definiált változókat, de YAML- vagy Pipelines felhasználói felület által definiált változókat nem használhat.

Sablonkifejezések a tárolóerőforrás-definícióban

Egy YAML-folyamat erőforrásának endpointoptions volumesportscontainer definiálásakor a sablonkifejezések támogatását is hozzáadtuk. Ez a fejlesztői közösség által erősen kért funkció volt.

Most az alábbihoz hasonló YAML-folyamatokat írhat.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Használhatja és variables. használhatja parameters. a sablonkifejezéseket. Változók esetén csak a YAML-fájlban definiáltakat használhatja, a Pipelines felhasználói felületén definiáltakat azonban nem. Ha újradefiniálja a változót, például ügynöknapló-parancsokat használ, annak nincs hatása.

A jóváhagyások változásainak naplózása

A jóváhagyásokkal szabályozhatja, hogy mikor fusson egy szakasz. Ezt gyakran használják az éles környezetekben történő üzembe helyezés szabályozására. A naplózás lehetővé teszi a megfelelőségi követelmények teljesítését és az Azure DevOps-szervezet biztonságának monitorozását.

Amikor egy felhasználónak jóvá kell hagynia egy folyamatot egy adott fázisban való üzembe helyezéshez, a felhasználó dönthet úgy, hogy a jóváhagyást valaki máshoz rendeli hozzá.

Eddig az ilyen műveleteket nem naplózták az auditnaplókban. Ez a probléma már ki lett javítva.

Az auditnaplók az alábbiakhoz hasonló bejegyzést tartalmaznak.

[
    {
        "Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
        "CorrelationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
        "ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUPN": "silviu@fabrikam.app",
        "AuthenticationMechanism": "AAD_Cookie",
        "Timestamp": "2022-10-10T11:26:53.7367453Z",
        "ScopeType": "Organization",
        "ScopeDisplayName": "Fabrikam (Organization)",
        "ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
        "ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
        "ProjectName": "FabrikamFiber",
        "IpAddress": "127.0.0.1",
        "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
        "ActionId": "ApproverReassigned",
        "Data": {
            "ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
            "OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
            "OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
            "NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
            "NewApproverDisplayName": "Jack Fabrikam",
            "Comment": "All admins are OOO"
        },
        "Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
        "Area": "Checks",
        "Category": "Modify",
        "CategoryDisplayName": "Modify",
        "ActorDisplayName": "Silviu"
    }
]

Emellett megjelenik az Audit felhasználói felületén is.

A feladattár elérhetővé teszi az ügynök üzemeltetési modelljét

Azok a feladatszerzők, amelyek meg szeretnék állapítani, hogy egy ügynök a Microsoft által üzemeltetett készletekben fut-e, vagy nem, most már nem használhatják a Feladattár függvényt getAgentMode() az üzemeltetési modell meghatározásához. Ez olyan helyzetekben hasznos, amikor egy feladat az ügyfél hálózatához való hozzáférésen alapulva szeretné befolyásolni a viselkedést. Egy feladat megpróbálhat elérni egy Azure-szolgáltatást egy privát végponton keresztül, ha egy saját üzemeltetésű ügynökből vagy egy ügyfél hálózatában található méretezési csoport ügynökéből hajtják végre. Lásd a tevékenységhivatkozást.

Következő lépések

Feljegyzés

Ezek a funkciók a következő két-három hétben jelennek meg.

Lépjen az Azure DevOpsba, és nézze meg.

Ugrás az Azure DevOpsra

Visszajelzés küldése

Szeretnénk hallani, mit gondol ezekről a funkciókról. A súgómenüvel jelentheti a problémát, vagy javaslatot adhat.

Tanácsokat és kérdéseket is kaphat a közösség által a Stack Overflow-on.

Köszönettel:

Vijay Machiraju