Az Azure DevOps Server 2022 1. frissítésének kibocsátási megjegyzései

---

| Fejlesztői közösség | rendszerkövetelményei és kompatibilitási | Licencfeltételek | DevOps Blog | SHA-256 Kivonatok |

---

Ebben a cikkben az Azure DevOps Server legújabb kiadásával kapcsolatos információkat talál.

Az Azure DevOps Server telepítésének telepítésével vagy frissítésével kapcsolatos további információkért tekintse meg Az Azure DevOps Server követelményei.

Az Azure DevOps Server-termékek letöltéséhez látogasson el az Azure DevOps Server Letöltések lapjára.

Az Azure DevOps Server 2022 Update 1 közvetlen frissítése az Azure DevOps Server 2019 vagy a Team Foundation Server 2015 vagy újabb verziójából támogatott. Ha a TFS üzembe helyezése a TFS 2013-ban vagy korábbi verzióban történik, az Azure DevOps Server 2022-re való frissítés előtt végre kell hajtania néhány időközi lépést. További információért tekintse meg a Telepítés lap.

---

Azure DevOps Server 2022 Update 1 Patch 4 Kiadás dátuma: 2024. június 11.

Fájl	SHA-256 kivonat
devops2022.1patch4.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Megjelent a Patch 4 for Azure DevOps Server 2022 Update 1, amely az alábbi javításokat tartalmazza.

• Kijavítottunk egy hibát a wikiben és a munkaelemekben, amelyekben a keresési eredmények nem voltak elérhetők olyan projektek esetében, amelyek nevében török "I" szerepel a török területi beállításhoz.

Azure DevOps Server 2022 Update 1 Patch 3 Kiadás dátuma: 2024. március 12.

Fájl	SHA-256 kivonat
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Megjelent a Patch 3 for Azure DevOps Server 2022 Update 1, amely az alábbi javításokat tartalmazza.

• Megoldotta azt a hibát, amely miatt a proxykiszolgáló a 2. javítás telepítése után leállt.
• Kijavítottunk egy megjelenítési hibát a bővítmény részleteinek lapján, amely nem angol nyelvű nyelveket érintett.

Azure DevOps Server 2022 Update 1 Patch 2 Kiadás dátuma: 2024. február 13.

Fájl	SHA-256 kivonat
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Megjelent a Patch 2 for Azure DevOps Server 2022 Update 1, amely az alábbi javításokat tartalmazza.

• A részletek lapmegjelenítési problémájának javítása a Keresési bővítményben.
• Kijavítottunk egy hibát, amely miatt a proxygyorsítótár-mappa által használt lemezterületet helytelenül számították ki, és a mappa nem lett megfelelően megtisztítva.
• CVE-2024-20667: Az Azure DevOps Server távoli kódvégrehajtási biztonsági rése.

Azure DevOps Server 2022 Update 1 Patch 1 Kiadás dátuma: 2023. december 12.

Fájl	SHA-256 kivonat
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Megjelent az Azure DevOps Server 2022 1. frissítésének 1. patchje , amely az alábbi javításokat tartalmazza.

• Megakadályozza a requested for beállítását, amikor egy folyamatfuttatás sorba áll.

Az Azure DevOps Server 2022 1. frissítésének kiadási dátuma: 2023. november 28.

Megjegyzés:

A kiadással két ismert probléma van:

1. Az Ügynök verziója nem frissül az Azure DevOps Server 2022.1-re való frissítés és az Ügynökkészlet konfigurációjában az Update Agent használata után. Jelenleg egy javításon dolgozunk a probléma megoldásán, és a fejlesztés során megosztjuk a frissítéseket a fejlesztői közösségben. Közben talál egy kerülő megoldást a problémára ebben a fejlesztői közösségi bejegyzésben.
2. Maven 3.9.x kompatibilitás. A Maven 3.9.x kompatibilitástörő változásokat vezetett be az Azure Artifactsben az alapértelmezett Maven Resolver-átvitel natív HTTP-hez való frissítésével a Wagonból. Ez 401 hitelesítési problémát okoz a https helyett http-t használó ügyfelek számára. Erről a problémáról itt talál további információt. Kerülő megoldásként továbbra is használhatja a Maven 3.9.x-et a tulajdonsággal -Dmaven.resolver.transport=wagon. Ez a változás kényszeríti a Mavent a Wagon Resolver Transport használatára. További részletekért tekintse meg a dokumentációt .

Az Azure DevOps Server 2022.1 hibajavítások összesítője. A korábban kiadott Azure DevOps Server 2022.1 RC2 összes funkcióját tartalmazza.

Megjegyzés:

Ismert probléma merült fel a Maven 3.9.x kompatibilitásával kapcsolatban. A Maven 3.9.x kompatibilitástörő változásokat vezetett be az Azure Artifactsben az alapértelmezett Maven Resolver-átvitel natív HTTP-hez való frissítésével a Wagonból. Ez 401 hitelesítési problémát okoz a https helyett http-t használó ügyfelek számára. Erről a problémáról itt talál további információt.

Kerülő megoldásként továbbra is használhatja a Maven 3.9.x-et a tulajdonsággal -Dmaven.resolver.transport=wagon. Ez a változás kényszeríti a Mavent a Wagon Resolver Transport használatára. További részletekért tekintse meg a dokumentációt .

Azure DevOps Server 2022 Update 1 RC2 Kiadás dátuma: 2023. október 31.

Az Azure DevOps Server 2022.1 RC2 hibajavítások összesítője. A korábban kiadott Azure DevOps Server 2022.1 RC1 összes funkcióját tartalmazza.

Megjegyzés:

Ismert probléma merült fel a Maven 3.9.x kompatibilitásával kapcsolatban. A Maven 3.9.x kompatibilitástörő változásokat vezetett be az Azure Artifactsben az alapértelmezett Maven Resolver-átvitel natív HTTP-hez való frissítésével a Wagonból. Ez 401 hitelesítési problémát okoz a https helyett http-t használó ügyfelek számára. Erről a problémáról itt talál további információt.

Kerülő megoldásként továbbra is használhatja a Maven 3.9.x-et a tulajdonsággal -Dmaven.resolver.transport=wagon. Ez a változás kényszeríti a Mavent a Wagon Resolver Transport használatára. További részletekért tekintse meg a dokumentációt .

Ezzel a kiadással a következő javítások lettek javítva:

• Kijavítottunk egy hibát a helyi hírcsatornákban, ahol a felsőbb rétegbeli bejegyzések nem oldották meg a megjelenítendő név módosításait.
• Váratlan hiba történt, amikor lapokat váltott a Kód lapról a Keresési lap egy másik lapjára.
• Hiba történt egy új munkaelemtípus létrehozásakor kínai, japán és koreai (CJK) egyesített ideográfokkal. Kérdőjel jelenik meg a RAW-naplóban a kapus bejelentkezéskor, amikor a csapatprojekt neve vagy fájljai CJK-t tartalmaztak.
• Kijavítottunk egy hibát a Keresés telepítése során, amely miatt a Java virtuális gép (JVM) nem tudott elegendő memóriát lefoglalni az Elastic Search-folyamathoz. A keresési konfigurációs widget mostantól az Elastic Search szolgáltatással csomagba csomagolt Java Development Kit (JDK) szolgáltatást használja, így eltávolítja a célkiszolgálón előre telepített Java Runtime Environment (JRE) függőségét.

