Az Azure DevOps Server 2022 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 közvetlen frissítését az Azure DevOps Server 2019 vagy a Team Foundation Server 2015 vagy újabb verzió támogatja. 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.

---

Az Azure DevOps Server 2022 Update 0.1 Patch 5 kiadás dátuma: 2023. november 14.

Megjegyzés:

Az Azure DevOps Server-javítások összegzőek, ha nem telepítette a 3. javítást, ez a javítás tartalmazza az Azure Pipelines-ügynök frissítéseit. Az ügynök új verziója az 5. javítás telepítése után 3.225.0 lesz.

Fájl	SHA-256 hash
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

Közzétettünk egy javítást az Azure DevOps Server 2022 Update 0.1-hez, amely az alábbi javításokat tartalmazza.

• Bővítettük a PowerShell feladatok által engedélyezett karakterek listáját az „Shell feladatok argumentum paraméterellenőrzésének engedélyezése” beállításnál.
• Kijavítottunk egy hibát, amely miatt a szolgáltatáskapcsolatok szerkesztései megmaradtak a mégse gombra kattintás után.

Azure DevOps Server 2022 Update 0.1 Patch 4 Kiadás dátuma: 2023. október 10.

Megjegyzés:

Az Azure DevOps Server-javítások összegzőek, ha nem telepítette a 3. javítást, ez a javítás tartalmazza az Azure Pipelines-ügynök frissítéseit. Az ügynök új verziója az 5. javítás telepítése után 3.225.0 lesz.

Közzétettünk egy javítást az Azure DevOps Server 2022 Update 0.1-hez, amely az alábbi javításokat tartalmazza.

• Kijavítottunk egy hibát, amely miatt a folyamatok elakadtak a folyamatvégrehajtási modell frissítésével.
• Kijavítottunk egy hibát, amely miatt az "Analysis Owner" identitás inaktív identitásként jelent meg a javításfrissítési gépeken.
• A build-tisztítási feladat számos tevékenységet tartalmaz, amelyek mindegyike töröl egy artefaktumot a buildhez kapcsolódóan. Ha bármelyik feladat meghiúsult, az azt követő tevékenységek egyike sem futott. Ezt a viselkedést úgy módosítottuk, hogy figyelmen kívül hagyjuk a feladathibákat, és a lehető legtöbb összetevőt töröljük.

Azure DevOps Server 2022 Update 0.1 Patch 3 Kiadás dátuma: 2023. szeptember 12.

Megjegyzés:

Ez a javítás tartalmazza az Azure Pipelines-ügynök frissítéseit. A 3. javítás telepítése után az ügynök új verziója 3.225.0 lesz.

Közzétettünk egy javítást az Azure DevOps Server 2022 Update 0.1-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-33136: Az Azure DevOps Server távoli kódvégrehajtási biztonsági rése.
• CVE-2023-38155: Az Azure DevOps Server és a Team Foundation kiszolgáló jogosultsági biztonsági résének emelése.

Azure DevOps Server 2022 Update 0.1 Patch 2 Kiadás dátuma: 2023. augusztus 8.

Közzétettünk egy javítást az Azure DevOps Server 2022 Update 0.1-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-36869: Azure DevOps Server hamisítási biztonsági rés.
• Kijavítottunk egy hibát a SOAP-hívásokban, ahol az ArithmeticException nagy metaadat-XML-válaszhoz hozható létre.
• A szolgáltatáskapcsolatok szerkesztőjének módosításait bevezették, hogy a végpont állapota törlődjön az összetevő bezárásakor.
• Elhárítottuk a markdown-fájlokban nem működő relatív hivatkozások problémáját.
• Kijavítottunk egy, az alkalmazásszinttel kapcsolatos teljesítményproblémát, amely a szokásosnál hosszabb ideig tart az indításig, amikor nagy számú címke van meghatározva.
• Az Ügynökkészletek lapon elhárítottuk a TF400367 hibákat.
• Kijavítottunk egy hibát, amely miatt az Analysis Owner identitás inaktív identitásként jelent meg.
• Kijavítottuk a végtelen ciklus hibáját a CronScheduleJobExtensionben.

Azure DevOps Server 2022 Update 0.1 Patch 1 Kiadás dátuma: 2023. június 13.

Közzétettünk egy javítást az Azure DevOps Server 2022 Update 0.1-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-21565: Azure DevOps Server hamisítási biztonsági rés.
• CVE-2023-21569: Azure DevOps Server hamisítási biztonsági rés.
• Kijavítottunk egy hibát a Szolgáltatáskapcsolatok szerkesztővel. Most a végpont vázlatállapota törlődik az összetevő bezárásakor.
• Kijavítottunk egy hibát, amely miatt a leválasztási vagy csatolási kollekció sikertelen, a következő hibát jelezve: "TF246018: Az adatbázis-művelet túllépte az időkorlátot, és megszakadt."

Azure DevOps Server 2022 Update 0.1 Kiadás dátuma: 2023. május 9.

Az Azure DevOps Server 2022.0.1 hibajavítások összesítője. Tartalmazza a korábban kiadott Azure DevOps Server 2022.0.1 RC összes javítását. Közvetlenül telepítheti az Azure DevOps Server 2022.0.1-et, vagy frissíthet az Azure DevOps Server 2022-ről vagy a Team Foundation Server 2015-ről vagy újabbról.

Az Azure DevOps Server 2022 Update 0.1 RC kiadási dátuma: 2023. április 11.

Az Azure DevOps Server 2022.0.1 RC hibajavítások összesítője. Tartalmazza a korábban kiadott Azure DevOps Server 2022-javítások összes javítását. Közvetlenül telepítheti az Azure DevOps Server 2022.0.1-et, vagy frissíthet az Azure DevOps Server 2022-ről vagy a Team Foundation Server 2015-ről vagy újabbról.

Ez a kiadás a következő hibák javítását tartalmazza:

• Frissítette a Git Virtual File System (GVFS) rendszert a 2.39.1.1-micorosoft.2 verzióra egy biztonsági rés elhárításához.
• A tesztadatok nem törlődtek, ezért az adatbázis növekedni fog. Ezzel a javítással frissítettük a buildmegőrzést, hogy elkerüljük új árva tesztadatok létrehozását.
• Az AnalyticCleanupJob frissítésekről: a feladat állapota korábban Leállítva volt, és most Sikerként jelentjük.
• A "tfx extension publish" parancs "A megadott kulcs nem volt jelen a szótárban" hibával meghiúsult.
• Bevezetett egy áthidaló megoldást a Csapatnaptár bővítmény elérése közbeni hiba kezelésére.
• CVE-2023-21564: Az Azure DevOps Server helyek közötti szkriptelési biztonsági rése
• CVE-2023-21553: Az Azure DevOps Server távoli kódvégrehajtási biztonsági rése
• Frissítettük az MSBuild és a VSBuild feladatokat a Visual Studio 2022 támogatásához.
• Az XSS-támadási vektor megakadályozása érdekében frissítse a betöltés újrahitelesítésének módszertanát.
• Az Azure DevOps Server 2022 Proxy a következő hibát jelenti: VS800069: Ez a szolgáltatás csak a helyszíni Azure DevOpsban érhető el.
• Kijavítottuk a polckészletek akadálymentességi problémáját a webes felhasználói felületen keresztül.
• Elhárítottuk azt a problémát, amely miatt újra kellett indítani a tfsjobagent szolgáltatást és az Azure DevOps Server alkalmazáskészletét, miután frissítette az SMTP-hez kapcsolódó beállítást az Azure DevOps Server Felügyeleti konzolon.
• A lejárati dátum előtt hét nappal nem küldték el az értesítéseket a PAT számára.

Azure DevOps Server 2022 Patch 4 kiadás dátuma: 2023. június 13.

Kiadottunk egy javítást az Azure DevOps Server 2022-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-21565: Azure DevOps Server hamisítási biztonsági rés.
• CVE-2023-21569: Azure DevOps Server hamisítási biztonsági rés.
• Kijavítottunk egy hibát a Szolgáltatáskapcsolatok szerkesztővel. Most a végpont vázlatállapota törlődik az összetevő bezárásakor.
• Kijavítottunk egy hibát, amely miatt a leválasztási vagy csatolási kollekció sikertelen, a következő hibát jelezve: "TF246018: Az adatbázis-művelet túllépte az időkorlátot, és megszakadt."

Azure DevOps Server 2022 Patch 3 kiadás dátuma: 2023. március 21.

Kiadottunk egy javítást (19.205.33506.1) az Azure DevOps Server 2022-hez, amely az alábbi javításokat tartalmazza.

• Elhárítottuk azt a problémát, amely miatt újra kellett indítani a tfsjobagent szolgáltatást és az Azure DevOps Server alkalmazáskészletét, miután frissítette az SMTP-hez kapcsolódó beállítást az Azure DevOps Server Felügyeleti konzolon.
• A végpont állapotának másolása a Szolgáltatásvégpont szerkesztési panelre ahelyett, hogy hivatkozással továbbítanák.
• Korábban a szolgáltatáskapcsolatok szerkesztésekor a módosítások a mégse gomb kiválasztása után is megmaradtak a felhasználói felületen. Ezzel a javítással kijavítottuk a Notification SDK-ban, amikor egy csapat értesítési kézbesítési beállítása kézbesítés letiltva van. Ebben az esetben, ha az értesítési előfizetés a Team preference delivery beállítással van konfigurálva, a csapattagok nem kapják meg az értesítéseket. A tagok preferenciáinak ellenőrzéséhez nincs szükség a csoport alatti identitások további bővítésére.

Azure DevOps Server 2022 Patch 2 kiadás dátuma: 2023. február 14.

Kiadottunk egy javítást az Azure DevOps Server 2022-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-21564: Az Azure DevOps Server helyek közötti szkriptelési biztonsági rése
• Frissítettük az MSBuild és a VSBuild feladatokat a Visual Studio 2022 támogatásához.
• Frissítse a betöltési újrahitelesítés módszertanát az XSS lehetséges támadási vektorának megakadályozása érdekében.
• Az Azure DevOps Server 2022 Proxy a következő hibát jelenti: VS800069: Ez a szolgáltatás csak a helyszíni Azure DevOpsban érhető el.

Azure DevOps Server 2022 Patch 1 Kiadás dátuma: 2023. január 24.

Kiadottunk egy javítást az Azure DevOps Server 2022-hez, amely az alábbi javításokat tartalmazza.

• A tesztadatok nem törlődtek, ezért az adatbázis növekedni fog. Ezzel a javítással frissítettük a buildmegőrzést, hogy elkerüljük új árva tesztadatok létrehozását.
• Az AnalyticCleanupJob frissítésekről: a feladat állapota korábban Leállítva volt, és most Sikerként jelentjük.
• A "tfx extension publish" parancs "A megadott kulcs nem volt jelen a szótárban" hibával meghiúsult.
• Bevezetett egy áthidaló megoldást a Csapatnaptár bővítmény elérése közbeni hiba kezelésére.

Az Azure DevOps Server 2022 kiadási dátuma: 2022. december 6.

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

Az Azure DevOps Server 2022 RC2 kiadási dátuma: 2022. október 25.

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

Megjegyzés:

Új SSH RSA-algoritmusok engedélyezve

Az RSA nyilvános kulcsok támogatása a korábban támogatott SHA1 SSH-RSA mellett az SHA2 nyilvános kulcstípusok támogatásához is javult.

A támogatott nyilvános kulcstípusok a következők:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Beavatkozás szükséges 

Ha a SSH-RSA engedélyezéséhez a .ssh/config1 fájlban kifejezetten megadott kerülő megoldást implementálta, akkor el kell távolítania a PubkeyAcceptedTypes, vagy módosítania kell azt, hogy a RSA-SHA2-256, az RSA-SHA2-512, vagy mindkettőt használja. A dokumentációban GIT_SSH_COMMAND="ssh -v" git fetch részletes információkat talál arról, hogy mi a teendő, ha a rendszer továbbra is kéri a jelszót, és nem található kölcsönös aláírási algoritmus.

Az ellipsziskulcs-támogatás még nem lett hozzáadva, és továbbra is egy erősen kért funkció marad a hátralékunkban.

Azure DevOps Server 2022 RC1 kiadás dátuma: 2022. augusztus 9.

Az Azure DevOps Server 2022 újdonságainak összefoglalása

Fontos

