Az Azure DevOpsServer 2020 1. frissítésének kibocsátási megjegyzései

fejlesztői közösség | rendszerkövetelményei | Licencfeltételek | DevOps Blog | SHA-1 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 Azure DevOps Server-követelmények. Az Azure DevOps-termékek letöltéséhez látogasson el az Azure DevOps Server Letöltések oldalára.

Az Azure DevOps Serverre való közvetlen frissítést az Azure DevOps Server 2020, az Azure DevOps Server 2019 vagy a Team Foundation Server (TFS) 2015 vagy újabb verzió támogatja. Ha a TFS üzembe helyezése a TFS 2010-ben vagy korábbi verzióban történik, az Azure DevOps Server 2019-re való frissítés előtt végre kell hajtania néhány időközi lépést. További információ: Helyszíni Azure DevOps telepítése és konfigurálása.

---

Biztonságos frissítés az Azure DevOps Server 2019-ről az Azure DevOps Server 2020-ra

Az Azure DevOps Server 2020 egy új folyamatfuttatási (buildelési) adatmegőrzési modellt vezet be, amely projektszintű-beállítások alapján működik.

Az Azure DevOps Server 2020 eltérő módon kezeli a buildmegőrzést a folyamatszintű adatmegőrzési szabályzatok alapján. Bizonyos szabályzatkonfigurációk a frissítés után a folyamatfuttatások törléséhez vezetnek. A manuálisan megtartott vagy a kiadás által megtartott "pipeline" futtatások a frissítés után nem törlődnek.

A blogbejegyzésben további információt talál arról, hogyan frissíthet biztonságosan az Azure DevOps Server 2019-ről az Azure DevOps Server 2020-ra.

Azure DevOps Server 2020 Update 1.2 Patch 17 Kiadás dátuma: 2025. július 9.

Fájl	SHA-256 kivonat
devops2020.1.2patch17.exe	139D489FC8F9EF96069A956482FBA6153058704BB1F3C8AB3637D7ADC3A95C94

Az Azure DevOps Server 2020 1.2-es frissítéséhez kiadott 17-es javítással kijavítottunk egy null referenciakivételt a többadattár-eseményindító funkcióban, ha a YAML-folyamatban nincsenek definiálva erőforrás-adattárak.

Azure DevOps Server 2020 Update 1.2 Patch 16 Kiadás dátuma: 2025. április 8.

Fájl	SHA-256 kivonat
devops2020.1.2patch16.exe	0C60AF43C79EAF3FD5A91E3DA6D9218F262B33EFE13E7A69E2C2AB336F1920A5

Megjelent a Patch 16 for Azure DevOps Server 2020 Update 1.2, amely a következőket tartalmazza:

Fontos

A CDN-tartomány URL-címének módosítása a Pipelines-ügynökök blogjában a javítás telepítése előtt követendő lépéseket tartalmazza.