Azure DevOps Server 2022 Update 1 RC1 Kiadás dátuma: 2023. szeptember 19.

Az Azure DevOps Server 2022.1 RC1 számos új funkciót tartalmaz. Néhány fontos elem:

• Az összes nyilvános REST API támogatja a részletes PAT-hatóköröket
• Utolsó hozzáférés oszlop a Kézbesítési tervek lapon
• A kézbesítési csomagokhoz való összes függőség megjelenítése
• @CurrentIteration makró a szállítási tervekben
• A jelenlegi projekt alapértelmezett hatókörként van beállítva a klasszikus folyamatok buildelérési jogkivonatához
• Szülő megjelenítése a lekérdezési eredmények widgetben
• Irányítópult másolása
• További diagramtípusok támogatása wikilapokon
• A Container Registry szolgáltatáskapcsolatai mostantól használhatják az Azure Managed Identities-t

Az egyes szakaszokra ugorva megtekintheti az egyes szolgáltatások összes új funkcióját:

• Általános
• Táblák
• Repos
• Csővezetékek
• Műtárgyak
• Jelentéskészítés
• Wiki

---

Általános

Az összes nyilvános REST API támogatja a részletes PAT-hatóköröket

Korábban számos nyilvánosan dokumentált Azure DevOps REST API-t nem társítottak hatókörökhöz (például a munkaelem olvasásához), ami azt eredményezte, hogy az ügyfelek teljes hatókörrel használják ezeket az API-kat nem interaktív hitelesítési mechanizmusok, például személyes hozzáférési jogkivonatok (PAT) használatával. A teljes hatókörű személyes hozzáférési jogkivonat használata növeli a kockázatot, ha rosszindulatú felhasználó kezébe kerülnek. Ez az egyik fő oka annak, hogy sok ügyfelünk nem használja ki teljes mértékben a vezérlősík-szabályzatok előnyeit a PAT használatának és viselkedésének korlátozása érdekében.

Most már minden nyilvános Azure DevOps REST API hozzá van rendelve, és támogatja a részletes PAT-hatókört. Ha jelenleg teljes hatókörű PAT-t használ a nyilvános Azure DevOps REST API-k egyikének hitelesítéséhez, érdemes lehet áttelepíteni egy PAT-re a szükségtelen hozzáférés elkerülése érdekében az API által elfogadott adott hatókörrel. Az adott REST API támogatott részletes PAT-hatóköre(i) a dokumentációs oldalak Biztonsági szakaszában találhatók. Emellett itt található egy hatókör-táblázat is.

A bővítményeknek meg kell jeleníteniük a hatóköreiket

Az Azure DevOps-gyűjtemény bővítményeinek telepítésekor a telepítés részeként áttekintheti a bővítményhez szükséges engedélyeket. A telepítés után azonban a bővítményengedélyek nem jelennek meg a bővítménybeállításokban. Ez kihívást jelent a rendszergazdák számára, akik rendszeresen felül kell vizsgálniuk a telepített bővítményeket. Most hozzáadtuk a bővítménybeállítások bővítményengedélyeit, így áttekintheti és megalapozott döntést hozhat arról, hogy megtartja-e őket.

Táblák

Utolsó hozzáférés oszlop a Szállítási tervek lapon

A Szállítási tervek könyvtár oldalán található a projekthez definiált tervek listája. Rendezhet a következők alapján: Név, Létrehozó, Leírás, Utolsó konfigurálás vagy Kedvencek. Ezzel a frissítéssel hozzáadtunk egy Utolsó hozzáférésű oszlopot a címtároldalhoz. Ez betekintést nyújt a kézbesítési csomag legutóbbi megnyitásának és áttekintésének időpontjára. Ennek eredményeképpen könnyen azonosíthatók a már nem használt és törölhető tervek.

Minden függőség megjelenítése a szállítási terveken

A szállítási tervek mindig is lehetővé tették a munkaelemek közötti függőségek megtekintését. A függőségi sorokat egyenként is megjelenítheti. Ezzel a kiadással továbbfejlesztettük a felhasználói élményt azáltal, hogy lehetővé tettük a függőségi vonalak megtekintését a képernyőn látható összes munkaelem között. Egyszerűen kattintson a kézbesítési terv jobb felső sarkában található függőségek váltógombjára. Kattintson ismét a vonalak kikapcsolására.

Új munkaelem-felülvizsgálati korlátok

Az elmúlt néhány évben láthattuk, hogy az automatizált eszközökkel rendelkező projektgyűjtemények több tízezer munkaelem-változatot hoznak létre. Ez problémákat okoz a teljesítmény és a használhatóság szempontjából a munkaelem űrlapján és a jelentéskészítési REST API-kban. A probléma megoldásához bevezettünk egy 10 000-re vonatkozó munkaelem-változatkorlátot az Azure DevOps Service-re. A korlát csak a REST API-t használó frissítéseket érinti, a munkaeleműrlapot nem.

Ide kattintva többet tudhat meg a változatkorlátról, és arról, hogyan kezelheti azt az automatizált eszközökben.

A kézbesítési tervek csapat létszámkorlátjának növelése 15-ről 20-ra.

A Szállítási tervek segítségével több felhalmozott munkát és több csapatot tekinthet meg a projektkészletben. Korábban 15 csapat-hátralékot tekinthetett meg, köztük a különböző projektekből származó hátralékokat és csapatokat. Ezzel a kiadással 15-ről 20-ra növeltük a maximális korlátot.

Kijavítottuk a jelentéskészítési munkaelem-hivatkozások get API-jának hibáját

Kijavítottunk egy hibát a Jelentéskészítési munkaelem-hivatkozások lekérése API-ban, amely a hivatkozástípusok megfelelő System.LinkTypes.Remote.Related remoteUrl-értékét adja vissza. A javítás előtt nem a megfelelő projektcsoportnevet és egy hiányzó projektazonosítót adtunk vissza.

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 jól működik, kivéve ha nagy WIQL-utasítással rendelkezik, amely eléri a lekérdezési karakterlánc hosszára vonatkozó böngészőkorlátokat. 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 kapott azonosítót a lekérdezési karaktersoron 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.

Tömeges törlő API

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 munkaelemek kötegelt törlésére és/vagy megsemmisítésére.

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

Ezzel a frissítéssel hozzáadtuk a @CurrentIteration makró támogatását a stílusokhoz a Szállítási tervekben. Ez a makró lehetővé teszi az aktuális iteráció lekérését a terv egyes sorainak csapatkörnyezetéből.

Kártya átméretezési logika a Delivery Plans funkcióban

Nem mindenki használja a céldátumot és/vagy kezdő dátumot a funkciók és az Eposzok nyomon követésekor. Vannak, akik a dátumok és az iterációs útvonal kombinációját választják. Ebben a kiadásban továbbfejlesztettük a logikát, hogy a használatuk módjától függően megfelelően állítsa be az iterációs útvonalat és a dátummező kombinációit.

Ha például nem használja a céldátumot, és átméretezi a kártyát, a céldátum frissítése helyett az új iterációs útvonal lesz beállítva.

Kötegelt frissítések fejlesztései

Számos módosítást végeztünk a munkaelem-kötegfrissítési API 7.1-es verzióján. Ezek közé tartoznak a kisebb teljesítménybeli fejlesztések és a részleges hibák kezelése. Ez azt jelenti, hogy ha az egyik javítás sikertelen, a többi azonban nem, a többi sikeresen befejeződik.