A Warehouse and Analysis Service az Azure DevOps Server (2020) korábbi verziójában elavult. Az Azure DevOps Server 2022-ben a Warehouse and Analysis Service el lett távolítva a termékből. Az Elemzés mostantól biztosítja a terméken belüli jelentéskészítési élményt.

Az Azure DevOps Server 2022 számos új funkciót vezet be. Néhány fontos elem:

• Szállítási tervek
• Helyes személy megjelenítése véglegesítési hivatkozásokon
• Új vezérlők a folyamatok környezeti változóihoz
• Korlátlan token generálása fork build-ekhez
• Új TFVC-lapok
• A diagram widgetjeiben elérhető címkék szerinti csoportosítás

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

• Táblák
• Repos
• Csővezetékek
• Jelentéskészítés

---

Táblák

Kézbesítési tervek

Örömmel jelentjük be, hogy a kézbesítési csomagok már megtalálhatók az Azure DevOps Serverben. A Kézbesítési Tervek 3 kulcsfontosságú forgatókönyvet valósítanak meg:

• A terv idővonal-nézete
• A munka előrehaladása
• Függőségek nyomon követése

Az alábbiakban a főbb funkciók találhatók. A szűrés, a jelölők és a mezőfeltételek szintén a szállítási tervek részét képezik.

Két fő nézet van: sűrített és kibontott

A Kézbesítési csomagok 2.0 lehetővé teszi a terv összes munkaelemének idővonalon való megtekintését a kezdési és céldátumok vagy iterációs dátumok használatával. Az elsőbbségi sorrend a kezdő és a céldátum, majd az iteráció. Így olyan portfóliószintű munkaelemeket vehet fel, mint például az Epic, amelyek gyakran nincsenek meghatározva egy iterációban.

A tömörített és a kibontott nézet két fő nézetből áll. A terv nagyításához és kicsinyítéséhez kattintson a nagyítóra a terv jobb oldalán.

A tömörített és a kibontott nézet két fő nézetből áll. A terv nagyításához és kicsinyítéséhez kattintson a terv jobb oldalán található nagyítóra.

• Sűrített nézet

  A tömörített nézetben az összes munkaelem-kártya összecsukva jelenik meg, ami azt jelenti, hogy nem minden kártyainformáció jelenik meg. Ez a nézet a tervben szereplő munka átfogó nézetéhez hasznos. A kártyamezők összecsukásához kattintson a kártya ikonra a terv jobb oldalán található nagyító ikonok mellett.

  Íme egy példa a tömörített és a kibontott nézetek közötti váltásra.

  

• Bővített nézet

  A kibontott nézet egy munkaelem haladását jeleníti meg a gyermek- és csatolt elemek számának összesítésével és a kész százalékos érték megjelenítésével. Az aktuális állapotot a munkaelemek száma határozza meg.

  Íme egy példa egy bővített nézetet használó tervre. Figyelje meg a folyamatjelző sávokat és a teljesítési százalékot.

  

Függőségek nyomon követése

A függőségek nyomon követése a munkaelemekben definiált megelőző és követő hivatkozásokon alapul. Ha ezek a hivatkozások nincsenek definiálva, akkor nem jelennek meg függőségi sorok. Ha függőségi probléma merül fel egy munkaelemben, a függőségi hivatkozás ikonja piros színű lesz.

• Függőségek megtekintése

  Az egyes függőségeket a függőségi panelen tekintheti meg, amely megjeleníti az adott munkaelem összes függőségét, beleértve az irányt is. A piros felkiáltójel függőségi problémát jelez. A panel megjelenítéséhez kattintson a kártya jobb felső sarkában található függőségi hivatkozás ikonra. Íme néhány példa a függőségekre.

  

  

• Függőségi sorok

  A munkaelemek közötti függőségek a megfelelő munkaelemek közötti irányított nyílvonalakkal jelennek meg. Több függőség több sorként jelenik meg. A piros színű vonal problémát jelez.

  Íme néhány példa.

  

  Íme egy példa egy több függőséggel rendelkező munkaelemre, amely sűrített nézettel is működik.

  

  Probléma esetén a vonal színe piros, és a függőség ikonja is.

  Íme egy példa.

  

Kártyaformázás

A kártyák mostantól szabályokkal is formázhatók, például a Kanban-táblákkal. Nyissa meg a terv beállításait, és kattintson a Stílusok elemre. A Stílusok panelen kattintson a + Stílusszabály hozzáadása elemre a szabály hozzáadásához, majd kattintson a Mentés gombra. Legfeljebb 10 szabály lehet, és minden szabály legfeljebb 5 záradékkal rendelkezhet.

• Előtte

• Utána

A kézbesítési csomagokkal kapcsolatos további információkért tekintse meg a dokumentációt itt.

Eltávolított elemek a Munkaelemek központban

A Munkaelemek központ az a hely, ahol megtekintheti a létrehozott vagy önhöz rendelt elemek listáját. A munkaelemek felsorolásának egyszerűsítéséhez több személyre szabott kimutatás- és szűrőfunkciót biztosít. A Hozzám rendelt kimutatás egyik legfontosabb panasza, hogy az eltávolított munkaelemeket jeleníti meg. Egyetértünk abban, hogy az eltávolított munkaelemek már nem értékesek, és nem lehetnek a hátralékban. Ebben a sprintben elrejtjük az összes eltávolított elemet a Hozzám rendelt nézetekből a Munkaelemek Központban.

Helyes személy megjelenítése véglegesítési hivatkozásokon

A munkaelem fejlesztési szakasza a vonatkozó véglegesítések és lekéréses kérelmek listáját jeleníti meg. A véglegesítési vagy lekéréses kérelem szerzőjének megtekintése a kapcsolódó időponttal együtt. Ezzel a frissítéssel kijavítottunk egy hibát, amely miatt a szerző avatarja helytelenül jelenik meg a nézetben.

A törölt melléklet letöltési lehetőségének eltávolítása a munkaelem előzményekből

Kijavítottunk egy kis hibát, amely miatt a felhasználók a mellékleteket a munkaelem előzményeiből tölthették le, még azután is, hogy a mellékletet eltávolították az űrlapról. Most, hogy a melléklet el lett távolítva, nem tölthető le az előzményekből, és a letöltési URL-cím sem lesz elérhető a REST API-válaszból.

"Nem javít" érték lett hozzáadva a Hiba ok mezőjéhez