• Korábban az Azure DevOps-ügynök az Edgio CDN-t használta végponttal vstsagentpackage.azureedge.net. Edgio nyugdíjba vonulásának részeként a *.azureedge.net tartományt leszerelik. A folyamatos rendelkezésre állás biztosítása érdekében migráltunk egy Akamai által támogatott CDN-re egy új végponttal download.agent.dev.azure.com. Ez a javítás tartalmazza az ügynök bináris fájljainak lekéréséhez szükséges módosításokat az új CDN-végpontról, ezzel lehetővé téve az előző CDN-végpontról való migráció befejezését. (https://devblogs.microsoft.com/devops/important-switching-cdn-providers/) További részletekért.

• Frissített Hableány-verzió.

Azure DevOps Server 2020 Update 1.2 Patch 15 Kiadás dátuma: 2025. március 11.

Fájl	SHA-256 kivonat
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

Az Azure DevOps Server 2020 1.2-s frissítéséhez kiadott Patch 15 az alábbiakat tartalmazza:

• Az Edgio CDN elavulása miatti feladatok frissítése. További részletekért tekintse meg a CDN-szolgáltatók váltása blogbejegyzést.

Azure DevOps Server 2020 Update 1.2 Patch 14 Kiadás dátuma: 2024. november 12.

Fájl	SHA-256 kivonat
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Az Azure DevOps Server 2020 1.2-s frissítéséhez Patch 14 jelent meg, amely egy sebezhető függőségre való frissítést tartalmaz.

Azure DevOps Server 2020 Update 1.2 Patch 13 Kiadás dátuma: 2024. március 12.

Fájl	SHA-256 kivonat
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Megjelent Patch 13 az Azure DevOps Server 2020 1.2-s frissítéséhez, amely az alábbi javításokat tartalmazza:

• Megoldotta azt a hibát, amely miatt a proxykiszolgáló a 12. javítás telepítése után leállt.

Azure DevOps Server 2020 Update 1.2 Patch 12 Kiadás dátuma: 2024. február 13.

Fájl	SHA-256 kivonat
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Megjelent Patch 12 az Azure DevOps Server 2020 1.2-s frissítéséhez, amely az alábbi javításokat tartalmazza:

• 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 2020 Update 1.2 Patch 11 Kiadás dátuma: 2023. december 12.

Fájl	SHA-256 kivonat
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Az Azure DevOps Server 2020 1.2-s frissítéséhez Patch 11 jelent meg, amely az alábbi javításokat tartalmazza:

• Kijavítottunk egy hibát, amely miatt az üzembe helyezés előtti jóváhagyás biztonsági öröklése nem működött a csővezetékek szakaszaiban.

Azure DevOps Server 2020 Update 1.2 Patch 10 Kiadás dátuma: 2023. november 14.

Közzétettünk egy javítást az Azure DevOps Server 2020 1.2-s frissítéséhez, amely az alábbi javításokat tartalmazza.

• Kibővítették a PowerShell feladatok által engedélyezett karakterek listáját , hogy engedélyezzék a rendszerhéj-feladatok argumentumainak paraméterérvényesítését.

Jegyzet

A javítások megvalósításához több lépést kell követnie a feladatok manuális frissítéséhez.

Javítások telepítése

Fontos

Az Azure Pipelines-ügynök frissítéseit 2023. szeptember 12-én adtuk ki a Patch 8 kiadásával. Ha nem telepítette az ügynökfrissítéseket a 8-kiadási megjegyzéseiben leírtak szerint, javasoljuk, hogy telepítse ezeket a frissítéseket a 10. javítás telepítése előtt. A 8. javítás telepítése után az ügynök új verziója 3.225.0 lesz.

TFX konfigurálása

1. Kövesse a feltöltési feladatok lépéseit a projektgyűjtemény dokumentációjában, hogy telepítse és bejelentkezzen a tfx-cli használatával.

Feladatok frissítése A TFX használatával

Fájl	SHA-256 kivonat
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Töltse le és bontsa ki Tasks20231103.zip.
2. Módosítsa a könyvtárat a kinyert fájlokra.
3. Hajtsa végre a következő parancsokat a feladatok feltöltéséhez:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Folyamatkövetelmények

Az új viselkedés használatához egy változót AZP_75787_ENABLE_NEW_LOGIC = true kell beállítani az érintett tevékenységeket használó folyamatokban.

• Klasszikusokról:

  Definiálja a változót a pipeline változók lapján.

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 9 Kiadás dátuma: 2023. október 10.

Fontos

Az Azure Pipelines-ügynök frissítéseit 2023. szeptember 12-én adtuk ki a Patch 8 kiadásával. Ha nem telepítette az ügynökfrissítéseket a kiadási megjegyzésekben leírtak szerint a 8. javításhoz, javasoljuk, hogy telepítse ezeket a frissítéseket a 9. javítás telepítése előtt. A 8. javítás telepítése után az ügynök új verziója 3.225.0 lesz.

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

• Kijavítottunk egy hibát, amely miatt az "Analysis Owner" identitás inaktív identitásként jelenik meg a javításfrissítési gépeken.

Azure DevOps Server 2020 Update 1.2 Patch 8 Kiadás dátuma: 2023. szeptember 12.

Közzétettünk egy javítást az Azure DevOps Server 2020 1.2-s frissítésé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.

Fontos

Telepítse a javítást egy tesztkörnyezetben, és győződjön meg arról, hogy a környezet folyamatai a várt módon működnek, mielőtt a javítást éles környezetben alkalmazták volna.

Jegyzet

A frissítés javításainak megvalósításához több lépést kell követnie, hogy manuálisan frissítse az ügynököt és a feladatokat.

Javítások telepítése

1. Töltse le és telepítse az Azure DevOps Server 2020 Update 1.2 patch 8.

Az Azure Pipelines-ügynök frissítése

1. Töltse le az ügynököt a következő forrásból: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Az ügynök üzembe helyezéséhez használja az saját üzemeltetésű Windows-ügynökök dokumentációjában ismertetett lépéseket.  

Jegyzet

Az AZP_AGENT_DOWNGRADE_DISABLED értékét "true"-ra kell állítani, hogy megakadályozza az ügynök leminősítését. Windows rendszeren a következő parancs használható egy felügyeleti parancssorban, amelyet újraindítás követ. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX konfigurálása

1. Kövesse a feltöltési feladatok lépéseit a projektgyűjtemény dokumentációjában, hogy telepítse és bejelentkezzen a tfx-cli használatával.

Feladatok frissítése A TFX használatával

1. Töltse le és bontsa ki Tasks_20230825.zip.
2. Módosítsa a könyvtárat a kinyert fájlokra.
3. Hajtsa végre a következő parancsokat a feladatok feltöltéséhez:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Folyamatkövetelmények

Az új viselkedés használatához egy változót AZP_75787_ENABLE_NEW_LOGIC = true kell beállítani az érintett tevékenységeket használó folyamatokban.

• Klasszikusokról:

  Definiálja a változót a pipeline változók lapján.

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 7 Kiadás dátuma: 2023. augusztus 8.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-36869: Azure DevOps Server hamisítási biztonsági rés.
• Frissítse az SSH szolgáltatást az SHA2-256 és az SHA2-512 támogatásához. Ha az RSA használatára keményen kódolt SSH-konfigurációs fájlokat használ, frissítsen SHA2-re, vagy távolítsa el a bejegyzést.
• Elhárítottuk a markdown-fájlokban nem működő relatív hivatkozások problémáját.
• Kijavítottunk egy hibát a megjegyzés-navigációval egy véglegesítési oldalon.
• 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 2020 Update 1.2 Patch 6 Kiadás dátuma: 2023. június 13.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-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, amely megzavarta a csomagok leküldését a 2018-ról vagy korábbi verzióról való frissítéskor.
• 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 2020 Update 1.2 Patch 5 Kiadás dátuma: 2023. február 14.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• CVE-2023-21553: Az Azure DevOps Server távoli kódvégrehajtási biztonsági rése
• Kijavítottuk a polckészletek elérhetőségi problémáját a webes felhasználói felületen keresztül.
• Az ügyfeleknek újra kell indítaniuk a tfsjobagent szolgáltatást és az Azure DevOps Server alkalmazáskészletet, miután frissítették az SMTP-sel kapcsolatos beállítást az Azure DevOps Server Felügyeleti konzolon.

Azure DevOps Server 2020 Update 1.2 Patch 4 Kiadás dátuma: 2022. december 13.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• A speciális karakterek rögzített megjelenítése az IdentityPickerben.

• 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.

Azure DevOps Server 2020 Update 1.2 Patch 3 Kiadás dátuma: 2022. október 18.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• Megoldhatja a biztonsági párbeszédpanel identitásválasztóiban nem megjelenő újonnan hozzáadott AD-identitásokkal kapcsolatos problémát.
• Kijavítottuk a csoporttag által kért szűrővel kapcsolatos hibát a webes horogbeállításokban.
• Kijavítottuk a Gated check-in build hibát, ha a szervezeti beállításoknál a folyamat feladat-engedélyezési hatóköre a nem kiadási folyamatok aktuális projektjére lett korlátozva.
• Kijavíthatja a hozzáférési jogkivonat Azure-ból való lekérését a hitelesített proxy mögötti szolgáltatáskapcsolat létrehozásakor.

Azure DevOps Server 2020 Update 1.2 Patch 2 Kiadás dátuma: 2022. augusztus 9.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• Identitásérték-hiba kijavítása munkaelem hozzárendelése közben egy különböző tartományokban megjelenő identitáshoz.

Azure DevOps Server 2020 Update 1.2 Patch 1 Kiadás dátuma: 2022. július 12.

Kiadottunk egy patch az Azure DevOps Server 2020 Update 1.2-hez, amely az alábbi javításokat tartalmazza.

• A tesztfuttatások API-jaiban a visszaadott folytatási token nagyobb volt, mint a megadott "maxLastUpdatedDate" érték.

Az Azure DevOps Server 2020 1.2-es frissítésének kiadási dátuma: 2022. május 17.

Azure DevOps Server 2020 Update 1.2 hibajavítások összesítője. Közvetlenül telepítheti az Azure DevOps Server 2020 1.2-s frissítését, vagy frissíthet az Azure DevOps Server 2020-ról vagy a Team Foundation Server 2013-ról vagy újabbról.

Jegyzet

Az adatmigrálási eszköz körülbelül három héttel a kiadás után elérhető lesz az Azure DevOps Server 2020 1.2-es frissítéséhez. Az importálási jelenleg támogatott verzióinak listáját itt láthatja.

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

• Az Azure DevOps Server 2020.1.2 letiltja az új (az Azure DevOps Server 2020-ban bevezetett) adatmegőrzési modellt, hogy megelőzze a folyamatfuttatások (buildek) elvesztését. Ez azt jelenti, hogy a rendszer:

  • A Server 2020 futtatása közben generált legutóbbi három build számára bérletek készítése
  • A YAML-folyamatok és a folyamatonkénti adatmegőrzési szabályzatok nélküli klasszikus folyamatok esetében a buildek a gyűjteményszintű maximális adatmegőrzési beállításoknak megfelelően maradnak meg
  • Az egyéni folyamatmegőrzési szabályzattal rendelkező klasszikus folyamatok esetében a buildek a folyamatspecifikus adatmegőrzési szabályzatnak megfelelően maradnak meg
  • A bérletes buildek nem számítanak bele a beállítások megőrzéséhez szükséges minimális értékbe.

• A módosítás- és mentett munkaterületi megjegyzésekhez tartozó hivatkozások nem lettek helyesen átirányítva. Amikor módosításkészletekben vagy polckészletekben lévő fájlokhoz adtak hozzá megjegyzéseket, a megjegyzések kijelölése nem a megfelelő helyre lett átirányítva a fájlnézetben.

• Nem lehet átugrani a felépítési sort a "Következő futtatása" gombbal. Korábban a "Tovább futtatása" gomb csak a projektgyűjtemény rendszergazdái számára lett engedélyezve.

• A felhasználói Active Directory-fiók letiltása után vonja vissza az összes személyes hozzáférési jogkivonatot.

Azure DevOps Server 2020.1.1 Patch 4 Kiadás dátuma: 2022. január 26.

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

• A rendszer nem küldött e-mail-értesítéseket, amikor a @mention vezérlőt használja egy munkaelemben.
• Az előnyben részesített e-mail-cím nem lett frissítve a felhasználói profilban. Ez azt eredményezte, hogy a rendszer az előző e-mail-címre küldött e-maileket.
• A fejléc nem jelenik meg a Projektösszegzés lapon. A fejléc néhány ezredmásodpercig látható volt, majd eltűnt.
• Az Active Directory felhasználói szinkronizálásának fejlesztése.
• Az Elasticsearch biztonsági rését úgy hárította el, hogy eltávolította a jndilookup osztályt a log4j bináris fájlokból.

Telepítési lépések

1. Frissítse a kiszolgálót a 4. javítócsomaggal.
2. Ellenőrizze a beállításjegyzék értékét a HKLM:\Software\Elasticsearch\Version. Ha a beállításjegyzék értéke nincs megadva, adjon hozzá egy sztringértéket, és állítsa a Verzió 5.4.1 értékre (Név = Verzió, Érték = 5.4.1).
3. Használja a frissítési parancsot PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update a readme fájlban megadott módon. A következőhöz hasonló figyelmeztetés jelenhet meg: Nem lehet csatlakozni a távoli kiszolgálóhoz. Ne zárja be az ablakot, mert a frissítés újrapróbálkozásokat végez, amíg be nem fejeződik.

Jegyzet

Ha az Azure DevOps Server és az Elasticsearch különböző gépekre van telepítve, kövesse az alábbi lépéseket.

1. Frissítse a kiszolgálót a 4. javítócsomaggal.
2. Ellenőrizze a beállításjegyzék értékét a HKLM:\Software\Elasticsearch\Version. Ha a beállításjegyzék értéke nincs megadva, adjon hozzá egy sztringértéket, és állítsa a Verzió 5.4.1 értékre (Név = Verzió, Érték = 5.4.1).
3. Másolja a C:\Program Files\{TFS Version Folder}\Search\zip helyen lévő zip nevű mappa tartalmát az Elasticsearch távoli fájlmappájába.
4. Futtassa a Configure-TFSSearch.ps1 -Operation update-at az Elasticsearch szerveren.

SHA-256 kivonat: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 kiadás dátuma: 2021. december 15.

3. javítás az Azure DevOps Server 2020.1.1-hez az alábbi javításokat tartalmazza.

• A "Szavakat tartalmaz" típusú lekérdezések munkaelem-makrójának javítása. Korábban a lekérdezések helytelen eredményeket adtak vissza a sortörést tartalmazó értékekhez.
• Növelje a Maven-csomag verziójának karakterhosszára vonatkozó korlátokat.
• Egyedi munkaelemek elrendezési állapotainak lokalizálási problémája.
• Honosítási probléma az e-mail-értesítési sablonban.
• Hiba a NOTSAMEAS-szabályok kiértékelésekor, ha több NOTSAMEAS-szabályt definiáltak egy mezőhöz.

Azure DevOps Server 2020.1.1 Patch 2 Kiadás dátuma: 2021. október 26.

Patch 2 for Azure DevOps Server 2020.1.1 az alábbi javításokat tartalmazza.

• Korábban az Azure DevOps Server csak a GitHub Enterprise Serverhez tudott kapcsolatot létesíteni. Ezzel a javítással a projektgazdák kapcsolatokat hozhatnak létre az Azure DevOps Server és a GitHub.com adattárai között. Ezt a beállítást a GitHub-kapcsolatok lapon találja Projektbeállításokalatt.
• A Tesztterv widgettel kapcsolatos probléma megoldása. A tesztvégrehajtási jelentés helytelen felhasználót mutatott az eredményeken.
• Kijavítottuk azt a hibát, amely miatt a Projekt áttekintése összefoglaló lap betöltése sikertelen volt.
• Kijavítottuk a termékfrissítés megerősítéséhez nem küldött e-mailek problémáját.

Azure DevOps Server 2020.1.1 Patch 1 Kiadás dátuma: 2021. szeptember 14.

Patch 1 for Azure DevOps Server 2020.1.1 az alábbi javításokat tartalmazza.

• Az összetevők letöltési/feltöltési hibájának javítása.
• Az inkonzisztens teszteredmény-adatokkal kapcsolatos probléma megoldása.

Az Azure DevOps Server 2020 1.1-es frissítésének kiadási dátuma: 2021. augusztus 17.

Azure DevOps Server 2020 Update 1.1 hibajavítások összesítője. Közvetlenül telepítheti az Azure DevOps Server 2020 1.1-s frissítését, vagy frissíthet az Azure DevOps Server 2020-ról vagy a Team Foundation Server 2013-ról vagy újabbról.

Jegyzet

Az adatmigrálási eszköz körülbelül három héttel a kiadás után elérhető lesz az Azure DevOps Server 2020 1.1-es frissítéséhez. Az importálási jelenleg támogatott verzióinak listáját itt láthatja.

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

Azure Boards

• Az értesítési e-mailekben található "Munkaelem megtekintése" hivatkozás nem a nyilvános URL-címet használja.

Azure-tárházak

• Kijavítottuk a korlátozott egyesítési típusok öröklési jelölőnégyzeteinek megjelenítését, hogy lehetővé tegyük a korlátozott egyesítési típusok módosítását a kereszt-repozitóriumi szabályzatok beállítása után.

Azure Pipelines

• Az Ügynökfrissítés beállításainak módosításakor a beállítások nem terjedtek át a környezet más alkalmazásszintjeire.

Általános

• Kijavítottuk a helyesírást a kiszolgálókonfigurációs varázslóban.
• Növelte a bővítménycsomag méretét, és lehetővé teszi a beállításjegyzék méretének módosítását.

Azure-tesztcsomagok

• Nem lehet vissza navigálni a teszteredményekhez, ha visszaüt az előzményekről az összefoglaló oldalra.

---

Azure DevOps Server 2020.1 2. javítás kiadási dátum: 2021. augusztus 10.

Kiadottunk egy patch az Azure DevOps Server 2020.1-hez, amely az alábbiakat javítja ki.

• Javítsa ki a builddefiníció felhasználói felületének hibáját.
• Módosította a böngészési előzményeket úgy, hogy a gyökéradattár helyett fájlok jelenjenek meg.

Azure DevOps Server 2020.1 Patch 1 Kiadás dátuma: 2021. június 15.

Kiadottunk egy patch az Azure DevOps Server 2020.1-hez, amely az alábbiakat javítja ki.

• Az engedélyezési folyamatokban, amelyek érvényesítik a SameSite=None-t, biztonságos cookie-kat használnak.

• Az Értesítések SDK-val kapcsolatos probléma megoldása. Korábban a területi útvonal szűrőt használó értesítési előfizetések nem voltak megfelelően elemezve.

Azure DevOps Server 2020.1 RTW kiadás dátuma: 2021. május 25.

Az Azure DevOps Server 2020.1 RTW újdonságainak összefoglalása

Az Azure DevOps Server 2020.1 RTW hibajavítások összesítője. A korábban kiadott Azure DevOps Server 2020.1 RC2 összes funkcióját tartalmazza. Azure DevOps Server 2020.1 RTW hibajavítások összesítője. Közvetlenül telepítheti az Azure DevOps Server 2020.1-et, vagy frissíthet az Azure DevOps Server 2020, 2019 vagy Team Foundation Server 2015 vagy újabb verziójáról.

Jegyzet

Az adatmigrálási eszköz körülbelül három héttel a kiadás után elérhető lesz az Azure DevOps Server 2020 1. frissítéséhez. Az importálási jelenleg támogatott verzióinak listáját itt láthatja.

Az Azure DevOps Server 2020.1 RC2 kiadási dátuma: 2021. április 13.

Az Azure DevOps Server 2020.1 RC2 újdonságainak összefoglalása

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

Azure DevOps Server 2020.1 RC1 kiadás dátuma: 2021. március 23.

Az Azure DevOps Server 2020.1 RC1 újdonságainak összefoglalása

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

• Táblák állapotváltási korlátozó szabályai
• Az érdekelt felek mostantól áthelyezhetik a munkaelemeket a táblaoszlopok között
• A kiadás biztonságának javítása a hozzáférési jogkivonatok hatókörének korlátozásával
• Továbbfejlesztett pull request élmény
• Több adattárú eseményindítók a Pipeline-okban

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

• táblák
• tárházak
• csővezetékek
• Tárgyak

---

Deszkák

Állapotátmenet korlátozó szabályok

Továbbra is lezárjuk a szolgáltatás paritási rését az üzemeltetett XML és az örökölt folyamatmodell között. Ez az új munkaelemtípus-szabály lehetővé teszi, hogy korlátozza a munkaelemek egyik állapotból a másikba való áthelyezését. Korlátozhatja például, hogy a Bugs státusza az Újról Megoldottra változzon. Ehelyett Újról –> Aktívra –> Megoldottra kell váltaniuk

Létrehozhat egy szabályt is, amely korlátozza az állapotváltásokat csoporttagság alapján. Például csak a "Jóváhagyók" csoportban lévő felhasználók helyezhetik át a felhasználói történeteket az Új –> Jóváhagyva csoportból.

Munkaelem másolása gyermekek másolásához

Az Azure Boards egyik legfontosabb kért funkciója, hogy átmásoljon egy olyan munkaelemet, amely a gyermekmunkaelemeket is átmásolja. Új beállítást adtunk hozzá a "Gyermekmunkaelemek belefoglalása" lehetőséghez a munkaelem másolása párbeszédpanelen. Ha be van jelölve, ez a beállítás másolja a munkaelemet, és az összes gyermekmunkaelemet (legfeljebb 100) másolja.

Továbbfejlesztett szabályok aktivált és feloldott mezőkhöz

Eddig a által aktiválva, aktiválás dátuma, által megoldva és megoldás dátuma szabályai rejtély voltak. Ezek csak a rendszer munkaelem-típusaihoz vannak beállítva, és az "Aktív" és a "Feloldott" állapotértékre vonatkoznak. Módosítottuk a logikát, így ezek a szabályok már nem egy adott állapotra vonatkoznak. Ehelyett a kategória (állapotkategória) aktiválja őket, amelyben az állapot található. Például tegyük fel, hogy van egy "Tesztelésre van szükség" nevű egyéni állapot a Feloldott kategóriában. Amikor a munkaelem "Aktív" értékről "Tesztelésre van szükség" értékre változik, az megoldásért felelős és a megoldási dátum szabályok aktiválódnak.

Ez lehetővé teszi az ügyfelek számára, hogy egyéni állapotértékeket hozzanak létre, és továbbra is létrehozzák az Aktiválva, Aktivált dátum, Feloldva, és Feloldott dátum mezőket anélkül, hogy egyéni szabályokat kellene használniuk.

Az érdekelt felek áthelyezhetik a munkaelemeket a táblaoszlopok között

Az érdekelt felek mindig meg tudták változtatni a munkaelemek állapotát. De amikor a Kanban táblára kerülnek, nem tudják áthelyezni a munkaelemeket az egyik oszlopból a másikba. Ehelyett az érdekelt feleknek egyenként kell megnyitniuk az egyes munkaelemeket, és frissíteniük kell az állapotértéket. Ez már régóta fájdalompont az ügyfelek számára, és örömmel jelentjük be, hogy most már áthelyezheti a munkaelemeket a táblák oszlopai között.

Rendszerelem típusok a feladatlistákon és táblákon

Ezután hozzáadhat egy rendszermunkaelem típust a választott hátralék szintjéhez. Ezek a munkaelemtípusok korábban csak lekérdezésekből voltak elérhetők.

Folyamat	Munkaelem típusa
Agilis	Kérdés
Scrum	Akadály
CMMI	Kérelem módosítása
	Kérdés
	Értékelés
	Kockázat

A rendszer munkaelemtípusának hozzáadása a hátralékszinthez egyszerű. Egyszerűen lépjen az egyéni folyamatba, és kattintson a Hátralékszintek fülre. Válassza ki a kívánt hátralékszintet (például: Követelmények Hátralék), és válassza a szerkesztés opciót. Ezután adja hozzá a munkaelem típusát.

Azure Boards GitHub alkalmazás adattárkorlátjának megemelése

A GitHub-piactéren Azure Boards-alkalmazás adattárkorlátja 100-ról 250-re nőtt.

A munkaelem állapotának testreszabása a lekéréses kérelem egyesítésekor

Nem minden munkafolyamat azonos. Egyes ügyfelek egy lekéréses kérelem befejezésekor bezárják a kapcsolódó munkaelemeket. Mások egy másik állapotba szeretnék állítani a munkaelemeket, amelyeket a zárás előtt ellenőrizni szeretne. Mindkettőt engedélyeznünk kell.

Új funkciónk lehetővé teszi, hogy a munkaelemeket a kívánt állapotba állítsa a lekéréses kérelem egyesítésekor és befejezésekor. Ahhoz, hogy ezt megtegyük, átvizsgáljuk a lekéréses kérelem leírását, és megkeressük az állapotértéket, majd a munkaelem(ek) #mentionjét. Ebben a példában két felhasználói történetet állítunk be megoldottra, és két feladatot zárunk le.

A munkaelem csatolása egy másik projektben lévő buildekhez

Mostantól egyszerűen nyomon követheti a buildfüggőségeket a projekten belül, ha a munkaelemet egy buildhez, a buildben találthoz vagy a buildbe integrálthoz csatolja.

munkaelemek összekapcsolása

Szerkesztési leírás (súgószöveg) a rendszermezőkön

Az egyéni mezők leírását mindig is szerkesztheti. Az olyan rendszermezők esetében, mint a prioritás, a súlyosság és a tevékenység, a leírás nem szerkeszthető. Ez egy funkcióbeli eltérés volt a üzemeltetett XML és az örökölt között, amely megakadályozta, hogy egyes ügyfelek áttelepüljenek az örökölt modellre. Most már szerkesztheti a leírást a rendszermezőkben. A szerkesztett érték csak a folyamat ezen mezőjére és az adott munkaelemtípusra lesz hatással. Ez lehetővé teszi, hogy a különböző munkaelem-típusok ugyanazon mezőjéhez különböző leírások tartoznak.

A munkaelem állapotának testreszabása a lekéréses kérelem egyesítésekor

A lekéréses kérelmek gyakran több munkaelemre hivatkoznak. Amikor pull requestet hoz létre vagy frissít, előfordulhat, hogy be kell zárnia néhányat, fel kell oldania néhányat, és nyitva kell tartania a többit. Ehhez most már használhat megjegyzéseket, például az alábbi ábrán látható megjegyzéseket. További részletekért tekintse meg dokumentációját.

Szülőmező a tevékenységtáblán

A népszerű kérés miatt mostantól hozzáadhatja a Szülő mezőt a feladattábla gyermek- és szülőkártyáihoz is.

A "Hozzárendelt" szabály eltávolítása a Hiba munkaelemtípuson

Az Agile, a Scrum és a CMMI különböző munkaelem-típusai között számos rejtett rendszerszabály található. Ezek a szabályok már több mint egy évtizede léteznek, és általában panasz nélkül is jól működtek. Azonban van néhány szabály, amely már idejétmúlt. Az egyik szabály különösen sok fájdalmat okozott az új és a meglévő ügyfelek számára, és úgy döntöttünk, hogy ideje eltávolítani. Ez a szabály az Agilis folyamat hiba munkaelemtípusában létezik.

Állítsa be a Hozzárendelt értéket Létrehozóra, amikor az állapot Feloldott-ra változik.

Sok visszajelzést kaptunk erről a szabályról. Válaszul eltávolítottuk ezt a szabályt az Agilis folyamat Hiba munkaelemtípusából. Ez a változás minden projektet érint, amely egy örökölt Agilis vagy egy testreszabott öröklött Agile-folyamatot használ. Azoknak az ügyfeleknek, akik kedvelik és függenek az aktuális szabálytól, javasoljuk, hogy tekintsék meg blogbejegyzésünket, amelyben leírjuk azokat a lépéseket, amelyeket megtehetnek a szabály egyéni szabályok használatával történő ismételt hozzáadásához.

Elemek eltávolítása a Munkaelemek lapon

A Munkaelemek lap nagyszerű hely a létrehozott vagy önhöz rendelt elemek gyors megkeresésére, többek között. Számos személyre szabott pivot táblázatot és szűrőt biztosít. A "Hozzám rendelve" fül egyik leggyakoribb panasza, hogy eltávolított munkaelemeket (azaz eltávolított állapotú munkaelemeket) jelenít meg. És egyetértünk! Az eltávolított elemek olyan feladatok, amelyek már nem számítanak értéknek, ezért el lettek távolítva a hátralékból, így az ebben a nézetben való szerepeltetésük nem hasznos.

Most már elrejtheti az összes eltávolított elemet a Hozzám rendelt nézetből a Munkaelemek oldalon.

Repos

Alapértelmezett ág nevének beállítása

Az Azure Repos mostantól testre szabható alapértelmezett ágnevet kínál a Git számára. Az adattár beállításai között választhat bármilyen jogi ágnevet, amelyet az adattár inicializálásakor használ. Az Azure-adattárak mindig támogatták egy meglévő adattár alapértelmezett ágnevének módosítását.

További információ: Ágak kezelése és Az alapértelmezett ágmódosítása.

Szervezeti szintű beállítás az alapértelmezett ághoz

Most már van egy gyűjteményszintű beállítás az előnyben részesített kezdeti ágnévhez az új adattárakhoz. Ha egy projekt nem választott kezdeti ágnevet, akkor a rendszer ezt a szervezeti szintű beállítást fogja használni. Ha nem adta meg a kezdeti ágnevet a szervezeti beállításokban vagy a projektbeállításokban, akkor az új adattárak az Azure DevOps által definiált alapértelmezett értéket fogják használni.

Új hitelesítési hatókör hozzáadása a pr-megjegyzésekhez való hozzájáruláshoz

Ez a kiadás új OAuth-hatókört ad hozzá a lekéréses kérelmek megjegyzéseinek olvasásához/írásához. Ha olyan robottal vagy automatizálással rendelkezik, amelynek csak megjegyzéseket kell kezelnie, akkor csak ezzel a hatókörrel adhat hozzá PAT-t. Ez a folyamat csökkenti a robbanás sugarát, ha az automatizálás hibás, vagy ha a jogkivonat kompromittálódott.

Pull Request felhasználói élmény fejlesztései

Az új lekéréses kérelem felülete a következőkkel lett továbbfejlesztve:

• Az opcionális ellenőrzések láthatóbbá tétele

Az ügyfelek opcionális ellenőrzésekkel felhívják a fejlesztők figyelmét a lehetséges problémákra. Az előző tapasztalatok szerint nyilvánvaló volt, hogy ezek az ellenőrzések sikertelenek. Az előzetes verzióban azonban ez nem így van. A szükséges ellenőrzéseken egy nagy, zöld pipa elrejti az opcionális ellenőrzések kudarcait. A felhasználók csak az ellenőrzőpanel megnyitásával fedezhették fel, hogy az opcionális ellenőrzések sikertelenek. A fejlesztők ezt gyakran nem teszik meg, ha nincs jelezve a probléma. Ebben az üzembe helyezésben láthatóbbá tettük az opcionális ellenőrzések állapotát az összegzésben.

• Ctrl+kattintás a menüelemekre

A PR lapmenüi nem támogatták a Ctrl-kattintást. A felhasználók gyakran nyitnak meg új böngészőlapokat, amikor áttekintik a lekéréses kérelmeket. Ezt kijavítottuk.

• [+] széljegyzet helye

A lekéréses kérelemben lévő fájlok falistája egy [+] jegyzetet jelenít meg, amely segít a szerzőknek és a véleményezőknek az új fájlok azonosításában. Mivel a széljegyzet a három pont után volt, a hosszabb fájlnevek esetében gyakran nem volt látható.

• PR-frissítések legördülő menüje visszanyeri az időzítési információkat

A frissítés kiválasztásához és a PR fájlok összehasonlításához használt legördülő menü elvesztette az előnézeti felület egyik fontos elemét. Nem jelenik meg, amikor a frissítés történt. Ezt kijavítottuk.

• **Továbbfejlesztett megjegyzésszűrő elrendezés **

Amikor egy lekéréses kérelem összefoglaló lapján szűri a megjegyzéseket, a legördülő lista a jobb oldalon volt, de a szöveg balra lett igazítva. Ezt kijavítottuk.

• Navigáció szülői commitekhez

A Véglegesítések lapon összehasonlíthatja az adott véglegesítésben végrehajtott módosításokat a szülő véglegesítésével. Előfordulhat azonban, hogy a szülő commitre szeretne navigálni, és részletesebben megérteni, hogy ez a commit miben különbözik a saját szülő commitjától. Erre gyakran van szükség, ha meg szeretné ismerni a kiadás összes módosítását. Hozzáadtunk egy szülőkártyát egy véglegesítéshez, hogy segítsünk ennek elérésében.

• Több hely a hosszú nevű mappák és fájlok számára a PR-fájlok lapon

A hosszú nevű mappákat és fájlokat a fájlfa vízszintes térközének hiánya miatt levágták. A fa behúzásának módosításával, hogy az igazodjon a gyökércsomóponthoz, és a hárompont gomb elrejtésével, amit csak akkor jelenítünk meg, ha fölé viszik az egeret, némi további helyet nyertünk a fán.

Az új fájlfa képe:

Kép a fájlfáról, amikor egy könyvtár fölé viszi az egérmutatót:

• A görgetési pozíció megőrzése a PR fájlok fülön lévő diff panel átméretezésekor

Ha átméretezi az egymás melletti diff panelt a PR-fájlok lapon, a felhasználó görgetési helye elveszik. Ez a probléma már ki lett javítva; a felhasználó görgetési helye mostantól megmarad a diff panel átméretezésén.

• Véglegesítés keresése mobileszközön

Amikor mobileszközön tekinti meg a Véglegesítések lapot, a keresőmező hiányzik az új felületen. Ennek eredményeképpen nehéz megtalálni egy commitot a hash alapján, és megnyitni. Ezt már kijavítottuk.

• Továbbfejlesztett helyhasználat az új PR-fájl diff mobilnézetének

Frissítettük ezt az oldalt, hogy jobban kihasználjuk a helyet, így a felhasználók több fájlt láthatnak mobilnézetben, ahelyett hogy a képernyőt 40%-ban egy fejléc foglalná el.

• Továbbfejlesztett képek pr-összefoglaló nézetben

A PR-ben szerkesztett képek nem jelentek meg az összefoglaló nézetben, de helyesen jelentek meg a fájlok nézetben. Ezt a problémát megoldottuk.

• Továbbfejlesztett ági élmény új PR létrehozásakor

A frissítés előtt ez a felület nem volt ideális, mivel a összehasonlítása ág helyett az adattár alapértelmezett ágával hasonlítaná össze a módosításokat.

Csővezetékek

További ügynökplatform: ARM64

Hozzáadtuk a Linux/ARM64 rendszert az Azure Pipelines-ügynök által támogatott platformok listájához. Bár a kódmódosítások minimálisak voltak, sok kulisszák mögötti munkát kellett először elvégezni, és örömmel jelentjük be a kiadását!

Címkeszűrő támogatás csővezeték erőforrásokhoz

Most hozzáadtunk "címkéket" a YAML-folyamatokhoz. Címkék használatával beállíthatja, hogy a CI-folyamat fusson, vagy mikor aktiválja automatikusan.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

A fenti kódrészlet azt mutatja, hogy címkék használatával határozható meg a CI (folyamatos integrációs) folyamat alapértelmezett verziója, amely akkor fut, ha a CD (folyamatos üzembe helyezés) folyamatfuttatását nem más forrás/erőforrás vagy ütemezett futtatási eseményindító aktiválja.

Amennyiben például egy olyan ütemezett eseményindítót állított be a CD-folyamathoz, amelyet csak akkor szeretne futtatni, ha a CI rendelkezik a production címkével, az eseményindítók szakaszában található címkék biztosítják, hogy a CD-folyamatot csak akkor indítják el, ha a CI befejezési eseménye teljesíti a címkézési feltételt.

Az engedélyezett feladatok szabályozása a csővezetékekben

Mostantól letilthatja a Marketplace-feladatokat. Néhányan engedélyezhetik a Marketplace-bővítményeket, de nem a velük járó Pipelines feladatokat. Az még nagyobb ellenőrzés érdekében lehetővé tesszük az összes dobozban lévő feladat önálló letiltását is (kivéve a checkout-ot, amely különleges művelet). Ha mindkét beállítás engedélyezve van, a pipeline-ban csak azok a feladatok futtathatók, amelyeket a tfxsegítségével töltöttek fel. Első lépésként keresse fel a https://dev.azure.com/<your_org>/_settings/pipelinessettings, és keresse fel a "Tevékenységkorlátozások" című szakaszt.

Kizárólagos telepítési zárolási szabályzat

Ezzel a frissítéssel biztosítható, hogy egyszerre csak egyetlen futtatás legyen üzembe helyezve egy környezetben. Ha kiválasztja a "Kizárólagos zárolás" beállítást egy környezetben, csak egyetlen futtatás fog végbemenni. Az adott környezetben üzembe helyezni kívánt későbbi futtatások szüneteltetve lesznek. Miután a kizárólagos zárat használó folyamat befejeződött, indul a legújabb folyamat. A köztes futtatások megszakadnak.

Fázisszűrők folyamaterőforrás-eseményindítókhoz

A YAML-ben a folyamaterőforrások szűrőjeként hozzáadtuk a "szakaszok" támogatását. Ezzel a szűrővel nem kell megvárnia a teljes CI pipeline befejeződését, hogy elindíthassa a CD pipeline-t. Most már dönthet úgy, hogy aktiválja a CD-folyamatot a CI-folyamat egy adott szakaszának befejezése után.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Ha az eseményindító-szűrőben megadott szakaszok sikeresen befejeződnek a CI-folyamatban, a rendszer automatikusan elindít egy új futtatási folyamatot a CD-folyamathoz.

Általános webhookalapú eseményindítók YAML-folyamatokhoz

Ma számos erőforrással (például folyamatokkal, tárolókkal, buildekkel és csomagokkal) rendelkezünk, amelyeken keresztül összetevőket használhat fel, és automatizált triggereket engedélyezhet. Eddig azonban nem tudta automatizálni az üzembe helyezési folyamatot más külső események vagy szolgáltatások alapján. Ebben a kiadásban webhook-triggertámogatást vezetünk be a YAML-folyamatokban a folyamatautomatizálás bármilyen külső szolgáltatással való integrációjának lehetővé tétele érdekében. Bármilyen külső eseményre feliratkozhat a webhookokon keresztül (Github, Github Enterprise, Nexus, Aritfactory stb.), és aktiválhatja a folyamatokat.

A webhook-eseményindítók konfigurálásához az alábbi lépések szükségesek:

1. Állítson be egy webhookot a külső szolgáltatáson. A webhook létrehozásakor a következő adatokat kell megadnia:

   • Kérelem URL-címe – "https://dev.azure.com/<ADO-gyűjtemény>/_apis/public/distributedtask/webhooks/<WebHook név>?api-version=6.0-preview"
   • Titkos kód – Ez nem kötelező. Ha biztonságossá kell tenni a JSON üzenti tartalmát, adja meg a titkos értéket.

2. Hozzon létre egy új "Bejövő webhook" szolgáltatáskapcsolatot. Ez egy újonnan bevezetett szolgáltatáskapcsolat-típus, amely lehetővé teszi három fontos információ definiálását:

   • Webhook neve: A webhook nevének meg kell egyeznie a külső szolgáltatásban létrehozott webhook nevével.
   • HTTP-fejléc – Annak a HTTP-fejlécnek a neve a kérelemben, amely a kérelem ellenőrzéséhez szükséges payload hash értékét tartalmazza. A GitHub esetében például a kérés fejléce "X-Hub-Signature" lesz.
   • Titkos – A titkos a bejövő kérelem ellenőrzéséhez használt terhelési kivonat elemzésére szolgál (ez nem kötelező). Ha titkos kulcsot használt a webhook létrehozásához, ugyanazt a titkos kulcsot kell megadnia

   

3. A YAML-folyamatokban egy új, webhooks nevű erőforrástípus jelenik meg. Ha webhookeseményre szeretne feliratkozni, meg kell határoznia egy webhook-erőforrást a csővezetékben, és azt úgy kell beállítani, hogy a Bejövő webhook szolgáltatáskapcsolatra mutasson. További szűrőket is definiálhat a webhook-erőforráson a JSON hasznos adatadatok alapján, hogy az egyes folyamatok eseményindítóit tovább testre szabhassa, és a hasznos adatok változók formájában használhatók fel a feladatokban.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Amikor a Bejövő webhook szolgáltatáskapcsolat fogad egy webhookeseményt, a rendszer új futtatást indít el a webhookeseményre előfizetett összes folyamathoz.

YAML erőforrásindító problémái támogatással és nyomon követhetőséggel kapcsolatban

Zavaró lehet, ha a folyamatindítók végrehajtása nem sikerül a várt módon. Ennek jobb megértése érdekében hozzáadtunk egy új menüelemet a folyamatdefiníció "Trigger Issues" (Eseményindító problémák) oldalához, ahol az eseményindítók végrehajtásának sikertelenségével kapcsolatos információk jelennek meg.

Az erőforrás-eseményindítók végrehajtása két okból meghiúsulhat.

1. Ha a megadott szolgáltatáskapcsolat forrása érvénytelen, vagy ha szintaxishibák lépnek fel az eseményindítóban, az eseményindító egyáltalán nem lesz konfigurálva. Ezek hibaként jelennek meg.

2. Ha az eseményindító feltételei nem teljesülnek, az eseményindító nem hajtódik végre. Amikor ez történik, egy figyelmeztetés jelenik meg, hogy megérthesse, miért nem feleltek meg a feltételeknek.

   

Több adattár eseményindítói

Egy YAML-fájlban több adattárat is megadhat, és egy folyamat bármelyik adattár frissítésével aktiválható. Ez a funkció például a következő esetekben hasznos:

• Egy másik adattárból származó eszközt vagy könyvtárat használ. Az eszköz vagy könyvtár frissítésekor az alkalmazáshoz tartozó teszteket szeretne futtatni.
• A YAML-fájlt az alkalmazáskódtól eltérő adattárban tárolhatja. A folyamatot minden alkalommal aktiválni szeretné, amikor a rendszer leküldi a frissítést az alkalmazás adattárába.

Ezzel a frissítéssel a több adattárt kezelő eseményindítók csak az Azure-adattárakban lévő Git-repozitóriumokban működnek. Nem működnek GitHub- vagy BitBucket-adattár-erőforrásokhoz.

Íme egy példa, amely bemutatja, hogyan definiálhat több adattár-erőforrást egy folyamatban, és hogyan konfigurálhatja az eseményindítókat mindegyiken.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

A példában szereplő folyamat akkor aktiválódik, ha a következőhöz van frissítés:

• A main adattár self ága, amely tartalmazza a YAML-fájlt
• main vagy release ágak tools adattárban

További információkért lásd: Több adattár a munkafolyamatban.

Javult az ügynöknapló feltöltése

Ha egy ügynök nem kommunikál az Azure Pipelines-kiszolgálóval, a futtatott feladat megszűnik. Ha véletlenül a streaming konzol naplóit nézte, talán kapott néhány jelet arról, hogy az ügynök mit csinált közvetlenül azelőtt, mielőtt nem válaszolt volna. De ha nem lettél volna ott, vagy ha frissítetted az oldalt, ezek a konzolnaplók eltűntek. Ebben a kiadásban, ha az ügynök nem válaszol, mielőtt elküldi a teljes naplóit, a konzolnaplókat a lehető legjobb alternatívának tekintjük. A konzolnaplók legfeljebb 1000 karaktert tartalmazhatnak soronként, és esetenként hiányosak is lehetnek, de sokkal hasznosabbak, mintha semmit sem mutatnának! A naplók vizsgálata segíthet a saját folyamatok hibaelhárításában, és minden bizonnyal segít a támogatási mérnökeinknek a hibaelhárításban.

Opcionálisan csatlakoztathatja a tárolói köteteket írásvédett módban

Amikor konténerfeladatot futtat az Azure Pipelines-ban, a munkaterületet, feladatokat és egyéb anyagokat tartalmazó kötetek kötetekként vannak leképezve. Ezek a kötetek alapértelmezés szerint olvasási/írási hozzáférést biztosítanak. A megnövekedett biztonság érdekében a kötetek írásvédetté tétele érdekében módosíthatja a tartály specifikációját YAML-ben. A mountReadOnly alatt lévő összes kulcs beállítható a true számára csak olvashatóként (az alapbeállítás false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

A tároló indításának/leállításának részletes szabályozása

Általában azt javasoljuk, hogy engedélyezze az Azure Pipelines számára a feladat- és szolgáltatástárolók életciklusának kezelését. Egyes nem gyakori helyzetekben azonban érdemes lehet saját maga elindítani és leállítani őket. Ezzel a kiadással ezt a képességet beépítettük a Docker-feladatba.

Íme egy példafolyamat az új képesség használatával:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Emellett a tárolók listáját is belefoglaljuk egy folyamatváltozóba, Agent.ContainerMapping. Ezt akkor használhatja, ha például egy szkript tárolóinak listáját szeretné megvizsgálni. Tartalmaz egy sztringezett JSON-objektumot, amely megfelelteti az erőforrás nevét ("builder" a fenti példából) az ügynök által kezelt tárolóazonosítóhoz.

Feladatcsomagok kibontása az egyes lépésekhez

Amikor az ügynök futtat egy feladatot, először letölti a feladat lépéseihez szükséges összes tevékenységcsomagot. A teljesítményhez általában feladatonként egyszer bontja fel a tevékenységeket, még akkor is, ha a feladatot több lépésben használják. Ha aggályai vannak azzal kapcsolatban, hogy a nem megbízható kód módosíthatja a kibontott tartalmat, feláldozhat egy kis teljesítményt azáltal, hogy az ügynök minden használatkor kibontja a feladatot. Az ügynök konfigurálásakor adja át --alwaysextracttask a mód engedélyezéséhez.

A kiadás biztonságának javítása a hozzáférési jogkivonatok hatókörének korlátozásával

Az Azure Pipelines biztonsági beállításainak továbbfejlesztésére irányuló kezdeményezésünkre építve mostantól támogatjuk a hozzáférési jogkivonatok hatókörének korlátozását a kiadásokhoz.

Minden kiadásban futó feladat kap egy hozzáférési jogkivonatot. A hozzáférési jogkivonatot a feladatok és a szkriptek használják az Azure DevOpsba való visszahíváshoz. A hozzáférési jogkivonat használatával például lekérjük a forráskódot, letöltjük az összetevőket, feltöltjük a naplókat, teszteljük az eredményeket, vagy REST-hívásokat indítunk az Azure DevOpsba. Minden feladathoz létrehoz egy új hozzáférési jogkivonatot, és a feladat befejeződése után lejár.

Ezzel a frissítéssel a folyamatbiztonság javítására építünk a hozzáférési jogkivonatok hatókörének korlátozásával, és ugyanezt kiterjesztjük a klasszikus kiadásokra is.

Ez a funkció alapértelmezés szerint be van kapcsolva az új projektek és gyűjtemények esetében. Meglévő gyűjtemények esetén engedélyeznie kell azt a gyűjteményben, a Beállítások > Folyamatok > Beállítások menüben. > Korlátozza a feladat engedélyezési hatókörét az aktuális projektre a kiadási folyamatokhoz. Tudjon meg többet itt.

YAML előzetes API-fejlesztések

Mostantól az egész YAML- előnézetét megtekintheti a folyamat futtatása nélkül. Emellett létrehoztunk egy dedikált új URL-címet az előzetes verziójú funkcióhoz. Most már küldhetsz POST-kérést a https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview-ra a véglegesített YAML-test lekéréséhez. Ez az új API ugyanazokat a paramétereket használja, mint a futtatások várólistára helyezése, de már nincs szükség a "Queue builds" engedélyre.

Következőként futtassa ezt a feladatot

Volt már olyan hibajavítása, amelyet azonnal telepítenie kellett, de várnia kellett a CI-folyamatok és a PR-feladatok mögött? Ezzel a kiadással mostantól lehetővé tesszük a sorba állított feladatok prioritásának növelését. A készlet "Kezelés" engedélyével rendelkező felhasználók – jellemzően a készletgazdák – a feladat részleteit tartalmazó lapon egy új "Tovább futtatása" gombot fognak látni. A gombra kattintva beállíthatja, hogy a feladat a lehető leghamarabb fusson. (Természetesen szüksége lesz a rendelkezésre álló párhuzamosságra és egy megfelelő ügynökre.)

A YAML-resources blokkban engedélyezett sablonkifejezések

Korábban (${{ }}) fordítási időkifejezések nem voltak engedélyezve az Azure Pipelines YAML-fájl resources szakaszában. Ezzel a kiadással feloldottuk a tárolókra vonatkozó korlátozást. Ez lehetővé teszi, hogy használja a futtatási paraméter tartalmát az erőforrásaiban, például a tároló kiválasztására a várakozási idejű választás során. Azt tervezzük, hogy ezt a támogatást idővel más erőforrásokra is kiterjesztjük.

Automatikus feladatfrissítések vezérlése a Marketplace-ről

YAML-folyamat írásakor általában csak a belefoglalt feladatok főverziószámát adja meg. Ez lehetővé teszi, hogy a folyamatok automatikusan elvégezzék a legújabb funkciók hozzáadását és hibajavításait. Időnként előfordulhat, hogy vissza kell állítania egy feladat egy korábbi verziójára. Ezzel a frissítéssel ezt a lehetőséget is hozzáadtuk. Most már megadhat egy teljes major.minor.patch feladatverziót a YAML-folyamatokban.

Nem javasoljuk, hogy ezt rendszeresen végezze el, és csak ideiglenes kerülő megoldásként használja, ha azt tapasztalja, hogy egy újabb tevékenység megszakítja a folyamatokat. Emellett ez nem telepíti a feladat régebbi verzióját a Marketplace-ről. Ennek már léteznie kell a gyűjteményben, különben a folyamat kudarcot vall.

Példa:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

A Node 10 támogatása az agentben és a feladatokban

Mivel a 6. csomópont már nem támogatott, migráljuk a feladatokat a 10. csomóponttal való együttműködéshez. A frissítéshez közel 50% dobozon belüli feladatot migráltunk a Node 10-re. Az ügynök mostantól a 6. csomópont és a 10. csomópont feladatait is futtathatja. Egy későbbi frissítésben teljes mértékben eltávolítjuk a Node 6-ot a rendszerben. A Node 6 ügynökből való eltávolításának előkészítése érdekében kérjük, hogy mielőbb frissítse a házon belüli bővítményeket és az egyéni feladatokat, hogy azokat a Node 10 használatára állítsa át. Ha a Node 10-et szeretné használni a feladathoz, frissítse a task.json alatt, execution-ből Node-ről Node10-ra.

YAML-átalakítás fejlesztése a klasszikus buildtervezőben

Ezzel a kiadással bevezetünk egy új "YAML-be való exportálás" funkciót a tervezői buildelési folyamatokhoz. Mentse a folyamatdefiníciót, majd keresse meg az "Exportálás YAML-be" lehetőséget a ... menüben.

Az új exportálási függvény felváltja a klasszikus buildtervezőben korábban talált "Nézet YAML-ként" függvényt. Ez a függvény hiányos volt, mivel csak azt vizsgálta meg, hogy a webes felhasználói felület mit tudott a buildről, ami néha helytelen YAML generálásához vezetett. Az új exportálási függvény pontosan figyelembe veszi a folyamat feldolgozásának módját, és teljes hűséggel hozza létre a YAML-t a tervezőfolyamat számára.

Új webplatform-átalakítás – Adattár beállításai

A két adattárbeállítási lapot egyetlen felületté alakítottuk át, amelyet egy új webplatformra frissítettünk. Ez a frissítés nemcsak gyorsabb és modernebbé teszi a felhasználói élményt, de ezek a lapok egyetlen belépési pontot is biztosítanak a projektszinttől az ágszintig minden szabályzathoz.

Ezzel az új felülettel a gyorsabb betöltési idők és a hozzáadott keresési szűrő miatt egyszerűbbé vált a jelentős számú adattárral rendelkező projektek navigációja. A projekt szintű szabályzatokat és a kereszt-repozitórium szabályzatok listáját a Szabályzatok fül alatt is megtekintheti.

Ha egy adattárra kattint, megtekintheti az adattár szintjén beállított szabályzatokat és engedélyeket. A Szabályzatok lapon megtekintheti az összes olyan ág listáját, amelyen a házirend be van állítva. Most kattintson az ágra a szabályzatok megtekintéséhez, miközben soha nem hagyja el az Adattár beállításai lapot.

Most, amikor a szabályzatok egy magasabb hatókörből öröklődnek, mint amellyel dolgozik, az egyes szabályzatok mellett megmutatjuk, hogy honnan lettek öröklődve. A hatókör nevére kattintva arra a lapra is navigálhat, ahol a magasabb szintű szabályzat be lett állítva.

Maga a szabályzatlap is frissítve lett az új webes platformra, összecsukható szakaszokkal! Egy adott buildérvényesítési, állapotellenőrzési vagy automatikus véleményezői szabályzat keresésének élményének javítása érdekében minden szakaszhoz hozzáadtunk keresési szűrőket.

ServiceNow változáskezelési integráció YAML-folyamatokkal

A ServiceNow Azure Pipelines-alkalmazás segít integrálni az Azure Pipelinest és a ServiceNow Change Managementet. A frissítéssel tovább viszük azon törekvésünket, hogy az Azure Pipelines integrálódjon a ServiceNow-ban kezelt változáskezelési folyamatokkal a YAML-pipelinetek terén.

Ha konfigurálja a "ServiceNow Change Management" ellenőrzést egy erőforráson, szüneteltetheti a módosítás jóváhagyását, mielőtt üzembe helyezené a buildet az adott erőforráson. Automatikusan létrehozhat egy új módosítást egy szakaszhoz, vagy várakozhat egy meglévő módosítási kérelemre.

A UpdateServiceNowChangeRequest feladatot is hozzáadhatja egy kiszolgálói feladathoz, hogy frissítse a változáskérést az üzembe helyezés állapotával, megjegyzéseivel stb.

Műtárgyak

Szervezeti hatókörű hírcsatornák létrehozása felhasználói felületről

Az ügyfelek számára visszahozzuk annak lehetőségét, hogy a gyűjteményekre kiterjedő hírcsatornákat hozzanak létre és kezeljenek a webes felhasználói felületen keresztül, mind a helyszíni, mind az üzemeltetett szolgáltatásokhoz.

Mostantól szervezeti hatókörű hírcsatornákat hozhat létre a felhasználói felületen, ha az Artifacts (Összetevők) lehetőséget választja,> Hírcsatorna létrehozása és a hatókörön belüli hírcsatornatípus kiválasztása lehetőséget.

Bár a projekthatókörű hírcsatornák használatát a többi Azure DevOps-ajánlattal összhangban javasoljuk, a gyűjtemény hatókörű hírcsatornáit ismét létrehozhatja, kezelheti és használhatja a felhasználói felületen és a különböző REST API-kon keresztül. További információért tekintse meg az adatfolyamok dokumentációját.

A Csomagverzió REST API frissítése már elérhető a Maven-csomagokhoz

Mostantól az Azure Artifacts "Csomagverzió frissítése" REST API-val frissítheti a Maven-csomagverziókat. Korábban a REST API-val frissíthette a NuGet, a Maven, az npm és az Univerzális csomagok csomagverzióit, a Maven-csomagokat azonban nem.

A Maven-csomagok frissítéséhez használja a HTTP PATCH parancsot az alábbiak szerint.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

A következőket állíthatja be:

URI-paraméterek

név		Kötelező	Típus	leírás
artefaktAzonosító	elérési út	IGAZ	karakterlánc	A csomag összetevő-azonosítója
hírcsatorna	elérési út	IGAZ	karakterlánc	A hírcsatorna neve vagy azonosítója
csoportId	elérési út	IGAZ	karakterlánc	A csomag csoportazonosítója
gyűjtemény	elérési út	IGAZ	karakterlánc	Az Azure DevOps-gyűjtemény neve
verzió	elérési út	IGAZ	karakterlánc	A csomag verziója
projekt	elérési út		karakterlánc	Projektazonosító vagy projektnév
api-verzió	lekérdezés	IGAZ	karakterlánc	A használni kívánt API verziója. Ennek az api ezen verziójának használatához az "5.1-preview.1" értéket kell beállítani

kérelemtörzs

név	Típus	leírás
Nézetek	JsonPatchOperation	Az a nézet, amelyhez hozzá lesz adva a csomag verziója.

További információkért tekintse meg a REST API dokumentációját, a frissítés során.

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