Kattintson ide a REST API kötegelt frissítésével kapcsolatos további információkért.

Tömeges törlő API

Ez az új REST API-végpont a köteg munkaelemeinek törléséhez és/vagy megsemmisítéséhez nyilvánosan elérhető. További információért kattintson ide.

Megosztható listamezők szerkesztésének megakadályozása

Az egyéni mezők meg vannak osztva a folyamatok között. Ez problémát okozhat a listamezők esetében, mert lehetővé tesszük a folyamatgazdák számára, hogy értékeket vegyenek fel vagy távolíthassanak el a mezőből. Ha így tesz, a módosítások az azt használó összes folyamat mezőjére hatással lesznek.

A probléma megoldásához hozzáadtuk azt a lehetőséget, hogy a gyűjtemény rendszergazdája "zároljon" egy mezőt a szerkesztéstől. Ha a picklist mező zárolva van, a helyi folyamat rendszergazdája nem módosíthatja a lista értékeit. A mező csak a folyamatból vehető fel vagy távolítható el.

Új megjegyzések mentésének engedélye

A fejlesztői közösség egyik legfontosabb kérése, hogy csak a munkaelemek megjegyzéseit mentse. Örömmel tudatjuk, hogy bevezettük ezt a funkciót. Első lépésként tekintsük át a leggyakoribb forgatókönyvet:

"Meg szeretném akadályozni, hogy néhány felhasználó szerkessze a munkaelemmezőket, de lehetővé szeretném tenni számukra, hogy hozzájáruljanak a vitafórumhoz."

Ehhez a Projektbeállítások > projektkonfigurációs > terület elérési útjára kell lépnie. Ezután válassza ki a kívánt terület elérési útját, és kattintson a Biztonság gombra.

Figyelje meg a "Munkaelem-megjegyzések szerkesztése ezen a csomóponton" új engedélyt. Alapértelmezés szerint az engedély nincs beállítva. Ez azt jelenti, hogy a munkaelem ugyanúgy fog viselkedni, mint korábban. Ha engedélyezni szeretné egy csoport vagy felhasználó számára a megjegyzések mentését, jelölje ki a csoportot/felhasználókat, és módosítsa az Engedélyezés beállítást.

Amikor a felhasználó megnyitja a munkaelem-űrlapot ezen a területen, megjegyzéseket adhat hozzá, de nem tudja frissíteni a többi mezőt.

Reméljük, hogy annyira szereted ezt a funkciót, mint mi. Mint mindig, ha bármilyen visszajelzése vagy javaslata van, kérjük, tudassa velünk.

Interaktív táblák riportjai

A Boards Hubban található interaktív jelentések már évek óta elérhetők a termék üzemeltetett verziójában. A korábbi halmozott folyamat diagram, sebesség diagram és sprint kifutási diagramok helyébe lépnek. Ezzel a kiadással elérhetővé tesszük őket.

A diagramok megtekintéséhez kattintson az Elemzés lap helyére a Kanban Board, a Backlog és a Sprints lapon.

Repos

A "Szabályzatok szerkesztése" engedély eltávolítása az ág létrehozója számára

Korábban, amikor létrehozott egy új ágat, engedélyt kaptunk a szabályzatok szerkesztésére az adott ágon. Ezzel a frissítéssel megváltoztatjuk az alapértelmezett viselkedést, hogy ne adja meg ezt az engedélyt még akkor sem, ha az "Engedélykezelés" beállítás be van kapcsolva az adattárban.

A "Szabályzatok szerkesztése" engedélyt explicit módon kell megkapnia, amelyet manuálisan vagy a REST API-n keresztül állítanak be, biztonsági engedélyörökléssel vagy csoporttagság útján.

Csővezetékek

A jelenlegi projekt alapértelmezett jogosultsági körként van beállítva a klasszikus folyamatokhoz tartozó buildelérési token számára.

Az Azure Pipelines feladat-hozzáférési jogkivonatokkal fér hozzá az Azure DevOps egyéb erőforrásaihoz futásidőben. A feladat-hozzáférési jogkivonatok olyan biztonsági jogkivonatok, amelyeket az Azure Pipelines dinamikusan hoz létre minden feladathoz futásidőben. Korábban egy új klasszikus folyamat létrehozásakor a hozzáférési jogkivonat alapértelmezett értéke Project Collection volt. Ezzel a frissítéssel a feladat-engedélyezési hatókört az aktuális projektre állítjuk be alapértelmezettként egy új klasszikus folyamat létrehozásakor.

A feladat-hozzáférési jogkivonatokkal kapcsolatos további részleteket az Access-adattárakban, összetevőkben és egyéb erőforrások dokumentációjában talál.

A hozzáférési jogkivonatok alapértelmezett hatókörének módosítása a klasszikus buildelési folyamatokban

A klasszikus buildelési folyamatok biztonságának javítása érdekében egy új létrehozásakor a buildelési feladat engedélyezési hatóköre alapértelmezés szerint a Project lesz. Eddig projektgyűjtemény volt. További információ a feladat-hozzáférési jogkivonatokról. Ez a módosítás nem érinti a meglévő adatcsatornákat. Ez csak az ebből a pontból létrehozott új klasszikus buildelési folyamatokat érinti.

A ServiceNow San Diego, Tokió és Utah kiadásainak támogatása az Azure Pipelines részéről

Az Azure Pipelines meglévő integrációval rendelkezik a ServiceNow szolgáltatással. Az integráció egy ServiceNow-alkalmazásra és egy Azure DevOps-bővítményre támaszkodik. Most frissítettük az alkalmazást, hogy működjön együtt a ServiceNow San Diego, Tokyo & Utah verzióival. Az integráció működésének biztosítása érdekében frissítsen az alkalmazás új verziójára (4.215.2) a ServiceNow áruházból.

További információkért tekintse meg az Integrálás a ServiceNow Change Management szolgáltatással című dokumentációt.

Proxy URL-címek használata a GitHub Enterprise-integrációhoz

Az Azure Pipelines integrálható a helyszíni GitHub Enterprise-kiszolgálókkal a folyamatos integráció és a PR-buildek futtatásához. Bizonyos esetekben a GitHub Enterprise Server tűzfal mögött található, és megköveteli, hogy a forgalmat proxykiszolgálón keresztül irányítsa. Ennek a forgatókönyvnek a támogatásához az Azure DevOps GitHub Enterprise Server szolgáltatáskapcsolatai lehetővé teszi proxy URL-címének konfigurálását. Korábban nem az Azure DevOps teljes forgalmát irányították át ezen a proxy URL-címen. Ezzel a frissítéssel biztosítjuk, hogy a következő forgalmat irányítsuk az Azure Pipelinesből, hogy a proxy URL-címen keresztül haladjon.

• Szerezz ágakat
• Lekéréses kérelem adatainak lekérése
• Jelentés összeállítási állapota

A tárolóregisztrációs szolgáltatás kapcsolatai mostantól használhatják az Azure Managed Identityes szolgáltatást

Rendszer által hozzárendelt felügyelt identitást használhat Docker Registry-szolgáltatáskapcsolatok azure Container Registry-hez való létrehozásakor. Ez lehetővé teszi az Azure Container Registry elérését egy saját üzemeltetésű Azure Pipelines-ügynökhöz társított felügyelt identitással, így szükségtelenné teszi a hitelesítő adatok kezelését.

Megjegyzés:

Az Azure Container Registry eléréséhez használt felügyelt identitásnak szüksége lesz a megfelelő Azure-szerepköralapú hozzáférés-vezérlési (RBAC) hozzárendelésre, például AcrPull vagy AcrPush szerepkörre.

A Kubernetes szolgáltatáskapcsolathoz automatikusan létrehozott jogkivonatok

A Kubernetes 1.24 óta a tokenek már nem jönnek létre automatikusan új Kubernetes szervizkapcsolat létrehozásakor. Ezt a funkciót újból hozzáadtuk. Az AKS elérésekor azonban ajánlott az Azure Service-kapcsolatot használni, ha többet szeretne megtudni a Kubernetes-feladatokat használó AKS-ügyfelek szolgáltatáskapcsolati útmutatóiról.

A Kubernetes-feladatok mostantól támogatják a kubelogin használatát

Frissítettük az KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 és AzureFunctionOnKubernetes@1 feladatokat a kubelogin támogatásához. Ez lehetővé teszi az Azure Active Directory-integrációval konfigurált Azure Kubernetes Service (AKS) megcélzását.

A Kubelogin nincs előre telepítve a üzemeltetett rendszerképeken. Ha meg szeretné győződni arról, hogy a fent említett tevékenységek kubelogint használnak, telepítse a KubeloginInstaller@0 feladatot az attól függő tevékenység elé:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Javítások a csővezetékek engedélyezésében

Továbbfejlesztettük a folyamatengedélyek kezelésével kapcsolatos felhasználói élményt, hogy az engedélyrendszer ne feledje, hogy egy folyamat korábban védett erőforrást, például szolgáltatáskapcsolatot használt-e.

Korábban, ha a védett erőforrás létrehozásakor kikapcsolta a "Hozzáférési engedély megadása az összes folyamat számára" jelölőnégyzetet, de korlátozta az erőforráshoz való hozzáférést, a folyamatnak új engedélyre volt szüksége az erőforrás használatához. Ez a viselkedés inkonzisztens volt az erőforrás későbbi megnyitásával és bezárásával, ahol nem volt szükség új engedélyezésre. Ezt a hibát kijavítottuk.

Új PAT-hatókör a folyamatok engedélyezésének, jóváhagyásának és ellenőrzésének kezeléséhez

A PAT-jogkivonat kiszivárgásával okozott károk csökkentése érdekében hozzáadtunk egy új PAT-hatókört, amely neve Pipeline Resources. Ezt a PAT-hatókört akkor használhatja, ha védett erőforrással, például szolgáltatáskapcsolattal kezeli a folyamat-engedélyezést, vagy kezeli a jóváhagyásokat és ellenőrzi az adott erőforrást.

Az alábbi REST API-hívások az alábbi módon támogatják az új PAT-hatókört:

• Jóváhagyás frissítése támogatja a hatókört Pipeline Resources Use
• Az Ellenőrzések kezelése támogatja a hatókört Pipeline Resources Use and Manage
• Az erőforrások folyamatengedélyeinek frissítése támogatja a hatókört Pipeline Resources Use and Manage
• A definícióerőforrások engedélyezése támogatja a hatókört Pipeline Resources Use and Manage
• A Projekterőforrások engedélyezése támogatja a hatókört Pipeline Resources Use and Manage

Védett erőforrások megnyitásának korlátozása az erőforrás-rendszergazdák számára

Az alkalmazások biztonságos kiépítéséhez és üzembe helyezéséhez kritikus fontosságú erőforrások biztonságának javítása érdekében az Azure Pipelines most erőforrástípus-rendszergazdai szerepkört igényel az erőforrásokhoz való hozzáférés minden folyamathoz való megnyitásakor.

Általános szolgáltatáskapcsolat-rendszergazdai szerepkörre van szükség például ahhoz, hogy bármely folyamat használhasson szolgáltatáskapcsolatot. Ez a korlátozás védett erőforrás létrehozásakor vagy biztonsági konfigurációjának szerkesztésekor érvényes.

Emellett, ha szolgáltatáskapcsolat létrehozásakor nem rendelkezik megfelelő jogosultságokkal, a hozzáférési engedély megadása az összes folyamat számára le van tiltva.

Ha egy meglévő erőforráshoz próbál hozzáférést nyitni, és nem rendelkezik megfelelő jogosultságokkal, egy Nincs jogosultsága az erőforrás eléréséhez üzenetet kap.

Folyamatok REST API biztonsági fejlesztései

Az Azure DevOps REST API-jainak többsége hatókörrel tagolt PAT-jogkivonatokat használ. Néhányuk azonban teljes hatókörű PAT-jogkivonatokat igényel. Más szóval, létre kell hoznia egy PAT-jogkivonatot a "Teljes hozzáférés" kiválasztásával ezeknek az API-knak a használatához. Az ilyen jogkivonatok biztonsági kockázatot jelentenek, mivel bármilyen REST API meghívására használhatók. Az Azure DevOpsban olyan fejlesztéseket végeztünk, amelyek célja az, hogy az egyes REST API-kat egy adott hatókörbe beépítve megszüntessük a teljes hatókörű jogkivonatok szükségességét. Ennek részeként az erőforrás folyamatengedélyeinek frissítésére szolgáló REST API-nak most egy adott hatókörre van szüksége. A hatókör a használatra engedélyezett erőforrás típusától függ:

• Code (read, write, and manage) típusú erőforrások esetén repository
• Agent Pools (read, manage) vagy Environment (read, manage) típusú erőforrásokhoz, például queue és agentpool
• Secure Files (read, create, and manage) típusú erőforrások esetén securefile
• Variable Groups (read, create and manage) típusú erőforrások esetén variablegroup
• Service Endpoints (read, query and manage) típusú erőforrások esetén endpoint
• Environment (read, manage) típusú erőforrások esetén environment

A csővezetékek engedélyeinek tömeges szerkesztéséhez továbbra is teljes körű PAT-jogkivonatra lesz szüksége. Az erőforrások folyamatengedélyeinek frissítéséről további információt a Folyamatengedélyek – Folyamatengedélyek frissítése az erőforrásokhoz című dokumentációban talál.

Az ügynökkészletek részletes hozzáférés-kezelése

Az ügynökkészletek lehetővé teszik azoknak a gépeknek a megadását és kezelését, amelyeken a pipeline-ek futnak.

Korábban, ha egyéni ügynökkészletet használt, a hozzáférhetővé tett pipeline-ok kezelése korlátozott mértékű volt. Engedélyezheti az összes folyamat számára a használatát, vagy megkövetelheti, hogy minden folyamat engedélyt kérjen. Sajnos, miután megadta a pipeline hozzáférési engedélyt egy ügynökkészletnek, nem tudta visszavonni azt a pipeline felhasználói felületén keresztül.

Az Azure Pipelines mostantól részletes hozzáférés-kezelést biztosít az ügynökkészletekhez. A szolgáltatáskapcsolatok folyamatengedélyeinek kezelése hasonló a felhasználói élményhez.

Megakadályozza, hogy minden csővezeték hozzáférjen védett erőforrásokhoz

Védett erőforrás, például szolgáltatáskapcsolat vagy környezet létrehozásakor bejelölheti a Hozzáférési engedély megadása az összes csővezetékhez jelölőnégyzetet. Eddig ez a beállítás alapértelmezés szerint be volt jelölve.

Bár ez megkönnyíti a folyamatok számára az új védett erőforrások használatát, a fordítottja az, hogy véletlenül túl sok folyamat számára biztosít hozzáférést az erőforráshoz.