Az összes többi munkaelemtípushoz hasonlóan a Hiba munkaelem típusa is jól definiált munkafolyamattal rendelkezik. Minden munkafolyamat három vagy több államból és egy okból áll. Az okok határozzák meg, hogy az elem miért váltott át egyik állapotról a másikra. Ezzel a frissítéssel hozzáadtunk egy nem javítjuk ok-értéket a Hibajegy típusokhoz az Agile módszerben. Ez az érték elérhető indokként, amikor a hibákat Új vagy Aktív állapotból Feloldottra helyezi át. A szoftverhibák definiálásáról, rögzítéséről, osztályozásáról és kezeléséről az Azure Boards dokumentációjában tudhat meg többet.

Csővezetékek

Csatornaadatmegőrzési szabályzatok eltávolítása klasszikus buildekben

Mostantól a klasszikus buildekhez és YAML-folyamatokhoz is konfigurálhat adatmegőrzési szabályzatokat az Azure DevOps-projektbeállításokban. A klasszikus build-folyamatok folyamatonkénti adatmegőrzési szabályai már nem támogatottak. Bár ez az egyetlen módja a YAML-folyamatok adatmegőrzésének konfigurálásának, a klasszikus buildelési folyamatok adatmegőrzését is konfigurálhatja folyamatonként. Egy közelgő kiadásban eltávolítottuk a klasszikus buildelési folyamatok összes folyamatonkénti adatmegőrzési szabályát.

Ez azt jelenti az Ön számára, hogy a klasszikus build pipeline-ek, amelyek folyamatonkénti adatmegőrzési szabályokkal rendelkeztek, mostantól a projektszintű adatmegőrzési szabályok hatálya alá tartoznak.

Annak érdekében, hogy a frissítés során ne veszítsen el buildeket, létrehozunk egy bérletet a frissítéskor meglévő összes olyan buildhez, amely nem rendelkezik bérletekkel.

Javasoljuk, hogy a frissítés után ellenőrizze a projektszintű adatmegőrzési beállításokat. Ha a csővezeték kifejezetten egyéni szabályokat igényel, használhat egyéni feladatot a csővezetékben. A feladaton keresztüli megőrzési szabályok beállításáról a buildek, kiadások és tesztek megőrzési szabályozásának dokumentációjában talál információkat.

Új vezérlők a folyamatok környezeti változóihoz

Az Azure Pipelines-ügynök speciális naplózási parancsokat keres a standard kimenetben, és végrehajtja őket. A setVariableparancs segítségével beállíthat egy változót, vagy módosíthatja a korábban definiált változót. Ezt a rendszeren kívüli szereplő is kihasználhatja. Ha például a folyamat olyan lépéssel rendelkezik, amely egy ftp-kiszolgálón nyomtatja ki a fájlok listáját, akkor az ftp-kiszolgálóhoz hozzáféréssel rendelkező személy hozzáadhat egy új fájlt, amelynek a neve tartalmazza a setVariable parancsot, és a folyamat viselkedésének megváltoztatását okozza.

Számos felhasználónk van, akik a pipeline naplózási parancsának segítségével állítanak be változókat. Ezzel a kiadással a következő módosításokat hajtjuk végre, hogy csökkentsük a setVariable parancs nem kívánt felhasználásának kockázatát.

• Új szerkezetet adtunk hozzá a feladatszerzők számára. Ha belevesz egy olyan kódrészletet, mint a következő task.json, a tevékenység szerzője szabályozhatja, hogy a változókat a feladat állítja-e be.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Emellett számos beépített feladatot frissítünk, például az ssh-t, hogy ne lehessen kihasználni őket.

• Végül YAML-szerkezetekkel szabályozhatja, hogy egy lépés beállíthat-e változókat.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Korlátlan token létrehozása elágazási build-ekhez

A GitHub Enterprise felhasználói általában forkokkal járulnak hozzá egy forrás adattárhoz. Amikor az Azure Pipelines hozzájárulásokat hoz létre egy GitHub Enterprise-adattár elágaztatásából, korlátozza a feladat-hozzáférési jogkivonathoz megadott engedélyeket, és nem teszi lehetővé a folyamat titkos kulcsainak elérését az ilyen feladatok számára. Az elágazások biztonságáról a dokumentációnkban talál további információt.

Ez a kívántnál szigorúbb lehet az ilyen zárt környezetekben, ahol a felhasználók továbbra is kihasználhatják a belső forrásból származó együttműködési modellek előnyeit. Bár konfigurálhat egy beállítást egy pipeline-ban, hogy a titkos adatokat elérhetővé tegye a forkok számára, nincs beállítás a feladat-hozzáférési jogkivonat hatókörének szabályozására. Ezzel a kiadással lehetőséget biztosítunk arra, hogy még az elágazások buildjeihez is létrehozhasson egy normál feladat-hozzáférési tokent.

Ezt a beállítást a folyamatszerkesztő eseményindítóiról módosíthatja. A beállítás módosítása előtt győződjön meg arról, hogy teljes mértékben tisztában van a konfiguráció engedélyezésének biztonsági következményeivel.

Az adattárak, mint védett erőforrások a YAML-folyamatokban

Az Azure DevOps-projektet úgy is rendszerezheti, hogy több alprojektet is üzemeltetjen – mindegyik saját Azure DevOps Git-adattárral és egy vagy több folyamattal. Ebben a struktúrában érdemes lehet szabályozni, hogy mely folyamatok férhetnek hozzá az adattárakhoz. Tegyük fel például, hogy két A és B adattára van ugyanabban a projektben, valamint két X és Y folyamat, amelyek általában ezeket az adattárakat építik. Előfordulhat, hogy meg szeretné akadályozni, hogy az Y folyamat hozzáférjen az A adattárhoz. Általában azt szeretné, hogy az A közreműködői szabályozni tudják, hogy mely folyamatokhoz szeretnének hozzáférést biztosítani.

Bár ez részben lehetséges volt az Azure Git-adattárakkal és -folyamatokkal, nem volt tapasztalat a kezelésével kapcsolatban. Ez a funkció kezeli ezt a rést. Az Azure Git-adattárak mostantól védett erőforrásokként kezelhetők YAML-folyamatokban, akárcsak a szolgáltatáskapcsolatok és az ügynökkészletek.