A biztonságos alapértelmezett választás előmozdítása érdekében az Azure DevOps mostantól üresen hagyja a jelölőnégyzetet.

A rövid titkos kódok maszkolásának letiltása

Az Azure Pipelines elrejti a naplók titkos kulcsait. A titkos kulcsok lehetnek titkosként megjelölt változók, az Azure Key Vaulthoz csatolt változócsoportok változói vagy a szolgáltatáskapcsolat-szolgáltató által titkosként megjelölt szolgáltatáskapcsolat elemei.

A titkos érték minden előfordulása elrejtve. Rövid titkok (pl. '1', '2', 'Dev') maszkolása megkönnyíti az értékek kitalálását, például egy dátumban: 'Jan 3, 202***'
Most már világos, hogy "3" egy titok. Ilyen esetekben előfordulhat, hogy inkább nem maszkolja a titkos kódot. Ha nem lehet titkosként megjelölni az értéket (például az érték a Key Vaultból származik), a gombot legfeljebb 4 értékre állíthatja AZP_IGNORE_SECRETS_SHORTER_THAN .

Node futtató letöltési feladat

Amikor olyan ügynökkiadásokat vezet be, amelyek kizárják a Node 6 feladatfuttatót , előfordulhat, hogy időnként olyan feladatokat kell futtatnia, amelyeket nem frissítettek egy újabb csomópontfuttató használatához. Ebben a forgatókönyvben megadunk egy módszert arra, hogy továbbra is használhassuk a Node életciklusának vége felé járó futóktól függő feladatokat. Lásd a Node-futók útmutatójának blogbejegyzését.

Az alábbi feladat a Node 6 futó igény szerint történő telepítéséhez használható módszer, így egy régi feladat továbbra is végrehajtható:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Frissített TFX-csomóponthajtó ellenőrzése

A feladatszerzők a bővítmények közzétételéhez a bővítménycsomagoló eszközt (TFX) használják. A TFX frissült, hogy validálja a Node runner verzióit, lásd a blogbejegyzést a Node runner útmutatójában.

A Node 6 futót használó tevékenységeket tartalmazó bővítmények a következő figyelmeztetést fogják látni:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Utasítások a 6. csomópont manuális előzetes telepítéséhez a folyamatügynökökön

Ha az ügynökcsatornátpipeline- használja, az ügynök nem tartalmazza a Node 6-ot. Bizonyos esetekben, amikor egy piactéri feladat még mindig a Node 6-tól függ, és az ügynök nem tudja használni a NodeTaskRunnerInstaller feladatot (például a kapcsolati korlátozások miatt), Önnek a Node 6-ot független módon elő kell telepítenie. Ehhez tekintse meg a Node 6 futtatókörnyezet manuális telepítésére vonatkozó utasításokat.

Folyamattevékenység változásnaplója

A folyamatfeladatok módosításait ebben a változásnaplóban tesszük közzé. Tartalmazza a beépített folyamatfeladatok módosításainak teljes listáját. Visszamenőlegesen közzétettük a korábbi módosításokat, így a változásnapló a feladatfrissítések előzményeit is biztosítja.

A kiadási feladatok a Microsoft Graph API-t használják

Frissítettük a kiadási feladatokat a Microsoft Graph API használatára. Ez eltávolítja az AAD Graph API használatát a tevékenységeinkből.

A Windows PowerShell-feladat teljesítményének javítása

Tevékenységek használatával definiálhat automatizálást a folyamatokban. Az egyik ilyen feladat az a PowerShell@2 segédprogram-feladat, amely lehetővé teszi PowerShell-szkriptek végrehajtását a folyamatban. Ha PowerShell-szkriptet szeretne használni egy Azure-környezet megcélzásához, használhatja a AzurePowerShell@5 feladatot. Néhány PowerShell-parancs, amely képes például az állapotfrissítések nyomtatására Invoke-WebRequest, most már gyorsabban hajthatók végre. A fejlesztés akkor lényegesebb, ha sok ilyen parancs található a szkriptben, vagy ha hosszú ideig futnak. Ezzel a frissítéssel a progressPreference és PowerShell@2 feladatok tulajdonsága alapértelmezés szerint AzurePowerShell@5 be van állítva.

Pipelines Agent v3 on .NET 6

A Pipeline ügynök frissítve lett, hogy futtatókörnyezetként a .NET 3.1 Core helyett a .NET 6-ot használja. Ez bevezeti az Apple Silicon és a Windows Arm64 natív támogatását.

A .NET 6 használata hatással van az ügynök rendszerkövetelményeire. Pontosabban a következő operációs rendszerek támogatását csökkentjük: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Tekintse meg az Ügynök szoftver 3-ik verziójának dokumentációját.

Ez a szkript olyan folyamatok azonosítására használható, amelyek nem támogatott operációs rendszerekkel rendelkező ügynököket használnak.

Fontos

Vegye figyelembe, hogy a .NET 6-alapú ügynök üzembe helyezése után a fenti operációs rendszerek bármelyikén futó ügynökök többé nem frissülnek vagy sikertelenek lesznek.

Ügynökverzió megadása az Ügynök virtuálisgép-bővítményben

Az Azure-beli virtuális gépek egy virtuálisgép-bővítmény használatával bekerülhetnek az üzembehelyezési csoportokba. A virtuálisgép-bővítmény frissítve lett, hogy opcionálisan megadják a telepíteni kívánt ügynökverziót:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Új kapcsolók a klasszikus pipeline-ok létrehozásának szabályozására

Az Azure DevOps mostantól lehetővé teszi, hogy a projektgyűjtemény csak YAML-folyamatokat használjon a klasszikus buildelési folyamatok, a klasszikus kiadási folyamatok, a feladatcsoportok és az üzembehelyezési csoportok létrehozásának letiltásával. A meglévő klasszikus folyamatok továbbra is futnak, és szerkesztheti őket, de nem hozhat létre újakat.

Az Azure DevOps mostantól lehetővé teszi, hogy szervezete csak YAML-folyamatokat használjon a klasszikus buildfolyamatok, a klasszikus kiadási folyamatok, a feladatcsoportok és az üzembehelyezési csoportok létrehozásának letiltásával. A meglévő klasszikus folyamatok továbbra is futnak, és szerkesztheti őket, de nem hozhat létre újakat.

A megfelelő kapcsolók bekapcsolásával letilthatja a klasszikus folyamatok létrehozását projektgyűjteményi vagy projektszintű szinten. A kapcsolók a Project / Project Settings -> Pipelines -> Settings területen találhatók. Két kapcsoló van: egy a klasszikus buildfolyamatokhoz , egy pedig a klasszikus kiadási folyamatokhoz, az üzembehelyezési csoportokhoz és a tevékenységcsoportokhoz.

A kapcsoló állapota alapértelmezés szerint ki van kapcsolva, és rendszergazdai jogosultságokra lesz szüksége az állapot módosításához. Ha a kapcsoló szervezeti szinten van bekapcsolva, a letiltás minden projekt esetében kötelező lesz. Ellenkező esetben minden projekt szabadon eldöntheti, hogy kényszeríti-e vagy sem a letiltást.

A klasszikus folyamatok létrehozásának letiltásakor a klasszikus folyamatok, feladatcsoportok és üzembehelyezési csoportok létrehozásával kapcsolatos REST API-k sikertelenek lesznek. A YAML-folyamatokat létrehozó REST API-k működni fognak.

"Futási szakaszállapot változott" szolgáltatáshook-esemény frissítései

A szolgáltatáshookok lehetővé teszik a feladatok más szolgáltatásokon való futtatását, amikor események történnek a projektben az Azure DevOpsban, a futtatási fázis állapota módosult . A futtatási szakasz állapotváltozásának eseményének tartalmaznia kell a futtatás adatait, beleértve a csővezeték nevét is. Korábban csak a futtatás azonosítójával és nevével kapcsolatos információkat tartalmazott. Ezzel a frissítéssel módosítottuk az eseményt, hogy tartalmazza a hiányzó információkat.

Szolgáltatáshorog a munka állapotváltozásához

A szolgáltatáshookok lehetővé teszik, hogy reagáljon a folyamatfuttatások állapotváltozásával kapcsolatos eseményekre. Mostanáig konfigurálhatott szolgáltatásihorgot a folyamat futási és a fázisállapot változásaihoz.

Mostantól konfigurálhatja azokat a szolgáltatáshogokat, amelyek akkor aktiválnak, amikor a folyamat egy feladatának állapota megváltozik. Az új esemény adatstruktúrája az alábbi példában látható.

{
    "subscriptionId": "8d91ad83-1db5-4d43-8c5a-9bb2239644b1",
    "notificationId": 29,
    "id": "fcad4962-f3a6-4fbf-9653-2058c304503f",
    "eventType": "ms.vss-pipelines.job-state-changed-event",
    "publisherId": "pipelines",
    "message":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "detailedMessage":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "resource":
    {
        "job":
        {
            "_links":
            {
                "web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088"
                },
                "pipeline.web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/definition?definitionId=4647"
                }
            },
            "id": "e87e3d16-29b0-5003-7d86-82b704b96244",
            "name": "Compile",
            "state": "completed",
            "result": "succeeded",
            "startTime": "2022-11-21T16:10:28.49Z",
            "finishTime": "2022-11-21T16:10:53.66Z"
        },
        "stage": { ... },
        "run": { ... },
        "pipeline": { ... },
        "repositories": [ ... ]
    },
    "resourceVersion": "5.1-preview.1",
    "createdDate": "2022-11-21T16:11:02.9207334Z"
}

A futtatási, fázis- és munkafolyamat-állapot-változási szolgáltatáshook-események mostantól tartalmaznak egy repository tulajdonságot, amely felsorolja azokat az Azure-adattárakat, amelyeket a csővezeték futtatása felhasznál. Például:

"repositories":
[
    {
        "type": "Git",
        "change":
        {
            "author":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "committer":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "message": "Added Viva support"
        },
        "url": "https://fabrikamfiber@dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_git/fabrikamfiber"
    }
]

A pipeline futtatásának utolsó commit üzenetének megjelenítésének letiltása

Korábban a Pipelines felhasználói felülete az utolsó véglegesítési üzenetet jeleníti meg egy folyamat futtatásakor.

Ez az üzenet zavaró lehet például, ha a YAML-folyamat kódja egy olyan adattárban található, amely eltér az általa létrehozott kódtól. Hallottuk a fejlesztői közösség visszajelzését, amely arra kért minket, hogy engedélyezzük/tiltsuk le a legújabb véglegesítési üzenet hozzáfűzését minden folyamatfuttatás címéhez.

Ezzel a frissítéssel hozzáadtunk egy új YAML-tulajdonságot, amelynek a neve appendCommitMessageToRunNamepontosan ezt teszi lehetővé. A tulajdonság alapértelmezés szerint a következőre truevan állítva: . Ha ezt falseállítja be, a folyamatfuttatás csak a BuildNumber.

Megnövelt Azure Pipeline-korlátok, hogy igazodjanak a 4 MB-os maximális Azure Resource Manager-sablonmérethez.

Az Azure-infrastruktúra létrehozásához használhatja az Azure Resource Manager-sablon üzembe helyezési feladatát. Visszajelzésére válaszul 2 MB-ról 4 MB-ra növeltük az Azure Pipelines integrációs korlátját. Ez igazodik az ARM-sablonokhoz, maximális mérete 4 MB, a méretkorlátozások feloldása a nagy sablonok integrálása során.

Csővezeték futtatás állapotának ikonja

Ezzel a kiadással egyszerűbbé tesszük a folyamatfuttatások általános állapotának megismerését.

A sok fázissal rendelkező YAML-folyamatok esetében korábban nehéz volt ismerni a folyamatfuttatás állapotát, vagyis még mindig fut vagy befejeződött. És ha befejeződött, mi a teljes állapot: sikeres, sikertelen vagy megszakított. Ezt a problémát egy futtatási állapot áttekintési ikon hozzáadásával javítottuk.

Folyamatszakaszok oldalpanelje

A YAML-folyamatok több tíz fázisból állhatnak, és nem mindegyik fog elférni a képernyőn. Bár a folyamatfuttatás áttekintési ikonja a futtatás általános állapotát jelzi, még mindig nehéz megállapítani, hogy melyik szakasz meghiúsult, vagy hogy melyik szakasz fut még mindig, például.

Ebben a kiadásban hozzáadtunk egy folyamatszakaszok oldalpanelt, amely lehetővé teszi az összes fázis állapotának gyors megtekintését. Ezután rákattinthat egy szakaszra, és közvetlenül a naplóihoz juthat.

Szakaszok keresése az oldalpanelen

Egyszerűbbé tettük a kívánt szakaszok megkeresését a szakaszok oldalpaneljén. Mostantól gyorsan szűrhet a szakaszokra az állapotuk alapján, például futó vagy manuális beavatkozást igénylő szakaszokra. A szakaszokat a nevük alapján is megkeresheti.

Gyorsműveletek előkészítése

A folyamatok Futtatások képernyője gyors hozzáférést biztosít az összes futtatási fázishoz. Ebben a kiadásban hozzáadtunk egy szakaszpanelt, ahol műveleteket hajthat végre az egyes szakaszokhoz. Például egyszerűen újrafuttathatja a sikertelen feladatokat, vagy újrafuttathatja a teljes szakaszt. A panel akkor érhető el, ha nem minden fázis fér el a felhasználói felületen, ahogy az alábbi képernyőképen látható.

Amikor a "+" jelre kattint a fázisok oszlopban, megjelenik a fázisok panel, majd végrehajthat szakaszműveleteket.

Felhasználói élmény fejlesztéseinek ellenőrzése

Egyszerűbbé tesszük az ellenőrzési naplók olvasását. Az ellenőrzési naplók kritikus fontosságú információkat nyújtanak az üzembe helyezés sikerességéhez. Megállapíthatják, hogy elfelejtette-e bezárni a munkaelem-jegyet, vagy frissítenie kell egy jegyet a ServiceNow-ban. Korábban nehéz volt tudni, hogy egy ellenőrzés ilyen kritikus információkat adott meg.

A folyamatfuttatás részleteinek lapja most a legújabb ellenőrzési naplót jeleníti meg. Ez csak az ajánlott használatot követő ellenőrzésekre vonatkozik.

A tévesen jóváhagyott jóváhagyások megakadályozása érdekében az Azure DevOps megjeleníti a jóváhagyóknak szóló utasításokat a Jóváhagyások lapon, és ellenőrzi az oldalpanelt egy folyamatfuttatás részletes lapján.

Ellenőrzés letiltása