Az A adattár közreműködőjeként ellenőrzéseket és folyamatengedélyeket adhat hozzá az adattárhoz. Ehhez keresse meg a projekt beállításait, válassza az Adattárak lehetőséget, majd az adattárat. Ekkor megjelenik egy "Ellenőrzések" nevű új menü, ahol bármilyen beépített vagy egyéni ellenőrzést konfigurálhat Azure-függvények formájában.

A "Biztonság" lapon kezelheti az adattárhoz hozzáférő folyamatok listáját.

Amikor egy YAML-folyamat adattárat használ, az Azure Pipelines-infrastruktúra ellenőrzi és biztosítja, hogy az összes ellenőrzés és engedély teljesül.

Megjegyzés:

Ezek az engedélyek és ellenőrzések csak a YAML-folyamatokra vonatkoznak. A klasszikus folyamatok nem ismerik fel ezeket az új funkciókat.

Változócsoportok és biztonságos fájlok engedélyei és ellenőrzése

A YAML-folyamatokban különböző típusú megosztott erőforrásokat használhat. Ilyenek például a szolgáltatáskapcsolatok, a változócsoportok, a biztonságos fájlok, az ügynökkészletek, a környezetek vagy az adattárak. Annak érdekében, hogy egy folyamat ne férhessen hozzá egy erőforráshoz, az erőforrás tulajdonosa konfigurálhatja az engedélyeket, és ellenőrizheti az adott erőforrást. Minden alkalommal, amikor egy folyamat megpróbál hozzáférni az erőforráshoz, a rendszer minden konfigurált engedélyt és ellenőrzést kiértékel. Ezek a védelmek szolgáltatáskapcsolatokon, környezeteken és ügynökkészleteken már egy ideje elérhetők. Ezeket a közelmúltban adták hozzá az adattárakhoz. Ezzel a kiadással ugyanazokat a védelmet adjuk hozzá a változó csoportokhoz és a biztonságos fájlokhoz.

Ha egy változócsoporthoz vagy egy biztonságos fájlhoz való hozzáférést egy kis folyamatcsoportra szeretné korlátozni, használja a Pipelines engedély funkcióját.

A minden alkalommal, amikor egy csővezeték lefut, kiértékelendő ellenőrzések vagy jóváhagyások konfigurálásához használja a Könyvtárhoz tartozó jóváhagyások és ellenőrzések funkciót.

Környezetek automatikus létrehozásának változásai

Amikor létrehoz egy YAML-folyamatot, és nem létező környezetre hivatkozik, az Azure Pipelines automatikusan létrehozza a környezetet. Ez az automatikus létrehozás történhet a felhasználói vagy a rendszerkörnyezetben. A következő folyamatokban az Azure Pipelines tud a műveletet végrehajtó felhasználóról:

• A YAML-folyamatlétrehozó varázslót az Azure Pipelines webes felületén használhatja, és egy még nem létrehozott környezetre hivatkozhat.
• A YAML-fájlt az Azure Pipelines webes szerkesztőjével frissítheti, és mentheti a folyamatot, miután hivatkozást adott hozzá egy nem létező környezethez. A fenti esetekben az Azure Pipelines világosan ismeri a műveletet végrehajtó felhasználót. Ezért létrehozza a környezetet, és hozzáadja a felhasználót a környezet rendszergazdai szerepköréhez. Ez a felhasználó rendelkezik a környezet kezeléséhez szükséges összes engedéllyel, és/vagy más felhasználókat is bevonhat a környezet kezeléséhez különböző szerepkörökbe.

A következő folyamatokban az Azure Pipelines nem rendelkezik információval a környezetet létrehozó felhasználóról: a YAML-fájlt egy másik külső kódszerkesztővel frissíti, egy nem létező környezetre mutató hivatkozást ad hozzá, majd egy folyamatos integrációs folyamatot indít el. Ebben az esetben az Azure Pipelines nem tud a felhasználóról. Korábban úgy kezeltük ezt az esetet, hogy hozzáadtuk az összes projekt-közreműködőt a környezet rendszergazdai szerepköréhez. Ezután a projekt bármely tagja módosíthatta ezeket az engedélyeket, és megakadályozhatta, hogy mások hozzáférjenek a környezethez.

Visszajelzést kaptunk arról, hogy rendszergazdai engedélyeket adtunk a környezethez egy projekt minden tagjának. Amikor meghallgattuk a visszajelzését, azt hallottuk, hogy nem szabad automatikusan létrehozni egy környezetet, ha nem egyértelmű, hogy ki a műveletet végrehajtó felhasználó. Ezzel a kiadással módosítottuk a környezetek automatikus létrehozásának módját:

• A folyamatfuttatások nem hoznak létre automatikusan környezetet, ha nem létezik, és ha a felhasználói környezet nem ismert. Ilyen esetekben a feldolgozási sor sikertelen lesz egy Környezet nem található hiba miatt. A környezeteket előre létre kell hoznia megfelelő biztonsági és ellenőrzési konfigurációval, mielőtt folyamatban használná őket.
• Az ismert felhasználói környezettel rendelkező folyamatok a korábbiakhoz hasonlóan automatikusan létrehoznak környezeteket.
• Végezetül meg kell jegyezni, hogy a környezet automatikus létrehozására vonatkozó funkció csak az Azure Pipelines használatának egyszerűbbé tétele érdekében lett hozzáadva. Tesztforgatókönyvekhez készült, nem éles forgatókönyvekhez. Mindig előre létre kell hoznia az éles környezeteket a megfelelő engedélyekkel és ellenőrzésekkel, majd használnia kell őket a pipeline-okban.

Insights-párbeszéd eltávolítása a build pipeline-ből

A visszajelzése alapján a munkafolyamat javítása érdekében eltávolítottuk a buildelési folyamat navigálásakor megjelenő Tevékenység/folyamat Elemzések párbeszédablakot. A folyamatelemzés továbbra is elérhető, így ön rendelkezik a szükséges elemzésekkel.

Csak kizárólagos zárolási ellenőrzések során támogatott a szekvenciális telepítések, nem pedig csak a legújabb telepítések.