A hibakeresési ellenőrzések kevésbé unalmasak. Előfordulhat, hogy az Azure-függvények meghívása vagy a REST API-k meghívása nem működik megfelelően, ezért ki kell javítania. Korábban törölnie kellett az ilyen ellenőrzéseket, hogy megakadályozzák, hogy hibásan blokkolják az üzembe helyezést. Miután kijavította az ellenőrzést, vissza kellett adnia, és helyesen kellett konfigurálnia, biztosítva, hogy az összes szükséges fejléc be legyen állítva, és a lekérdezési paraméterek helyesek legyenek. Ez unalmas.

Most egyszerűen letilthatja az ellenőrzést. A letiltott ellenőrzés nem fog futni az ellenőrzőcsomag későbbi kiértékelései során.

A hibás ellenőrzés kijavítása után egyszerűen engedélyezheti azt.

Felhasznált erőforrások és sablonparaméterek a Pipelines Runs Rest API-ban

A kiterjesztett Folyamatfuttatások REST API mostantól több típusú összetevőt ad vissza, amelyeket egy folyamatfuttatás használ, valamint a futtatás aktiválásához használt paramétereket. Továbbfejlesztettük az API-t, hogy visszaadja a container folyamatfuttatásban használt erőforrásokat és pipeline sablonparamétereket. Most például megírhatja a megfelelőségi ellenőrzéseket, amelyek kiértékelik a folyamat által használt adattárakat, tárolókat és egyéb folyamatfuttatásokat.

Íme egy példa az új válasz tartalmára.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Általános rendelkezésre állási sablon támogatása a YAML-szerkesztőben

A sablonok a YAML-folyamatok gyakran használt funkciói. A folyamatrészletek megosztásának egyszerű módja. Emellett hatékony mechanizmust jelentenek a biztonság és a szabályozás ellenőrzésére vagy érvényesítésére a pipeline-on keresztül.

Az Azure Pipelines támogatja a YAML-szerkesztőt, amely hasznos lehet a folyamat szerkesztésekor. A szerkesztő azonban eddig nem támogatta a sablonokat. A YAML-folyamatok szerzői nem tudtak segítséget kérni az intellisense segítségével sablon használata esetén. A sablonkészítők nem használhatják a YAML-szerkesztőt. Ebben a kiadásban a YAML-szerkesztőben hozzáadjuk a sablonok támogatását.

A fő Azure Pipelines YAML-fájl szerkesztése során felvehet vagy kibővíthet egy sablont. Amikor beírja a sablon nevét, a rendszer kérni fogja a sablon érvényesítését. Az ellenőrzés után a YAML-szerkesztő megérti a sablon sémáját, beleértve a bemeneti paramétereket is.

Az ellenőrzés után a sablonba navigálhat. A YAML-szerkesztő összes funkciójának használatával módosíthatja a sablont.

Vannak ismert korlátozások:

• Ha a sablon olyan kötelező paraméterekkel rendelkezik, amelyek nem a fő YAML-fájl bemeneteiként vannak megadva, akkor az ellenőrzés meghiúsul, és kéri, hogy adja meg ezeket a bemeneteket. Ideális esetben az ellenőrzés nem tiltható le, és az intellisense használatával meg kell tudnia adni a bemeneti paramétereket.
• Nem hozhat létre új sablont a szerkesztőből. Csak meglévő sablonokat használhat vagy szerkeszthet.

Új előre definiált rendszerváltozó

Bevezettünk egy új előre definiált rendszerváltozót, amelynek Build.DefinitionFolderPath értéke egy build folyamat definíciójának mappa útvonala. A változó yaML-ben és klasszikus buildfolyamatokban is elérhető.

Ha például a folyamat az FabrikamFiber\Chat mappa alatt található az Azure Pipelines rendszerben, akkor az Build.DefinitionFolderPath értéke FabrikamFiber\Chat.

Sztringfelosztási függvény támogatása YAML-sablonkifejezésekben

A YAML-folyamatok kényelmes módszereket biztosítanak a kódismétlések csökkentésére, például egy objektum listájának vagy tulajdonságának értékén keresztüli each hurkolással .

Előfordulhat, hogy az iterálni kívánt elemek sztringként jelennek meg. Ha például az üzembe helyezendő környezetek listáját a sztring integration1, integration2 határozza meg.

Ahogy meghallgattuk a fejlesztői közösség visszajelzéseit, hallottuk, hogy sztringfüggvényt split szeretne a YAML-sablonkifejezésekben.

Most már egy karakterláncot át lehet split, és az alsztringjei felett is lehet iterálni each.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

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

Támogatást adtunk hozzá sablonkifejezésekhez, amikor egy ref erőforrás repository tulajdonságát határozzuk meg a YAML-folyamatban. 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 a saját adattárát állítja össze, és ehhez egy könyvtárat kell kiolvasnia egy erőforrástárból. Tegyük fel továbbá, hogy azt szeretné, hogy az adatfolyam ugyanazt a könyvtárágat hívja le, mint amit 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 be kell tölteni a dev könyvtár ágát.

A mai napig explicit módon meg kellett adnia a kiválasztandó ágat, és módosítania kellett a pipeline kódot, amikor az ág megváltozott.

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

Amikor futtatja a csővezetéket, megadhatja a használni kívánt ágat a library adattárhoz.

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 ésa 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 reftemplates 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 pipeline kódját, ha azt szeretné, hogy a pipeline: kiterjesszen egy sablont egy másik ágról; kiterjesszen egy sablont ugyanabból az ágból, amelynek neve megegyezik a pipeline-éval, teljesen mindegy, hogy melyik ágon futtatta a pipeline-t.

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: ./build.sh
      - script: ./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 endpointvolumesportsoptionscontainer 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'

A sablonkifejezéseknél a parameters. és variables. használható. 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.

Ütemezett kiadások fejlesztései

Kijavítottunk egy hibát, amely miatt a pipeline ütemezési információi korruptak lettek, és a pipeline nem töltődött be. Ezt például az okozta, hogy az ág neve túllépett egy bizonyos számú karaktert.

Továbbfejlesztett hibaüzenet a csővezetékek betöltésekor

Az Azure Pipelines többféle eseményindítót biztosít a folyamat indításának konfigurálásához. A folyamat futtatásának egyik módja az ütemezett eseményindítók használata. Előfordulhat, hogy egy folyamat ütemezett futtatási információi megsérülnek, és egy terhelés meghiúsulását okozhatják. Korábban egy félrevezető hibaüzenetet jelenítettünk meg, amely azt állította, hogy a csővezeték nem található. Ezzel a frissítéssel megoldottuk a problémát, és tájékoztató jellegű hibaüzenetet adunk vissza. A továbbiakban a következőhöz hasonló üzenet jelenik meg: A buildütemezési adatok sérültek , ha egy folyamat nem töltődik be.

Ne szinkronizálja a címkéket, amikor egy Git-adattárat olvas be.

A checkout feladat a Git-adattár tartalmának beolvasásához --tags opciót használ. Ez azt eredményezi, hogy a kiszolgáló lekéri az összes címkét, valamint az összes olyan objektumot, amelyekre ezek a címkék mutatnak. Ez növeli a feladat folyamaton belüli futtatásának idejét – különösen akkor, ha több címkével rendelkező nagy adattárral rendelkezik. Ezenkívül az ellenőrzési feladat szinkronizálja a címkéket akkor is, ha engedélyezi a sekély beolvasási lehetőséget, ezáltal lehetséges, hogy a beolvasás célja nem teljesül. A Git-adattárból lekért vagy lekért adatok mennyiségének csökkentése érdekében új lehetőséget adtunk a feladathoz a címkék szinkronizálásának szabályozására. Ez a lehetőség a klasszikus és a YAML-folyamatokban is elérhető.

YAML

Ez a viselkedés a YAML-fájlból vagy a felhasználói felületről vezérelhető.

Ha le szeretné tiltani a címkék YAML-fájlon keresztüli szinkronizálását, adja hozzá a fetchTags: false kivételi lépéshez. Ha a fetchTags beállítás nincs megadva, ugyanaz, mint a fetchTags: true használatban.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Ha módosítani szeretné a meglévő YAML-folyamatok viselkedését, célszerűbb lehet ezt a beállítást a felhasználói felületen beállítani a YAML-fájl frissítése helyett. A felhasználói felületre való navigáláshoz nyissa meg a YAML szerkesztőt a folyamatnál, válassza ki az Eseményindítók, majd a Folyamat, és végül az Ellenőrzési lépés lehetőséget.

Ha ezt a beállítást a YAML-fájlban és a felhasználói felületen is megadja, akkor a YAML-fájlban megadott érték elsőbbséget élvez.

Klasszikus

Ha le szeretné tiltani a címkék szinkronizálását, törölje a jelet a Címkék szinkronizálása jelölőnégyzetből a Források lekérése lépésben.

A létrehozott új folyamatok (YAML vagy klasszikus) esetében a címkék alapértelmezés szerint továbbra is szinkronizálva lesznek. Ez a beállítás nem módosítja a meglévő folyamatok viselkedését. A címkék továbbra is szinkronizálva lesznek ezekben a folyamatokban, kivéve, ha explicit módon módosítja a fenti beállításokat.

Műtárgyak

Frissített alapértelmezett hírcsatorna-engedélyek

A Project Collection Build Service-fiókok mostantól alapértelmezés szerint közreműködői szerepkörrel rendelkeznek, amikor új projektgyűjtemény hatókörű Azure Artifacts-hírcsatornát hoznak létre a jelenlegi közreműködői szerepkör helyett.

Új felhasználói felület a felsőbb rétegbeli csomagkereséshez

Korábban láthatta a felsőbb rétegbeli csomagokat, ha rendelkezik a hírcsatorna másolatával. A probléma az volt, hogy nem tudtál olyan csomagokat keresni, amelyek elérhetők a külső forrásban, és amelyek még nincsenek mentve a hírcsatornában. Most az új hírcsatorna felhasználói felületével megkeresheti az elérhető felsőbb rétegbeli csomagokat.

Az Azure Artifacts mostantól egy felhasználói felületet biztosít, amellyel csomagokat kereshet a felsőbb rétegbeli forrásokban, és csomagverziókat menthet a hírcsatornába. Ez összhangban van a Microsoft termék- és szolgáltatásfejlesztésre vonatkozó céljával.

Jelentéskészítés

Szülő megjelenítése a lekérdezési eredmények widgetben

A Lekérdezési eredmények widget mostantól támogatja a szülő nevét és a szülőre mutató közvetlen hivatkozást.

Irányítópult másolása

Az ezzel a kiadással az Irányítópult másolása funkciót is bevezetjük.

Irányítópultok legutóbb elért dátum és módosítás dátuma

A csapatok több irányítópult létrehozásának egyik kihívása az elavult és nem használt irányítópultok kezelése és törlése. Fontos tudni, hogy egy irányítópultot mikor látogattak meg vagy módosítottak utoljára, hogy megértsük, melyek távolíthatók el. Ebben a kiadásban két új oszlopot vettünk fel az Irányítópultok címtárlapra. A legutóbb elért dátum nyomon követi az irányítópult legutóbbi meglátogatásának időpontját. A Módosította mező nyomon követi, hogy mikor és ki szerkesztette legutóbb az irányítópultot.

A Módosított adatok is megjelennek az irányítópult oldalán.

Reméljük, hogy ezek az új mezők segítenek a projektgazdáknak megérteni az irányítópultok tevékenységi szintjét, hogy megalapozott döntést hozhassanak, ha el kellene távolítani őket.

Az elemzési nézetek már elérhetők

Az Elemzési nézetek funkció hosszabb ideje előzetes verziójú a termék üzemeltetett verziójában. Ezzel a kiadással örömmel jelentjük be, hogy ez a funkció már elérhető az összes projektgyűjtemény számára.

A navigációban az Elemzés nézetek az Áttekintés lapról a Táblák lapra kerültek.

Az Analytics-nézet leegyszerűsíti a Power BI-jelentések szűrési feltételeinek megadását az Analytics-adatok alapján. Ha nem ismeri az Elemzési nézeteket, az alábbi dokumentáció segítségével érheti el:

• Tudnivalók az Analytics-nézetekről
• Elemzési nézet létrehozása az Azure DevOpsban
• Elemzési nézetek kezelése
• Power BI-jelentés létrehozása alapértelmezett Elemzési nézettel
• Csatlakozás az Elemzéshez a Power BI Adatösszekötővel

Már elérhető a lekéréses kérelem widget több adattárhoz

Örömmel jelentjük be, hogy a több adattárhoz tartozó Pull Request widget elérhető az Azure DevOps Server 2022.1-ben. Ezzel az új widgettel könnyedén megtekintheti a lekéréses kérelmeket akár 10 különböző adattárból egyetlen, egyszerűsített listában, így minden eddiginél egyszerűbben tarthatja a lekéréses kérelmeket.

Közösségi javaslatjegy

A felhasználási és felemelkedési gráfokon a megoldott tételek befejezettként történő megjelenítése.

Tisztában vagyunk azzal, hogy mennyire fontos pontosan tükrözni a csapat előrehaladását, beleértve a diagramokon befejezett megoldott elemeket is. Egy egyszerű kapcsolóval mostantól kiválaszthatja, hogy befejezettként jeleníti meg a feloldott elemeket, így valódi tükrözést nyújt a csapat leégési állapotáról. Ez a fejlesztés pontosabb nyomon követést és tervezést tesz lehetővé, így a csapatok megalapozott döntéseket hozhatnak a tényleges haladás alapján. Jobb átláthatóságot és jobb elemzéseket érhet el a jelentéskészítés frissített burndown- és burnup-diagramjaival.

Wiki - egy online enciklopédia, amit a felhasználók közösen szerkesztenek.

További diagramtípusok támogatása wikilapokon

Frissítettük a wikilapokban használt sellődiagramok verzióját a 8.13.9-es verzióra. Ezzel a frissítéssel mostantól az alábbi diagramokat és vizualizációkat is belefoglalhatja az Azure DevOps wikilapjaiba:

• Folyamatábra
• Szekvenciadiagramok
• Gantt-diagramok
• Kördiagramok
• Követelménydiagramok
• Állapotdiagramok
• Felhasználói út

Az olyan kísérleti módban lévő diagramok, mint az Entitáskapcsolat és a Git Graph, nem szerepelnek benne. Az új funkciókkal kapcsolatos további információkért tekintse meg a sellő kibocsátási megjegyzéseit.

---

Visszajelzés

Örömmel hallanánk tőled! Jelenthet egy problémát, vagy ötleteket adhat meg, és nyomon követheti azt fejlesztői közösség, és tanácsokat kaphat Stack Overflow.

---

lap tetején