A YAML-folyamatokban az ellenőrzések segítségével szabályozható a szakaszok végrehajtása védett erőforrásokon. Az egyik gyakori ellenőrzés, amelyet használhat, egy kizárólagos zárolási ellenőrzés. Ez az ellenőrzés csak egyetlen futtatás folytatását teszi lehetővé a folyamatból. Ha egyszerre több futtatás is megkísérel üzembe helyezést egy környezetben, az ellenőrzés megszakítja az összes régi futtatási lehetőséget, és engedélyezi a legújabb futtatás üzembe helyezését.

A régi futtatások megszakítása jó módszer, ha a kiadások kumulatívak, és tartalmazzák az előző futtatások kódmódosításait. Vannak azonban olyan folyamatok, amelyekben a kódmódosítások nem kumulatívak. Ezzel az új funkcióval engedélyezheti az összes futtatás folytatását és üzembe helyezését egymás után egy környezetben, vagy megőrizheti a régi futtatások megszakításának korábbi viselkedését, és lehetővé teheti a legújabbak használatát. Ezt a viselkedést a folyamat YAML-fájljában hívott lockBehavior új tulajdonság használatával adhatja meg. A sequential értéke azt jelenti, hogy minden futtatás egymás után szerzi be a zárolást a védett erőforráshoz. A runLatest értéke azt jelenti, hogy csak a legújabb futtatás szerzi be az erőforrás zárolását.

Ha kizárólagos zárolás-ellenőrzést szeretne használni sequential üzemelő példányokkal vagy runLatest, kövesse az alábbi lépéseket:

1. Engedélyezze a kizárólagos zárolási ellenőrzést a környezetben (vagy egy másik védett erőforráson).
2. A folyamat YAML-fájljában adjon meg egy új, lockBehaviornevű tulajdonságot. Ez megadható a teljes folyamathoz vagy egy adott fázishoz:

Beállítás egy fázisban:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Beállítás a folyamaton:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ha nem ad meg egy lockBehaviorértéket, akkor a rendszer feltételezi , hogy runLatestaz .

A ServiceNow Quebec-verziójának támogatása

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 a ServiceNow Quebec-verziójával működjön. A klasszikus és a YAML folyamatok is működnek Quebec-kel. Az integráció működésének biztosítása érdekében frissítsen az alkalmazás új verziójára (4.188.0) a Service Now áruházból. További információ: Integrálás a ServiceNow változáskezeléssel.

Új feltételes YAML-kifejezések

A feltételes kifejezések írása YAML-fájlokban most egyszerűbbé vált a ${{ else }} és ${{ elseif }} kifejezések használatával. Az alábbiakban példákat talál arra, hogyan használhatja ezeket a kifejezéseket YAML-folyamatok fájljaiban.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Helyettesítő karakterek támogatása útvonal-szűrőkben

Helyettesítő kártyák használhatók a CI- vagy PR-triggerek belefoglalási és kizárási ágainak megadásához egy folyamat YAML-fájljában. Elérésiút-szűrők megadásakor azonban nem használhatók. Például nem vehet fel minden egyező src/app/**/myapp*elérési utat. Erre több ügyfél is felhívta a figyelmet. Ez a frissítés kitölti ezt a rést. Most használhat helyettesítő karaktereket (**vagy *?) az elérési utak szűrőinek megadásakor.

A folyamatok alapértelmezett ügynökspecifikációja a Windows-2022 lesz

Az windows-2022 címkénél a windows-latest rendszerkép készen áll arra, hogy alapértelmezett verzió legyen az Azure Pipelines Microsoft által üzemeltetett ügynökeiben. Eddig ez a címke a Windows-2019-ügynökökre mutatott. Ezt a módosítást január 17-től kezdődően több héten keresztül hajtják végre. Azt tervezzük, hogy márciusig befejezzük a migrálást.

Az Azure Pipelines 2021 szeptembere óta támogatja a windows-2022-t. Figyeltük a visszajelzését a windows-2022 kép stabilitásának javítása érdekében, és most készen állunk arra, hogy azt legújabb verziónak beállítsuk.

A windows-2022 kép tartalmazza a Visual Studio 2022-t. A windows-2022 és windows-2019 közötti különbségek teljes listájáért látogasson el a GitHub-kérdésre. A lemezképre telepített szoftverek teljes listájáért tekintse meg itt.

A csővezeték mappa átnevezése érvényesíti az engedélyeket.

A pipeline-eket tartalmazó mappák átnevezhetők. A mappák átnevezése csak akkor lesz sikeres, ha a felhasználó szerkesztési engedélyekkel rendelkezik a mappában található legalább egy folyamathoz.

Pipelines Agent futtatókörnyezet frissítésének tervezése

Mi az a Pipeline Agent?

Az Azure DevOps Pipeline Agent az a szoftvertermék, amely egy folyamatgazdagépen fut a folyamatfeladatok végrehajtásához. Microsoft által üzemeltetett ügynökökön, skálázási csoport ügynökökön és saját üzemeltetésű ügynökökön fut. Az utóbbi esetben saját maga telepíti. A folyamatügynök egy figyelőből és feldolgozóból (.NET-ben implementálva) áll, a feldolgozó olyan feladatokat futtat, amelyek a Node-ban vagy a PowerShellben vannak implementálva, és ezért azokat a futtatókörnyezeteket üzemelteti.

A .NET 6 közelgő frissítése és a Red Hat 6 elavulása

A .NET 6 kiadásával kihasználhatjuk az új platformfüggetlen képességeit. Pontosabban natív kompatibilitást biztosítunk az Apple Silicon és a Windows Arm64 rendszerhez. A következő hónapok során azt tervezzük, hogy a Pipeline Agent (Listener és Worker) a .NET 6-ra tér át.

Ennek számos kényszere miatt 2022. április 30-án elvetjük a Red Hat Enterprise Linux 6 támogatását ügynökünktől.

Azure-fájlmásolási feladat frissítései

Az Azure File Copy feladat új verzióját vezetjük be. Ezzel a feladatsal fájlokat másolhat a Microsoft Azure Storage-blobokra vagy virtuális gépekre. Az új verzió számos olyan frissítéssel rendelkezik, amelyeket a közösség gyakran kért:

• Az AzCopy eszköz verziója a 10.12.2-es verzióra frissült, amely támogatja a fájltartalmak típusait. Ennek eredményeképpen a PDF, az Excel, a PPT vagy a támogatott mimetípusok másolásakor a fájl tartalomtípusa megfelelően van beállítva.

• Az AzCopy új verziójával konfigurálhat olyan beállítást is, amely megtisztítja a célhelyet, ha a céltípus az Azure Blob. Ha ezt a beállítást választja, a tárolóban lévő összes mappa/fájl törlődik. Vagy ha egy blob előtag van megadva, akkor az előtag alatti összes mappa és fájl törlődik.

• A feladat új verziója az AzureRM-modulok helyett az ügynökre telepített Az-modulokra támaszkodik. Ez bizonyos esetekben eltávolít egy szükségtelen figyelmeztetést a feladat használatakor.

A módosítások a feladat főverziófrissítésének részét képezik. Az új verzió használatához kifejezetten frissítenie szükséges a csővezetékeit. Ezt a döntést úgy választottuk, hogy a főverziót frissítjük, hogy ne szakítsunk meg olyan folyamatokat, amelyek továbbra is az AzureRM-moduloktól függenek.

Új bővítménypontok a Pipelines details nézethez

Két új bővíthetőségi pontot adtunk hozzá, amelyeket megcélzhat a bővítményekben. Ezek a bővíthetőségi pontok lehetővé teszik egy egyéni gomb hozzáadását a folyamat fejlécében és egy egyéni menüt egy folyamatmappában:

• Egyéni gomb a folyamat fejlécében: ms.vss-build-web.pipelines-header-menu
• Egyéni menü egy folyamatmappában: ms.vss-build-web.pipelines-folder-menu

Az új bővíthetőségi pontok használatához egyszerűen adjon hozzá egy új kiegészítést, amely azokat célozza az Azure DevOps-bővítmény jegyzékfájljában.

Például:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Az eredmény a következő lesz:

• Egyéni gomb a csővezeték fejlécében

  

• Egyéni menü egy folyamatmappában

  

Továbbfejlesztett migrálás az Azure DevOps Servicesbe

Az Azure DevOps Serverről az Azure DevOps Servicesbe történő importálás futtatásakor figyelembe kell vennie, hogy az Azure DevOps már nem támogatja a folyamatonkénti adatmegőrzési szabályokat. Ezzel a frissítéssel eltávolítottuk ezeket a szabályzatokat, amikor a helyszíni Azure DevOps Serverről migrál az Azure DevOps Services szolgáltatásba. A megőrzési szabályzatok konfigurálásával kapcsolatos további információkért tekintse meg a buildekre, kiadásokra és tesztekre vonatkozó adatmegőrzési szabályzatok beállításáról szóló dokumentációt.

A futó csővezetékek REST API-jának fejlesztése

Korábban a Pipelines Runs REST API csak az adattárat self adja vissza. Ezzel a frissítéssel a Pipelines Runs REST API visszaadja egy build összes adattár-erőforrását.

A kiterjesztett YAML-folyamatok sablonjai mostantól átadhatók a fázisokra, feladatokra és üzembe helyezésekre vonatkozó környezeti információknak

Ezzel a frissítéssel új tulajdonságot templateContext adunk hozzá a jobsablonokkal együtt használni kívánt YAML deployment- és stage YAML-folyamatösszetevőkhöz.

Az alábbiakban a következő forgatókönyvet használjuk templateContext:

• Sablonokkal csökkentheti a kódismétlődést, vagy javíthatja a folyamatok biztonságát

• A sablon paraméterként egy stages, jobs vagy deployments listát vesz fel

• A sablon feldolgozza a bemeneti listát, és végrehajt néhány átalakítást az egyes fázisokon, feladatokon vagy üzembe helyezéseken. Beállítja például azt a környezetet, amelyben az egyes feladatok futnak, vagy további lépéseket is hozzáad a megfelelőség kikényszerítéséhez

• A feldolgozáshoz a folyamat szerzőjének további információkat kell továbbítania a sablonba a listában szereplő egyes fázisokhoz, feladatokhoz vagy üzembe helyezésekhez

Lássunk egy példát. Tegyük fel, hogy olyan folyamatot hoz létre, amely a lekéréses kérelmek érvényesítéséhez végpontok közötti teszteket futtat. A cél a rendszer egyetlen összetevőjének tesztelése, de mivel a végpontok közötti tesztek futtatását tervezi, olyan környezetre van szüksége, ahol a rendszer összetevői közül több elérhető, és meg kell adnia azok viselkedését.

Tisztában kell lennie azzal, hogy más csapatoknak is hasonló igényeik lesznek, ezért úgy dönt, hogy a környezet sablonként való beállításának lépéseit fogja kinyerni. A kód a következőhöz hasonlóan néz ki:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

A sablon az, hogy a testSet paraméter minden feladatához beállítja a ${{ testJob.templateContext.requiredComponents }} által megadott rendszerösszetevők válaszát a ${{ testJob.templateContext.expectedHTTPResponseCode }} visszaadásához.

Ezután létrehozhat egy saját csővezetéket, amely kiterjeszti a(z) testing-template.yml-t, mint az alábbi példa mutatja.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Ez a csővezeték két tesztet futtat, egy pozitívat és egy negatívat. Mindkét teszthez elérhetővé kell tenni az dimensionsapi összetevőt. A positive_test feladat a dimensionsapi HTTP 200 kódot várja, míg a negative_test a HTTP 500 kódot várja.

Csoport által felügyelt szolgáltatásfiókok támogatása ügynökszolgáltatás-fiókként

Az Azure Pipelines-ügynök mostantól támogatja a windowsos , saját üzemeltetésű ügynökök csoportos felügyelt szolgáltatásfiókjait.

A csoportosan felügyelt szolgáltatásfiókok központi jelszókezelést biztosítanak a szolgáltatásfiókként működő tartományi fiókokhoz. Az Azure Pipelines-ügynök képes felismerni ezt a fióktípust, hogy a konfiguráció során ne legyen szükség jelszóra:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Információs futások

Egy információs futtatás azt jelzi, hogy az Azure DevOps nem tudta lekérni egy YAML-folyamat forráskódját. Az ilyen futtatás a következőképpen néz ki.

Az Azure DevOps lekéri egy YAML-folyamat forráskódját külső eseményekre, például leküldéses véglegesítésre vagy belső eseményindítókra válaszul, például annak ellenőrzéséhez, hogy vannak-e kódmódosítások, és elindít egy ütemezett futtatást, vagy sem. Ha ez a lépés sikertelen, a rendszer létrehoz egy információs futtatás. Ezek a futtatások csak akkor jönnek létre, ha a folyamat kódja Egy GitHub- vagy BitBucket-adattárban található.

A folyamat YAML-kódjának beolvasása a következő miatt meghiúsulhat:

• Az adattárszolgáltató üzemkimaradást tapasztal
• Kérelem korlátozása
• Hitelesítési problémák
• Nem sikerült lekérni a folyamat .yml fájljának tartalmát

További információ az információs futtatásokról.

A build definíció REST API tulajdonsága retentionRules elavult.

A Build Definition REST API választípusában BuildDefinition a retentionRules tulajdonság elavultként van megjelölve, mivel ez a tulajdonság mindig üres készletet ad vissza.

Repos

Új TFVC-lapok

Az Azure DevOps különböző lapjait frissítettük egy új webplatform használatára azzal a céllal, hogy a felhasználói élmény konzisztensebbé és akadálymentesebbé váljon a különböző szolgáltatásokban. A TFVC-oldalak frissültek az új webplatform használatára. Ezzel a verzióval általánosan elérhetővé tesszük az új TFVC-lapokat.

Adattár letiltása

Az ügyfelek gyakran kérték, hogy tiltsa le az adattárat, és ne férhessenek hozzá a felhasználók a tartalmaihoz. Ezt például a következő esetekben érdemes elvégeznie:

• Talált egy titkos kulcsot az adattárban.
• Egy külső ellenőrző eszköz úgy találta, hogy egy adattár nem felel meg a megfelelőségnek.

Ilyen esetekben érdemes lehet ideiglenesen letiltani az adattárat, amíg a probléma megoldásán dolgozik. Ezzel a frissítéssel letilthatja az adattárakat, ha rendelkezik törlési adattár-engedélyekkel . Az adattár letiltása esetén:

• Listázhatja az adattárat az adattárak listájában
• Nem olvasható be az adattár tartalma
• Az adattár tartalma nem frissíthető
• Üzenet arról, hogy az adattár le lett tiltva, amikor megpróbálják elérni az adattárat az Azure Repos felhasználói felületén

A szükséges kockázatcsökkentési lépések elvégzése után a Törlési adattár engedéllyel rendelkező felhasználók újra engedélyezhetik az adattárat. Az adattárak letiltásához vagy engedélyezéséhez lépjen a Projektbeállítások lapra, válassza az Adattárak lehetőséget, majd az adott adattárat.

Konfigurálja az ágak létrehozóit úgy, hogy ne kapják meg az „Engedélyek kezelése“ jogosultságot az ágaikon.

Amikor új ágat hoz létre, az adott ágon megjelenik az "Engedélyek kezelése" kifejezés. Ezzel az engedéllyel módosíthatja más felhasználók engedélyeit, vagy beengedhet további felhasználókat, hogy hozzájáruljanak az adott ághoz. Egy ág létrehozója például ezt az engedélyt arra használhatja, hogy egy másik külső felhasználó módosítsa a kódot. Vagy engedélyezhetik, hogy egy folyamat (szolgáltatásadentitás összeállítása) módosítsa a kódot az adott ágban. Bizonyos, magasabb megfelelőségi követelményekkel rendelkező projektekben a felhasználók nem végezhetnek ilyen módosításokat.

Ezzel a frissítéssel konfigurálhatja a csapatprojekt összes adattárát, és korlátozhatja az ág létrehozói számára az "Engedélyek kezelése" engedélyt. Ehhez keresse meg a projektbeállításokat, válassza az Adattárak, majd az összes adattár vagy egy adott adattár beállításai lehetőséget.

Ez a beállítás alapértelmezés szerint be van kapcsolva a meglévő viselkedés utánzásához. De kikapcsolhatja, ha használni szeretné ezt az új biztonsági funkciót.

Érd el, hogy a forkolt adattár felhasználók ne tudjanak szavazni az eredeti PR-ekre

Az Azure-adattárakban "olvasási" engedéllyel rendelkező felhasználók forkolhatják az adattárat, és módosításokat végezhetnek a forkolt adattárban. Ahhoz, hogy egy lekéréses kérelmet elküldhessenek a felsőbb rétegbe való módosításokkal együtt, a felhasználóknak "közreműködésre van szükségük a lekéréses kérelmekhez" engedélyre a felsőbb rétegben. Ez az engedély azonban azt is szabályozza, hogy ki szavazhat a lekéréses kérelmekre a felsőbb rétegbeli adattárban. Ennek eredményeképpen olyan helyzetekbe kerülhet, amikor egy felhasználó, aki nem közreműködője az adattárnak, elküldhet egy lekéréses kérelmet, és a fiókszabályzatok beállításától függően egyesítheti azt.

A belső forráskód-modellt előléptető projektekben a fork- és közreműködés gyakori minta. A minta további védelme és előmozdítása érdekében módosítjuk a lekéréses kérelmekre vonatkozó szavazati engedélyt a "hozzájárulás a lekéréses kérelmekhez" formából a "hozzájárulás" formára. Ez a módosítás azonban alapértelmezés szerint nem minden projektben történik. Az engedély váltásához be kell jelentkeznie, és ki kell választania egy új szabályzatot az adattárban, "Szigorú szavazási mód" néven. Javasoljuk, hogy ezt tegye, ha az Azure Repos-ban lévő forkokra támaszkodik.

Jelentéskészítés

A diagram widgetjeiben elérhető címkék szerinti csoportosítás

A Csoportosítás címkék szerint diagram widget alapértelmezés szerint minden ügyfél számára elérhető. A diagram widget használata esetén mostantól elérhető egy lehetőség a címkékhez. A felhasználók az összes címkét vagy címkekészletet kiválasztva jeleníthetik meg az adataikat a widgetben.

Egyéni munkaelemtípusok megjelenítése a burndown widgetben

Korábban nem láthatta az égésdiagram widgetben konfigurált egyéni munkaelem-típusokat, valamint egy egyéni mező alapján összesített vagy megszámolt elemeket. Ezzel a frissítéssel kijavítottuk a problémát, és most már egyéni munkaelem-típusok is megjelennek a leégetési diagramon.

---

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.

---

Az oldal teteje