Az Azure DevOps Server 2020 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 egy verzió á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 0.2 Patch 6 Kiadás dátuma: 2023. november 14.

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

• Bővítette a PowerShell-tevékenységek által engedélyezett karakterek listáját A rendszerhéj-tevékenységek argumentumainak paraméterérvényesítésének engedélyezése.

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 4. javítással. Ha nem telepítette az ügynökfrissítéseket a 4. javítás kibocsátási megjegyzéseiben leírtak szerint, javasoljuk, hogy a 6. javítás telepítése előtt telepítse ezeket a frissítéseket. A 4. 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ényi dokumentációba való telepítéshez és a tfx-cli-vel történő bejelentkezéshez.

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.

• Klasszikus:

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

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Fontos

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

Kiadottunk egy patch az Azure DevOps Server 2020 Update 0.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 0.2 Patch 4 Kiadás dátuma: 2023. szeptember 12.

Közzétettünk egy javítást az Azure DevOps Server 2020 0.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 javítások alkalmazá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 0.2 patch 4.

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-t "true" értékre kell beállítani, hogy megakadályozzuk 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ényi dokumentációba való telepítéshez és a tfx-cli-vel történő bejelentkezéshez.

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.

• Klasszikus:

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

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

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

Azure DevOps Server 2020 Update 0.2 Patch 2 Kiadás dátuma: 2023. június 13.

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

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

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

Kiadottunk egy patch az Azure DevOps Server 2020 Update 0.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.
• Javítottuk a "gated check-in" build hibáját, amikor a szervezet folyamatbeállításai között a feladat engedélyezési hatóköre úgy volt beállítva, hogy csak a nem kiadási folyamatok aktuális projektjeire korlátozódjon.

Az Azure DevOps Server 2020.0.2 kiadási dátuma: 2022. május 17.

Azure DevOps Server 2020.0.2 hibajavítások összesítője. Közvetlenül telepítheti az Azure DevOps Server 2020.0.2-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.0.2-ben. Az importálási jelenleg támogatott verzióinak listáját itt találja.

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

• Nem lehet kihagyni a buildsort a "Futtatás tovább" 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.0.1 Patch 9 kiadás dátuma: 2022. január 26.

Kiadottunk egy javítás az Azure DevOps Server 2020.0.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.
• Javítsa ki TF400813 hibát a fiókváltáskor. Ez a hiba a TFS 2018-ról az Azure DevOps Server 2020.0.1-re való frissítéskor jelentkezett.
• Kijavítottuk azt a hibát, amely miatt a Projekt áttekintése összefoglaló lap betöltése sikertelen volt.
• 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 Patch 9.
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. Futtassa 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 9-es számú javítással.
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 meghajtón található, zip nevű mappa tartalmát az Elasticsearch távoli fájlmappájába.
4. Futtassa a Configure-TFSSearch.ps1 -Operation update-t az Elasticsearch szervergépen.

SHA-256 kivonat: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 Patch 8 kiadás dátuma: 2021. december 15.

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

• Egyéni munkaelemek elrendezési állapotainak honosítási problémája.
• Honosítási probléma az e-mail-értesítési sablonban.
• Probléma a konzolnaplók csonkításával, ha egy sorban több azonos hivatkozás található.
• Hiba a NOTSAMEAS-szabályok kiértékelésekor, ha több NOTSAMEAS-szabályt definiáltak egy mezőhöz.

Az Azure DevOps Server 2020.0.1 7-es patch kiadási dátuma: 2021. október 26.

7. javítás az Azure DevOps Server 2020.0.1-hez 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.

Az Azure DevOps Server 2020.0.1 6-os patch kiadási dátuma: 2021. szeptember 14.

Patch 6 for Azure DevOps Server 2020.0.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.0.1 5-ös patch kiadási dátuma: 2021. augusztus 10.

Azure DevOps Server 2020.0.1-hez készült 5. patch az alábbi javításokat tartalmazza.

• 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.
• Kijavítottunk néhány munkaelemtípushoz tartozó e-mail-kézbesítési feladatokkal kapcsolatos problémát.

Az Azure DevOps Server 2020.0.1 4-es patch kiadási dátuma: 2021. június 15.

4. patch az Azure DevOps Server 2020.0.1-hez az alábbi javításokat tartalmazza.

• Az adatimportálással kapcsolatos probléma megoldása. Az adatimportálás sok elavult tesztesetet tartalmazó ügyfelek számára hosszú időt vett igénybe. Ez a tbl_testCaseReferences tábla méretét növelő hivatkozásoknak volt köszönhető. Ezzel a javítással eltávolítottuk az elavult tesztelési esetekre mutató hivatkozásokat az adatimportálási folyamat felgyorsítása érdekében.

Azure DevOps Server 2020.0.1 3. javítás kiadási dátuma: 2021. május 11.

Kiadottunk egy javítás az Azure DevOps Server 2020.0.1-hez, amely az alábbiakat javítja ki.

• Inkonzisztens teszteredmények adatai a Microsoft.TeamFoundation.TestManagement.Client használatakor.

Ha azure DevOps Server 2020.0.1-et futtat, telepítse Azure DevOps Server 2020.0.1 Patch 3.

Az ellenőrzése a telepítésnek

• 1. lehetőség: Futtassa a devops2020.0.1patch3.exe CheckInstall-t. A devops2020.0.1patch3.exe a fenti hivatkozásból letöltött fájl. A parancs kimenete vagy azt fogja mondani, hogy a javítás telepítve van, vagy nincs telepítve.

• 2. lehetőség: Ellenőrizze a következő fájl verzióját: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Az Azure DevOps Server 2020.0.1 alapértelmezés szerint ide települ: c:\Program Files\Azure DevOps Server 2020. Az Azure DevOps Server 2020.0.1 3.1-es javítása után a verzió 18.170.31228.1 lesz.

Azure DevOps Server 2020.0.1 2. javítás kiadási dátuma: 2021. április 13.

Jegyzet

Ha azure DevOps Server 2020-ra van szüksége, először frissítenie kell az Azure DevOps Server 2020.0.1-et. Egyszer 2020.01.01-én telepítse az Azure DevOps Server 2020.0.1 2. javítócsomagot.

Kiadottunk egy javítás az Azure DevOps Server 2020.0.1-hez, amely az alábbiakat javítja ki.

• CVE-2021-27067: Információfeltárás
• CVE-2021-28459: Jogosultság emelése

A javítások implementálásához az alábbi lépéseket kell követnie az általános javítástelepítéshez, AzureResourceGroupDeploymentV2, és a AzureResourceManagerTemplateDeploymentV3 feladat telepítések végrehajtásához.

Általános javítástelepítés

Ha az Azure DevOps Server 2020.0.1 verzióval rendelkezik, telepítse Azure DevOps Server 2020.0.1 Patch 2.

Az ellenőrzése a telepítésnek

• 1. lehetőség: Futtatás devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe a fentebb található linkről letöltött fájl. A parancs kimenete vagy azt fogja mondani, hogy a javítás telepítve van, vagy nincs telepítve.

• 2. lehetőség: Ellenőrizze a következő fájl verzióját: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Az Azure DevOps Server 2020.0.1 alapértelmezés szerint ide települ: c:\Program Files\Azure DevOps Server 2020. Az Azure DevOps Server 2020.0.1 2-es javítása után a verzió 18.170.31123.3 lesz.

AzureResourceGroupDeploymentV2 feladattelepítés

Jegyzet

Az alábbiakban említett összes lépést Windows rendszerű gépen kell végrehajtani

Felszerel

1. Bontsa ki a AzureResourceGroupDeploymentV2.zip csomagot egy új mappába a számítógépen. Például: D:\tasks\AzureResourceGroupDeploymentV2.

2. Töltse le és telepítse Node.js 14.15.1 és npm (a Node.js letöltésével együtt) a gépének megfelelően.

3. Nyisson meg egy parancssort rendszergazda módban, és futtassa a következő parancsot a tfx-cli telepítéséhez.

npm install -g tfx-cli

4. Hozzon létre egy személyes hozzáférési jogkivonatot teljes hozzáférésű jogosultságokkal, és másolja ki. Ez a személyes hozzáférési jogkivonat a tfx bejelentkezési parancs futtatásakor lesz használva.

5. Futtassa a következőt a parancssorból. Amikor a rendszer kéri, adja meg a szolgáltatás URL-címét és a személyes hozzáférési jogkivonatot.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Futtassa a következő parancsot a feladat kiszolgálóra való feltöltéséhez. Használja az 1. lépésből kinyert .zip fájl elérési útját.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 feladattelepítés

Jegyzet

Az alábbiakban említett összes lépést Windows rendszerű gépen kell végrehajtani

Felszerel

1. Bontsa ki a AzureResourceManagerTemplateDeploymentV3.zip csomagot egy új mappába a számítógépen. Például:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Töltse le és telepítse a Node.js 14.15.1-et és az npm-et (a Node.js letöltésével együtt) a gépének megfelelően.

3. Nyisson meg egy parancssort rendszergazda módban, és futtassa a következő parancsot a tfx-cli telepítéséhez.

npm install -g tfx-cli

4. Hozzon létre egy személyes hozzáférési jogkivonatot teljes hozzáférésű jogosultságokkal, és másolja ki. Ez a személyes hozzáférési jogkivonat a tfx bejelentkezési parancs futtatásakor lesz használva.

5. Futtassa a következőt a parancssorból. Amikor a rendszer kéri, adja meg a szolgáltatás URL-címét és a személyes hozzáférési jogkivonatot.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Futtassa a következő parancsot a feladat kiszolgálóra való feltöltéséhez. Használja az 1. lépésből kinyert .zip fájl elérési útját.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 Patch 1 Kiadás dátuma: 2021. február 9.

Kiadottunk egy javítás az Azure DevOps Server 2020.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• A fejlesztői közösség visszajelzési jegyének keretében jelentettprobléma megoldása | Az Új teszteset gomb nem működik
• Foglalja bele a Azure DevOps Server 2020Patch 2 által kiadott javításokat.

Azure DevOps Server 2020 Patch 3 kiadás dátuma: 2021. február 9.

Kiadottunk egy patch az Azure DevOps Server 2020-hoz, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• A fejlesztői közösség visszajelzési jegyének keretében jelentettprobléma megoldása | Az Új teszteset gomb nem működik

Az Azure DevOps Server 2020.0.1 kiadás dátuma: 2021. január 19.

Az Azure DevOps Server 2020.0.1 hibajavítások összesítője. Közvetlenül telepítheti az Azure DevOps Server 2020.0.1-et, vagy frissíthet egy meglévő telepítésről. A frissítés támogatott verziói az Azure DevOps Server 2020, az Azure DevOps Server 2019 és a Team Foundation Server 2012 vagy újabb verziók.

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

• Megoldhatja az Azure DevOps Server 2019 frissítési problémáját, amely miatt előfordulhat, hogy a Git-proxy nem működik a frissítés után.
• Az Azure DevOps Server 2020-ra való frissítéskor javítsa ki a System.OutOfMemoryException kivételt a Team Foundation Server 2017 előtti nem ENU-gyűjtemények esetében. Megoldja a számú Developer Community visszajelzési jegyben jelentettproblémát.
• A Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dllhiánya által okozott karbantartási meghibásodás. Megoldja a számú Developer Community visszajelzési jegyben jelentettproblémát.
• Az Azure DevOps Server 2020-ra való frissítés során javítsa ki az Érvénytelen oszlopnév hibát az Analyticsben. Megoldja a számú Developer Community visszajelzési jegyben jelentettproblémát.
• Tárolt XSS, amikor a tesztesetek lépéseit jeleníti meg a teszteset eredményeiben.
• Frissítési lépés hibája az eredményadatok TCM-re történő migrálása során.

Azure DevOps Server 2020 Patch 2 kiadás dátuma: 2021. január 12.

Kiadottunk egy patch az Azure DevOps Server 2020-hoz, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• A tesztfuttatás részletei nem jelenítik meg az OpsHub Migration használatával migrált tesztadatok tesztelési lépésének részleteit
• Kivétel a Microsoft.TeamFoundation.TestManagement.Server.TCMLogger inicializálóján
• Az Azure DevOps Server 2020-ra való migrálás után a rendszer azonnal törli a nem kézbesített buildeket
• Adatszolgáltatói kivétel javítása

Azure DevOps Server 2020 Patch 1 Dátum: 2020. december 8.

Kiadottunk egy patch az Azure DevOps Server 2020-hoz, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2020-17145: Azure DevOps Server és Team Foundation Services hamisítási biztonsági rés

Az Azure DevOps Server 2020 kiadási dátuma: 2020. október 6.

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

Jegyzet

Az Azure DevOps 2020 Server problémát tapasztal a Git virtuális fájlrendszer (GVFS) által használt szerelvények telepítésével kapcsolatban.

Ha az Azure DevOps 2019-ről (bármely kiadásról) vagy az Azure DevOps 2020 kiadásjelöltről frissít, és az előző kiadással megegyező könyvtárba telepíti, a szerelvény Microsoft.TeamFoundation.Git.dll nem lesz telepítve. Annak ellenőrzéséhez, hogy valóban a problémával van-e dolga, keressen Microsoft.TeamFoundation.Git.dll jelölést a <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent és <Install Dir>\Tools mappákban. Ha a fájl hiányzik, futtathat egy javítást a hiányzó fájlok visszaállításához.

Javítás futtatásához nyissa meg az Azure DevOps Server-gépen/virtuális gépen található Settings -> Apps & Features, és futtasson egy javítást az Azure DevOps 2020 Serveren. Miután a javítás befejeződött, újraindíthatja a gépet/virtuális gépet.

Az Azure DevOps Server 2020 RC2 kiadási dátuma: 2020. augusztus 11.

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

Az Azure DevOps Server 2020 RC1 újrakiadásának dátuma: 2020. július 10.

Az Azure DevOps Server 2020 RC1-et újra kiadjuk azért, hogy kijavítsuk a fejlesztői közösség visszajelzési jegyét.

Korábban az Azure DevOps Server 2019 1.1-es frissítéséről az Azure DevOps Server 2020 RC1-re való frissítés után nem tudta megtekinteni a webes felhasználói felület adattáraiban, folyamataiban és wikijében lévő fájlokat. Hibaüzenet jelenik meg, amely azt jelzi, váratlan hiba történt a lap ezen régiójában. Megpróbálhatja újra betölteni ezt az összetevőt, vagy frissítheti a teljes lapot. Ezzel a kiadással kijavítottuk ezt a problémát. További információért tekintse meg a blogbejegyzést.

Azure DevOps Server 2020 RC1 kiadás dátuma: 2020. június 30.

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

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

• többfázisú csővezetékek
• Folyamatos üzembe helyezés a YAML
• A szülőelemek előrehaladásának nyomon követése a táblák feladatlistájának összesítő funkciójával
• "Szülő munkaelem" szűrő hozzáadása a feladattáblához és a sprint hátralékhoz
• Új webes felhasználói felület az Azure Repos kezdőlapjaihoz
• Tárházközi fiókházirend-kezelés
• Új tesztterv lap
• Kód wikilapjainak részletes szerkesztése
• folyamathibák és időtartamjelentések

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

• Általános
• táblák
• tárhelyek
• csővezetékek
• teszttervek
• összetevők
• Wiki
• jelentéskészítés

---

Általános

Az Azure DevOps CLI általános elérhetősége

Februárban bevezettük az Azure CLI-hez készült Azure DevOps-bővítményt. A bővítmény segítségével a parancssorból kezelheti az Azure DevOps-t. Összegyűjtöttük a visszajelzését, amely segített a bővítmény fejlesztésében és további parancsok hozzáadásában. Örömmel jelentjük be, hogy a bővítmény általánosan elérhető.

Az Azure DevOps CLI-vel kapcsolatos további információkért tekintse meg az itt dokumentációt.

Közzétételi profil használata a WindowsHoz készült Azure WebApps üzembe helyezéséhez az Üzembe helyezési központból

Mostantól a profilalapú hitelesítés közzétételével üzembe helyezheti a WindowsHoz készült Azure WebAppset az Üzembe helyezési központban. Ha rendelkezik engedéllyel egy Windowshez készült Azure WebApp közzétételi profiljának használatával történő üzembe helyezéséhez, beállíthatja a folyamatot ezzel a profillal a telepítési központ munkafolyamataiban.

Deszkák

"Szülőmunkaelem" szűrő hozzáadása a tevékenységtáblához és a sprint hátralékához

Új szűrőt adtunk hozzá a Sprint Boardhoz és a Sprint Backloghoz is. Ez lehetővé teszi, hogy a követelmények szintjén lévő hátralékelemeket a szülő alapján szűrje (az első oszlop a bal oldalon). Az alábbi képernyőképen például szűrtük a nézetet, hogy csak olyan felhasználói történetet jelenítsünk meg, ahol a szülő a "Nagy funkcióm".

Hibakezelési élmény javítása – a hiba/tevékenység kötelező mezői

Korábban a Kanban táblából, ha áthelyezett egy munkaelemet az egyik oszlopból egy másikba, ahol az állapotváltozás aktiválta a mezőszabályokat, a kártya csak egy piros hibaüzenetet jelenít meg, amely arra kényszeríti, hogy nyissa meg a munkaelemet, hogy megértse a kiváltó okot. A Sprint 170-ben javítottuk a felületet, így a piros hibaüzenetre kattintva anélkül tekintheti meg a hiba részleteit, hogy meg kellene nyitnia magát a munkaelemet.

Munkaelem élő újratöltése

Korábban, amikor frissített egy munkaelemet, és egy második csapattag módosította ugyanazt a munkaelemet, a második felhasználó elveszíti a módosításokat. Most, ha mindketten különböző mezőket szerkesztenek, a munkaelemen végrehajtott módosítások élő frissítései jelennek meg.

Iteráció és terület elérési útjainak kezelése a parancssorból

Mostantól a parancssorból is kezelheti az iterációt és a terület elérési útját a az boards iteration és az boards area parancsokkal. Beállíthatja és kezelheti például az iterációkat és a területútvonalakat interaktívan a parancssori felületről, vagy automatizálhatja a teljes beállítást egy szkripttel. A parancsokkal és a szintaxisokkal kapcsolatos további részletekért tekintse meg a dokumentációt, itt.

Munkaelem szülőoszlopa oszlopként beállítás

Most már lehetősége van látni a terméklistában vagy a sprintlistában található összes munkaelem szülőjét. A funkció engedélyezéséhez lépjen be a kívánt hátraléknál a Oszlopbeállítások részre, majd adja hozzá a Szülő oszlopot.

Projekt által használt folyamat módosítása

Az eszközöknek ugyanúgy kell változnia, mint a csapatának, mostantól bármilyen beépített folyamatsablonról átállíthatja projektjeit bármely más, házon kívüli folyamatra. Módosíthatja például a projektet az Agile-ről Scrumra, az Alapszintűről az Agile-ra. A teljes részletes dokumentációt itttalálja.

Egyéni mezők elrejtése az elrendezésből

Mostantól elrejtheti az egyéni mezőket az űrlapelrendezésből a folyamat testreszabásakor. A mező továbbra is elérhető lesz a lekérdezésekből és a REST API-kból. Ez hasznos lehet a további mezők nyomon követéséhez, amikor más rendszerekkel integrálódik.

Három új Azure Boards-jelentéssel betekintést nyerhet a csapat állapotába

Nem tudja kijavítani, amit nem lát. Ezért érdemes szorosan figyelemmel kísérni a munkafolyamataik állapotát és egészségi állapotát. Ezekkel a jelentésekkel egyszerűbbé tesszük a fontos metrikák nyomon követését minimális erőfeszítéssel az Azure Boardsban.

A három új interaktív jelentés a következő: Burndown, Kumulatív Folyamatábra (CFD) és Sebesség. A jelentéseket az új elemzési lapon tekintheti meg.

Az olyan metrikák, mint a sprint burndown, a munkafolyamat és a csapatsebesség, betekintést nyújtanak a csapat előrehaladásába, és segítenek megválaszolni az olyan kérdéseket, mint például:

• Mennyi munka maradt ebben a futamban? Jó úton haladunk a befejezéshez?
• A fejlesztési folyamat melyik lépése tart a leghosszabb ideig? Tehetünk valamit?
• A korábbi iterációk alapján mennyi munkát kell terveznünk a következő futamra?

Jegyzet

A fejlécekben korábban látható diagramokat lecseréltük ezekre a továbbfejlesztett jelentésekre.

Az új jelentések teljesen interaktívak, és lehetővé teszik az igényeinek megfelelő beállításukat. Az új jelentéseket az Elemzés lap minden egyes központban megtalálhatja.

• Az összegző diagram a Sprints hub alatt található.

  

• A CFD- és sebességjelentések a Elemzés lapTáblák és Hátralékok alatt érhetők el a megfelelő kártyára kattintva.

  

Az új jelentésekben több irányítás és információ áll rendelkezésre a csapatról. Íme néhány példa:

• A Sprint Burndown és a Velocity-jelentések beállíthatók úgy, hogy a munkaelemek számát vagy a hátralévő munka összegét használják.
• A sprint burndown diagram időkeretét módosíthatja a projektdátumok befolyásolása nélkül. Tehát, ha a csapat általában az egyes sprintek első napját a tervezéssel tölti, most már hozzá igazíthatja a diagramot ennek megfelelően.
• A Burndown-diagramon most már van egy vízjel, amelyen a hétvégék láthatók.
• A CFD-jelentés lehetővé teszi, hogy eltávolítsa a táblaoszlopokat, például a Tervezést, hogy jobban összpontosítson azokra a folyamatokra, amelyeket a csapatok irányítanak.

Íme egy példa a CFD-jelentésre, amely a Stories-hátralék utolsó 30 napjának folyamatát mutatja be.

A Sebesség diagram mostantól nyomon követhető az összes hátralékszinten. Mostantól hozzáadhatja például a Funkciókat és az Eposzokat is, míg az előző diagram előtt csak a Követelmények támogatottak. Íme egy példa a szolgáltatások hátralékának utolsó 6 iterációjára vonatkozó sebességjelentésre.

Feladattáblaoszlopok testreszabása

Örömmel jelentjük be, hogy hozzáadtunk egy lehetőséget, amellyel testre szabhatja a tálcán lévő oszlopokat. Mostantól hozzáadhatja, eltávolíthatja, átnevezheti és átrendezheti az oszlopokat.

A Feladatkezelő táblán az oszlopok konfigurálásához menjen a Oszlopbeállításokmenüpontba.

A funkció priorizálásra került a fejlesztői közösségből származó javaslat alapján.

Váltás a befejezett gyermekmunkaelemek megjelenítésére vagy elrejtésére a hátralékban

A hátralék finomításakor sokszor csak a nem befejezett elemeket szeretné látni. Most már megjelenítheti vagy elrejtheti a befejezett alfeladatokat a feladatlistában.

Ha a kapcsoló be van kapcsolva, az összes gyermekelem kész állapotban jelenik meg. Ha a kapcsoló ki van kapcsolva, a befejezett állapotban lévő összes gyermekelem el lesz rejtve a hátralék elől.

Munkaelem címkézésekor megjelenő legújabb címkék

Munkaelem címkézésekor az automatikus kiegészítési lehetőség mostantól legfeljebb öt legutóbb használt címkét jelenít meg. Ez megkönnyíti a megfelelő információk hozzáadását a munkaelemekhez.

Csak olvasható és kötelező érvényű szabályok a csoporttagságra

A munkaelem-szabályok lehetővé teszik adott műveletek beállítását a munkaelem-mezőkön a viselkedésük automatizálásához. Létrehozhat egy szabályt, amellyel a csoporttagság alapján egy mezőt írásvédetté vagy kötelezővé tehet. Előfordulhat például, hogy lehetővé szeretné tenni a terméktulajdonosok számára, hogy beállítsák a funkciók prioritását, miközben mindenki más számára csak olvashatóvá teszik.

A rendszer választólistájának értékeinek testreszabása

Mostantól testre szabhatja a rendszerválasztók értékeit (kivéve az okmezőt), például súlyosság, tevékenység, prioritás stb. A lista testreszabásai hatókörrel vannak elosztva, így az egyes munkaelem-típusokhoz különböző értékeket kezelhet ugyanahhoz a mezőhöz.

Új munkaelem URL-paramétere

Az új munkaelem URL-paraméterével megoszthatja a munkaelemekre mutató hivatkozásokat a tábla vagy a hátralék kontextusával. Mostantól megnyithat egy munkaelem-párbeszédpanelt a táblán, a backlogon vagy a sprinten, ha hozzáfűzi a ?workitem=[ID] paramétert az URL-címhez.

Bárki, akivel megosztja a hivatkozást, ugyanazt a helyzetet fogja megtapasztalni, mint amikor ön megosztotta.

Személyek, munkaelemek és PRS-ek említése szövegmezőkben

Ahogy meghallgattuk a visszajelzését, azt hallottuk, hogy a munkaelem leírási területén (és más HTML-mezőkben) meg szeretné említeni a személyeket, a munkaelemeket és a PRS-eket, és nem csak a megjegyzésekben. Előfordul, hogy egy munkaelemen együttműködik valakivel, vagy ki szeretne emelni egy pr-elemet a munkaelem leírásában, de nem tudta hozzáadni ezeket az információkat. Mostantól a munkaelem összes hosszú szövegmezőjében megemlítheti a személyeket, a munkaelemeket és a PRs-eket.

Itt láthat egy példát.

• A személyek megemlítéséhez írja be a @ jelet és a megemlítendő személy nevét. @mentions munkaelem-mezőkben e-mail-értesítéseket hoz létre, például a megjegyzésekhez.
• A munkaelem-említések használatához írja be a # jelet, majd a munkaelem azonosítóját vagy címét. #mentions kapcsolatot hoz létre a két munkaelem között.
• Pr-említések használatához adjon hozzá egy ! után a PR-azonosítót vagy a nevet.

Hozzászólásokkal kapcsolatos reakciók

Az egyik fő célunk, hogy a munkaelemek együttműködőbbek legyenek a csapatok számára. A közelmúltban egy szavazást végeztünk a Twitteren, hogy megtudjuk, milyen együttműködési funkciókat szeretne a munkaelemről folytatott beszélgetésekben. A megjegyzésekre adott reakciók megnyerték a szavazást, ezért hozzáadjuk őket! Itt vannak az eredmények a Twitter szavazás.

Bármilyen megjegyzéshez hozzáadhat reakciókat, és kétféleképpen adhat hozzá reakciókat – a megjegyzés jobb felső sarkában lévő mosolygó ikont, valamint a megjegyzés alján a meglévő reakciók mellett. Ha szeretné, mind a hat reakciót hozzáadhatja, vagy csak egy vagy két reakciót. A reakció eltávolításához kattintson a megjegyzés alján található reakcióra, és az el lesz távolítva. Az alábbiakban láthatja a reakció hozzáadásának élményét, valamint azt, hogy a reakciók hogyan néznek ki egy megjegyzésen.

Azure Boards-jelentések rögzítése az irányítópulton

A Sprint 155 frissítésben a CFD- és Velocity-jelentések frissített verzióit tartalmaztuk . Ezek a jelentések a Táblák és hátralékok Elemzés lapján érhetők el. Mostantól közvetlenül az irányítópulton rögzítheti a jelentéseket. A jelentések rögzítéséhez vigye az egérmutatót a jelentés fölé, válassza a három pontból álló "..." menüt, majd kattintson a Másolás az irányítópultralehetőségre.

A szülőelemek előrehaladásának nyomon követése a táblákra vonatkozó összesítési teendőlista használatával

Az összesítő oszlopok a hierarchián belüli numerikus mezők vagy leszármazott elemek előrehaladási sávjait és/vagy összegeit jelenítik meg. A leszármazott elemek a hierarchia összes gyermekelemének felelnek meg. Egy vagy több összesítő oszlop hozzáadható egy termék- vagy portfólió-backloghoz.

Itt például a Előrehaladás munkaelemek szerint jelenik meg, amely a bezárt leszármazott elemek százalékos aránya alapján jeleníti meg az emelkedő munkaelemek előrehaladási sávját. Az Epics leszármazott elemei tartalmazzák az összes gyermekfunkciót, valamint a gyermek- vagy unoka munkaelemeket. A szolgáltatások leszármazott elemei közé tartozik az összes gyermek felhasználói történet és a gyermek munkaeleme.

A Taskboard élő frissítései

A feladattábla mostantól automatikusan frissül, amikor változások történnek! Ahogy más csapattagok áthelyezik vagy átrendezik a kártyákat a feladattáblán, a tábla automatikusan frissül ezekkel a módosításokkal. Többé nem kell lenyomnia az F5 billentyűt a legújabb módosítások megtekintéséhez.

Testreszabható mezők támogatása összegző oszlopokban

Az összesítés mostantól bármely mezőn elvégezhető, beleértve az egyéni mezőket is. Összegző oszlop hozzáadásakor továbbra is választhat egy összegző oszlopot a gyorslistában, de ha olyan numerikus mezőket szeretne összesíteni, amelyek nem részei a dobozon kívüli folyamatsablonnak, az alábbiak szerint konfigurálhatja a sajátját:

1. A teendőlistán kattintson az "Oszlopbeállítások" elemre. Ezután a panelen kattintson az "Összesítő oszlop hozzáadása" elemre, és Egyéni összesítőkonfigurálása elemre.

   

2. Válasszon folyamatjelző sáv és Összesközött.
3. Válasszon ki egy munkaelemtípust vagy egy hátralékszintet (általában a hátralékok több munkaelemtípust összesítenek).
4. Válassza ki az összesítés típusát. Munkaelemek száma vagy Összeg. Összeg esetén ki kell jelölnie az összegzendő mezőt.
5. Az OK gomb visszaviszi az oszlopbeállítások panelre, ahol átrendezheti az új egyéni oszlopot.

Vegye figyelembe, hogy az OK gombra kattintás után nem szerkesztheti az egyéni oszlopot. Ha módosítania kell, távolítsa el az egyéni oszlopot, és adjon hozzá egy másikat igény szerint.

Új szabály a munkaelem-űrlap mezőinek a feltétel alapján történő elrejtéséhez

Új szabályt adtunk hozzá az örökölt szabálymotorhoz, hogy elrejtse a mezőket egy munkaeleműrlapon. Ez a szabály a felhasználói csoporttagság alapján elrejti a mezőket. Ha például a felhasználó a "terméktulajdonos" csoporthoz tartozik, elrejthet egy fejlesztőspecifikus mezőt. További részletekért lásd a dokumentációt, itt.

Egyéni munkaelem értesítési beállításai

Rendkívül fontos, hogy naprakészen maradjon az Ön vagy a csapata számára fontos munkaelemekről. Segít a csapatoknak együttműködni és nyomon követni a projekteket, és gondoskodni arról, hogy minden megfelelő fél részt vegyen benne. A különböző érdekelt felek azonban különböző szintű beruházásokat végeznek különböző erőfeszítésekbe, és úgy gondoljuk, hogy ennek tükröződnie kell abban, hogy képes vagy követni egy munkaelem állapotát.

Korábban, ha követni szeretne egy munkaelemet, és értesítéseket szeretne kapni az elvégzett módosításokról, e-mailben értesítést kapna a munkaelem minden módosításáról. A visszajelzések mérlegelése után rugalmasabbá tesszük a munkaelemek követését minden érintett számára. Most egy új beállítások gomb jelenik meg a munkaelem jobb felső sarkában található Követés gomb mellett. Ekkor megjelenik egy előugró ablak, amely lehetővé teszi a következő beállítások konfigurálását.

A értesítési beállításokmenüjéből három értesítési lehetőség közül választhat. Először is teljesen leiratkozhat. Másodszor, teljes mértékben előfizethet, ahol értesítést kap az összes munkaelem-módosításról. Végül dönthet úgy, hogy értesítést kap a legfontosabb és legfontosabb munkaelemek változási eseményeiről. Csak egy vagy mindhárom lehetőséget választhatja. Ez lehetővé teszi, hogy a csapattagok magasabb szinten kövessék a munkaelemeket, és ne vonják el a figyelmét minden egyes módosítástól, amely történik. Ezzel a funkcióval kiküszöböljük a szükségtelen e-maileket, és lehetővé tesszük, hogy a fontos feladatokra összpontosítson.

Munkaelemek csatolása a telepítésekhez

Örömmel jelentjük be az Üzembehelyezési vezérlő elérhetőségét a munkaelem űrlapján. Ez a vezérlő a munkaelemeket egy kiadáshoz csatolja, és lehetővé teszi a munkaelem üzembe helyezésének egyszerű nyomon követését. További információért tekintse meg a dokumentációt, itt.

Munkaelemek importálása CSV-fájlból

Eddig a munkaelemek CSV-fájlból való importálása az Excel beépülő modultól függött. Ebben a frissítésben első osztályú importálási felületet biztosítunk közvetlenül az Azure Boardsból, hogy új vagy meglévő munkaelemeket importálhassunk. További információért tekintse meg a dokumentációt, itt.

Szülőmező hozzáadása munkaelemkártyákhoz

A szülői kontextus mostantól új mezőként érhető el a Kanban táblán a munkaelemek kártyáin. Mostantól hozzáadhatja a Szülő mezőt a kártyákhoz, elkerülve az olyan áthidaló megoldások használatát, mint a címkék és az előtagok.

Szülőmező hozzáadása a visszamaradt elemekhez és a lekérdezésekhez.

A szülőmező mostantól elérhető a hátralékok és a lekérdezési eredmények megtekintésekor. A szülőmező hozzáadásához használja az Oszlopbeállítások nézetet.

Repos

Kódlefedettségi metrikák és ágszabályzat lekéréses kérelmekhez

Mostantól a lekéréses kérelem (PR) nézetben láthatja a módosítások kódlefedettségi mérőszámait. Ez biztosítja, hogy automatikus tesztek segítségével megfelelően tesztelje a módosításokat. A lefedettség állapota megjegyzésként jelenik meg a pull request áttekintésében. A fájldiff nézetben módosított kódsorok lefedettségi adatainak részleteit megtekintheti.

Emellett az adattártulajdonosok beállíthatják a kódlefedési szabályzatokat, és megakadályozhatják, hogy a nagy, nem tesztelt módosítások egy ágba egyesülnek. A kívánt lefedettségi küszöbértékek meghatározhatók egy azurepipelines-coverage.yml beállításfájlban, amelyet az adattár gyökerébe beadtak, és a lefedettségi szabályzat definiálható a meglévő további szolgáltatásokhoz történő ágszabályzat-konfigurálási képesség felhasználásával az Azure-adattárakban.

Megjegyzésértesítések szűrése lekéréses kérelmekből

A lekéréses kérelmek megjegyzései gyakran nagy zajt okozhatnak az értesítések miatt. Hozzáadtunk egy egyéni előfizetést, amellyel szűrheti, hogy mely kommentértesítésekre iratkozhat fel a kommentek kora, a megjegyzést író, a törölt komment, az említett felhasználók, a pull request szerzője, a célág és a téma résztvevői szerint. Ezeket az értesítési feliratkozásokat a jobb felső sarokban lévő felhasználói ikonra kattintva hozhatja létre, és navigál a Felhasználói beállításokmenübe.

Szolgáltatáskapcsolók a pull request megjegyzéseihez

Mostantól létrehozhat szolgáltatási horgokat a pull request megjegyzéseihez az adattár és a célág alapján.

A megadott mintákkal rendelkező fájlok blokkolására vonatkozó szabályzat

A rendszergazdák mostantól beállíthatnak egy szabályzatot, amely megakadályozza a véglegesítések leküldését egy adattárba fájltípusok és elérési utak alapján. A fájlnév-érvényesítési szabályzat blokkolja a megadott mintának megfelelő leküldéseket.

Munkaelemek feloldása véglegesítésekkel kulcsszavakkal

Mostantól a munkaelemeket az alapértelmezett ág commit-jeivel is megoldhatja olyan kulcsszavak használatával, mint például fix, fixesvagy fixed. A véglegesítési üzenetben például írhatja: "ez a változás javította a #476 hibát," és a #476 munkaelem befejeződik, amikor a commit az alapértelmezett ágba kerül feltöltésre vagy egyesítésre. További részletekért lásd a dokumentációt, itt.

Részletesség az automatikus véleményezők számára

Korábban, amikor csoportszintű felülvizsgálókat adott hozzá egy lekéréses kérelemhez, csak egy jóváhagyásra volt szükség a hozzáadott csoporttól. Most már beállíthatja azokat a szabályokat, amelyek előírják, hogy egy csapatból több véleményezőnek is jóvá kell hagynia egy módosítási kérelmet automatikus véleményezők hozzáadásakor. Emellett hozzáadhat egy szabályzatot is, amely megakadályozza, hogy a kérelmezők jóváhagyják a saját módosításaikat.

Szolgáltatásfiók-alapú hitelesítés használata az AKS-hez való csatlakozáshoz

Korábban az Azure Pipelines AKS Deployment Centerből való konfigurálásakor egy Azure Resource Manager-kapcsolatot használtunk. Ennek a kapcsolatnak hozzáférése volt a teljes fürthöz, és nem csak ahhoz a névtérhez, amelyhez a folyamatot konfigurálták. Ezzel a frissítéssel a csővezetékeink szolgáltatásfiók-alapú hitelesítést fognak használni a fürthöz való csatlakozáshoz, így csak a csővezetékkel társított névtérhez férhetnek majd hozzá.

Markdown-fájlok előnézete pull requestben egymás melletti eltéréssel

Az új Előnézet gombbal megtekintheti a Markdown-fájlok megjelenésének előnézetét. Emellett a Nézet gombra kattintva megtekintheti egy fájl teljes tartalmát az egymás melletti sávban.

Manuális építések szabályzatának lejárata

A szabályzatok betartatják a csapat kódminőségét és változáskezelési szabványait. Korábban beállíthatja a build lejárati szabályzatait az automatizált buildekhez. Mostantól a manuális buildekre is beállíthat build lejárati szabályzatokat.

Szabályzat hozzáadása a véglegesítések letiltásához a véglegesítés szerzőjének e-mailje alapján

A rendszergazdák mostantól leküldéses szabályzatot állíthatnak be, hogy megakadályozzák a véglegesítések leküldését egy olyan adattárba, amelyhez a véglegesítési szerző e-mailje nem felel meg a megadott mintának.

Ez a funkció a fejlesztői közösség javaslata alapján került rangsorolásra, hogy hasonló élményt nyújtson. Továbbra is nyitva tartjuk a jegyet, és arra ösztönözzük a felhasználókat, hogy mondják el nekünk, milyen más típusú push szabályzatokat szeretnének látni.

Fájlok áttekintettként megjelölése egy pull kérésben

Időnként át kell tekintenie a nagy számú fájl módosításait tartalmazó lekéréses kérelmeket, és nehéz lehet nyomon követni, hogy mely fájlokat ellenőrizte már. Mostantól egy lekéréses kérelemben áttekintettként jelölheti meg a fájlokat.

A fájlokat áttekintettként megjelölheti a fájlnév melletti legördülő menüben, vagy rámutatva és a fájl nevére kattintva.

Jegyzet

Ez a funkció csak a lekéréses kérelmek áttekintése során nyomon követi az előrehaladást. Ez nem jelenti a lekéréses kérelmekre vonatkozó szavazást, így ezek a jelek csak a véleményező számára lesznek láthatók.

Ezt a funkciót a fejlesztői közösségjavaslata alapján rangsorolásra került.

Új webes felhasználói felület az Azure Repos kezdőlapjaihoz

Most már kipróbálhatja az új modern, gyors és mobilbarát kezdőlapokat az Azure-adattárakban. Ezek a lapok Új adattár kezdőoldalaként érhetők el. A kezdőlapok tartalmazzák az összes oldalt, kivéve a lekéréses kérelmek részleteit, a véglegesítés részleteit és az ág összehasonlítását.

web

Mobil

Tárházközi fiókházirend-felügyelet

Az ág szabályzatok az Azure Repos egy hatékony funkciója, amely segít a fontos ágak védelmében. Bár a szabályzatok projektszinten történő beállításának lehetősége a REST API-ban létezik, nem volt hozzá felhasználói felület. Most a rendszergazdák beállíthatnak szabályzatokat egy adott ágra vagy az alapértelmezett ágra a projekt összes adattárában. Egy rendszergazdának például két minimális felülvizsgálóra lehet szüksége a projekt minden fő ágában végrehajtott lekéréses kérelmekhez a projekt minden adattárában. Az Ágvédelmi hozzáadása funkciót a Tárprojekt beállításai között találja.

Új webplatform-konverzió kezdőoldalai

Frissítettük a Repos kezdőlapok felhasználói felületét, hogy modern, gyors és mobilbarát legyen. Íme két példa a frissített lapokra, a későbbi frissítésekben továbbra is frissíteni fogjuk a többi lapot.

Webes felület:

Mobilélmény:

A Kotlin nyelv támogatása

Örömmel jelentjük be, hogy mostantól támogatjuk a Kotlin nyelv kiemelését a fájlszerkesztőben. A kiemelés javítja a Kotlin-szövegfájl olvashatóságát, és segít a hibák gyors keresésében. Ezt a funkciót a fejlesztői közösségjavaslata alapján rangsorítottuk.

Egyéni értesítési előfizetés a lekéréses kérelmek piszkozatához

A lekéréses kérelmekről érkező e-mail-értesítések számának csökkentése érdekében mostantól létrehozhat egy egyéni értesítési előfizetést piszkozatállapotúlétrehozott vagy frissített lekéréses kérelmekhez. E-maileket kaphat kifejezetten a lekéréses kérelmek piszkozatához, vagy kiszűrheti a lekéréses kérelmek tervezetéből érkező e-maileket, így a csapat nem kap értesítést, mielőtt a lekéréses kérelem készen áll a felülvizsgálatra.

Továbbfejlesztett PR-kezelhetőség

Ha sok lekéréses kérelmet szeretne áttekinteni, nehéz lehet megérteni, hogy hol kell először elvégeznie a műveletet. A lekéréses kérelmek kezelhetőségének javítása érdekében mostantól több egyéni lekérdezést is létrehozhat a lekéréses kérelmek listájának lapján, és számos új lehetőséget kínál a szűrésre, például a vázlatállapot alapján. Ezek a lekérdezések külön és összecsukható szakaszokat hoznak létre a lekéréses kérelem oldalán a "Létrehozva velem" és a "Hozzárendelve hozzám" mellett. A Szavazás menüben vagy a lekéréses kérelmek listájának helyi menüjében is elutasíthatja a lekéréses kérelmek áttekintését. Az egyéni szakaszokban mostantól külön fülek jelennek meg azoknak a lekéréses kérelmeknek, amelyeken felülvizsgálatot nyújtott vagy elutasított. Ezek az egyéni lekérdezések a gyűjtemény kezdőlapjának "Lekéréses kérelmek" lapján található adattárakban működnek. Ha vissza szeretne térni egy lekéréses kérelemhez, megjelölheti azt, és azok megjelennek a lista tetején. Az automatikus kiegészítésre beállított lekérési kérelmeket a listában egy "Automatikus kiegészítés" címkével jelölik meg.

Csővezetékek

Többfázisú folyamatok

Már dolgozunk egy frissített felhasználói élményen, a csővezetékek kezelésére. Ezek a frissítések modernebbé teszik a folyamatokat, és összhangban vannak az Azure DevOps irányával. Ezenkívül ezek a frissítések egyetlen felületen egyesítik a klasszikus buildfolyamatokat és a többfázisú YAML-folyamatokat. Mobilbarát, és különböző fejlesztéseket tesz lehetővé a folyamatok kezeléséhez. Részletezheti és megtekintheti a folyamat részleteit, futtathat részleteket, folyamatelemzéseket, feladatadatokat, naplókat stb.

Az új felület a következő képességeket tartalmazza:

• több fázis megtekintése és kezelése
• folyamatfuttatások jóváhagyása
• görgessen vissza a naplókba, amíg egy folyamat még folyamatban van
• a folyamat ágonkénti egészségi állapota.

Folyamatos üzembe helyezés a YAML-ben

Örömmel mutatjuk be az Azure Pipelines YAML CD-funkcióit. Mostantól egységes YAML-felületet kínálunk, így az egyes folyamatokat úgy konfigurálhatja, hogy a CI, a CD vagy a CI és a CD együttesen is elvégezhetők. A YAML CD-funkciók számos új speciális funkciót vezetnek be, amelyek minden gyűjteményhez elérhetők többfázisú YAML-folyamatokat használva. Néhány fontos elem:

• többfázisú YAML-folyamatok (CI-hez és CD-hez)
• Erőforrások jóváhagyása és ellenőrzése
• környezetek és üzembehelyezési stratégiák
• Kubernetes és Virtuális Gép erőforrásokat a környezetben
• Alkalmazások az együttműködéshez
• Frissített UX a szolgáltatási kapcsolatokhoz
• YAML-folyamatok erőforrásai

Ha készen áll a fejlesztésre, tekintse meg a dokumentációt vagy a blogot többfázisú CI/CD-pipeline-ek építéséhez.

Folyamatváltozók kezelése a YAML-szerkesztőben

Frissítettük a folyamatváltozók kezelésének élményét a YAML-szerkesztőben. A yaML-folyamatok változóinak hozzáadásához vagy frissítéséhez már nem kell a klasszikus szerkesztőbe lépnie.

Kiadások jóváhagyása közvetlenül a Releases Hubról

A függőben lévő jóváhagyások alapján történő működés egyszerűbbé vált. Korábban a kiadás részleteinek oldaláról is jóváhagyhatták a kiadást. Most már közvetlenül a Releases hubról is jóváhagyhatja a kiadásokat.

Fejlesztések a folyamatok használatának első lépéseiben

A közös kérés az első lépések varázslójával szemben az volt, hogy a létrehozott fájlt át lehessen nevezni. Jelenleg azure-pipelines.yml van bejelentkezve az adattár gyökerénél. A folyamat mentése előtt ezt frissítheti egy másik fájlnévre vagy helyre.

Végül, mostantól mind Ön, mind mi nagyobb ellenőrzést gyakorolhatunk, amikor a azure-pipelines.yml fájlt egy másik ágba küldi be, mivel dönthet úgy is, hogy kihagyja a lekéréses kérelem létrehozását az adott ágból.

Teljes körű YAML-dokumentum előnézete a folyamat véglegesítése vagy futtatása nélkül

Hozzáadtunk egy előzetes verziót, de nem futtatunk módot YAML-folyamatokhoz. Most kipróbálhat egy YAML-pipelint anélkül, hogy azt egy adattárba köteleződne el, vagy futtatná azt. Egy meglévő folyamat és egy opcionális új YAML-payload megadásával ez az új API visszaadja a teljes YAML-folyamatot. A jövőbeli frissítésekben ezt az API-t egy új szerkesztőfunkcióban fogjuk használni.

Fejlesztőknek: Küldjön POST kérést a dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview-ra egy ilyen JSON-törzzsel:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

A válasz tartalmazza a renderelt YAML-t.

Cron-ütemezések a YAML-ben

Korábban a felhasználói felület szerkesztőjével megadhatja a YAML-folyamatok ütemezett eseményindítóit. Ezzel a kiadással cron szintaxissal ütemezheti a buildeket a YAML-fájlban, és kihasználhatja az alábbi előnyöket:

1. Konfigurálás kódként: Nyomon követheti az ütemezéseket, valamint a csővezetéket a kód részeként.
2. Kifejező: Több kifejezőerővel rendelkezik az ütemezések meghatározásában, mint amit a felhasználói felületen képes volt megtenni. Egyszerűbb például egyetlen ütemezést megadni, amely óránként indítja el a futtatásokat.
3. Iparági szabvány: Sok fejlesztő és rendszergazda már ismeri a cron szintaxist.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Azt is megkönnyítettük, hogy diagnosztizálja a cron ütemezéssel kapcsolatos problémákat. A Futtatás folyamat menüjében az Ütemezett futtatások menüben megtekintheti a folyamat közelgő néhány ütemezett futását, hogy könnyebben diagnosztizálhassa a cron-ütemezésekkel kapcsolatos hibákat.

Szolgáltatáskapcsolatok felhasználói felületének frissítései

A szolgáltatáskapcsolatok kezeléséhez már dolgozunk egy frissített felhasználói felületen. Ezek a frissítések modernebbé és konzisztenssé teszik a szolgáltatáskapcsolatot az Azure DevOps irányával. Az év elején bevezettük a szolgáltatáskapcsolatok új felhasználói felületét előzetes verziójú funkcióként. Köszönet mindenkinek, aki kipróbálta az új élményt, és értékes visszajelzést adott nekünk.

A felhasználói élmény frissítése mellett két olyan képességet is hozzáadtunk, amelyek kritikus fontosságúak a YAML-folyamatok szolgáltatáskapcsolatainak igénybevételéhez: a folyamatengedélyezésekhez, a jóváhagyásokhoz és az ellenőrzésekhez.

Az új felhasználói felület alapértelmezés szerint be lesz kapcsolva ezzel a frissítéssel. Továbbra is lehetősége lesz kikapcsolni az előnézetet.

Jegyzet

Új funkcióként tervezzük bevezetni szolgáltatáskapcsolatok projektközi megosztását. A megosztási felületről és a biztonsági szerepkörökről itt talál további információt .

Fázisok kihagyása YAML-folyamatban

Manuális futtatás indításakor előfordulhat, hogy a folyamat néhány szakaszát ki kell hagynia. Például, ha nem szeretne éles környezetben üzembe helyezni, vagy ha azt szeretné, hogy néhány éles környezetbe ne történjen meg az üzembe helyezés. Most már ezt is elvégezheti a YAML-csővezetékekkel.

A frissített futtatási folyamat panel megjeleníti a YAML-fájl szakaszainak listáját, és lehetősége van kihagyni egy vagy több szakaszt. A szakaszok kihagyásakor körültekintően kell eljárnia. Ha például az első fázis olyan összetevőket hoz létre, amelyek szükségesek a következő szakaszokhoz, akkor nem szabad kihagynia az első szakaszt. A futtatási panel általános figyelmeztetést jelenít meg, amikor kihagyja az alárendelt függőségekkel rendelkező fázisokat. Önre van bízva, hogy eldöntse, ezek a függőségek valódi artefaktum-függőségek-e, vagy csak az üzembe helyezések sorrendje miatt vannak jelen.

A fázisok kihagyása egyenértékű a szakaszok közötti függőségek újrafordításával. A kihagyott szakasz közvetlen alárendelt függőségei a kihagyott szakasz felsőbb rétegbeli szülőjától függenek. Ha a futtatás sikertelen, és sikertelen szakaszt kísérel meg újrafutni, az adott kísérlet is ugyanazzal a kihagyási viselkedéssel fog rendelkezni. A kihagyott szakaszok módosításához új futtatást kell elindítani.

Szolgáltatáskapcsolatok új felhasználói felületét alapértelmezett élményként

Új szolgáltatáskapcsolatok felhasználói felülete van. Ez az új felhasználói felület modern tervezési szabványokra épül, és számos kritikus funkcióval rendelkezik, amelyek támogatják a többfázisú YAML CD-folyamatokat, például a jóváhagyásokat, az engedélyezéseket és a projektközi megosztást.

További információ a szolgáltatások kapcsolatairól itt.

Folyamaterőforrás-verzióválasztó a futtatás indítása párbeszédablakban

Hozzáadtuk a folyamaterőforrás-verziók manuális felvételének lehetőségét a futtatási párbeszéd létrehozásakor. Ha folyamatot használ erőforrásként, egy másik folyamatban, akkor most már kiválaszthatja a folyamat verzióját a futtatás indításakor.

az CLI fejlesztései az Azure Pipelineshoz

Folyamatváltozócsoport- és változókezelési parancsok

A YAML-alapú folyamatokat nehéz lehet egyik projektből a másikba portolni, mivel manuálisan kell beállítania a folyamatváltozókat és a változócsoportokat. A folyamat változócsoport és változók felügyeleti parancsaival azonban mostantól szkriptelheti a folyamatváltozók és változócsoportok beállítását és kezelését, amelyek viszont verzióvezéreltek lehetnek, így egyszerűen megoszthatja a folyamatok egyik projektből a másikba való áthelyezésére és beállítására vonatkozó utasításokat.

Folyamat futtatása pr-ághoz

Pr létrehozásakor nehéz lehet ellenőrizni, hogy a módosítások megszakíthatják-e a folyamat futtatását a célágon. Ha azonban képes elindítani egy folyamatfuttatást vagy egy build várólistára helyezését egy PR-ághoz, most már ellenőrizheti és megjelenítheti a folyamatban lévő módosításokat a célfolyamaton való futtatással. További információt az az pipelines run és az pipelines build-üzenetsor parancsdokumentációjában talál.

Az első folyamatfuttatás kihagyása

Folyamatok létrehozásakor előfordulhat, hogy YAML-fájlt szeretne létrehozni és véglegesíteni, és nem aktiválni a folyamatfuttatást, mert az számos okból hibás futtatást eredményezhet – az infrastruktúra nem áll készen, vagy változó-/változócsoportok létrehozására és frissítésére van szükség stb. Az Azure DevOps CLI-vel most már kihagyhatja az első automatizált folyamatfuttatást egy folyamat létrehozásakor a --skip-first-run paraméter hozzáadásával. További információért keresse a pipeline create parancs dokumentációját.

Szolgáltatásvégpont-parancsok fejlesztése

A szolgáltatásvégpont cli-parancsai csak az Azure RM és a GitHub szolgáltatásvégpont beállítását és kezelését támogatták. Ezzel a kiadással azonban a szolgáltatásvégpont-parancsok lehetővé teszik bármely szolgáltatásvégpont létrehozását a konfiguráció fájlon keresztüli biztosításával, és optimalizált parancsokat biztosít – az az devops service-endpoint github és az az devops service-endpoint azurerm, amelyek első osztályú támogatást nyújtanak az ilyen típusú szolgáltatásvégpontok létrehozásához. További információért tekintse meg a parancs dokumentációját.

Üzembehelyezési feladatok

Az üzembehelyezési feladat az alkalmazás környezetbe való üzembe helyezéséhez használt speciális feladat. Ezzel a frissítéssel az üzembe helyezési feladatban lépéshivatkozások támogatását is hozzáadtuk. Meghatározhat például egy lépéskészletet egy fájlban, és hivatkozhat rá egy üzembe helyezési feladatban.

Az üzembe helyezési feladathoz további tulajdonságokat is hozzáadtunk. Íme például egy üzembe helyezési feladat néhány tulajdonsága, amelyet most már beállíthat.

• timeoutInMinutes – mennyi ideig futtassa a feladatot, mielőtt automatikus megszakításra kerül sor
• cancelTimeoutInMinutes – mennyi időt adjon a feladatok futtatásának, még akkor is, ha törölve lettek, mielőtt megszakítaná őket.
• feltétel – feladat feltételes futtatása
• változók – A hardkódolt értékek közvetlenül hozzáadhatók, vagy változócsoportokra, Azure Key Vault által támogatott változócsoportra hivatkozhat, vagy hivatkozhat egy fájlban definiált változókészletre.
• continueOnError – ha a jövőbeli feladatok akkor is futni fognak, ha ez az üzembe helyezési feladat meghiúsul; alapértelmezés szerint "false" (hamis)

Az üzembehelyezési feladatokról és az üzembehelyezési feladat megadására szolgáló teljes szintaxisról további információt Üzembehelyezési feladatcímű témakörben talál.

A társított CD-csővezetékek információinak megjelenítése a CI-csővezetékekben

Támogatást adtunk a CD YAML-folyamatok részleteihez, ahol a CI-folyamatokat folyamaterőforrásoknak nevezzük. A CI-folyamat futtatási nézetében most megjelenik egy új "Társított folyamatok" lap, ahol megtalálhatja a folyamatot használó összes folyamatfuttatást és az abból származó összetevőket.

GitHub-csomagok támogatása YAML-folyamatokban

Nemrég vezettünk be egy új, csomagoknak nevezett erőforrástípust, amely támogatja NuGet- és npm- csomagokat a GitHubról, mint erőforrást a YAML-folyamatokban. Az erőforrás részeként most már megadhatja a GitHubról használni kívánt csomagtípust (NuGet vagy npm). Az automatizált folyamatindítókat egy új csomagverzió megjelenésekor is engedélyezheti. A támogatás jelenleg csak a GitHubról származó csomagok felhasználásához érhető el, de a jövőben azt tervezzük, hogy kiterjesztjük a támogatást más csomagtárházakból származó csomagok használatára, például NuGet, npm, AzureArtifacts és még sok más csomag használatára. Részletekért tekintse meg az alábbi példát:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Jegyzet

A GitHub-csomagok jelenleg csak a PAT-alapú hitelesítést támogatják, ami azt jelenti, hogy a csomagerőforrás GitHub-szolgáltatáskapcsolatának PAT típusúnak kell lennie. A korlátozás feloldását követően támogatást nyújtunk más típusú hitelesítésekhez.

Alapértelmezés szerint a csomagok nem töltődnek le automatikusan a feladatokba, ezért bevezettünk egy getPackage makrót, amely lehetővé teszi az erőforrásban definiált csomag használatát. Részletekért tekintse meg az alábbi példát:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Kubernetes szolgáltatás klaszter hivatkozás a Kubernetes környezetek erőforrás nézetében

Hozzáadtunk egy hivatkozást a Kubernetes-környezetek erőforrásnézetéhez, így a megfelelő fürt Azure-paneljére navigálhat. Azokra a környezetekre vonatkozik, amelyek Azure Kubernetes Service-fürtökben lévő névterekhez vannak leképezve.

Kubernetes-erőforrásnézetében

Értesítési előfizetések mappaszűrőinek feloldása

A mappák lehetővé teszik a folyamatok rendszerezését a könnyebb felderíthetőség és a biztonság szabályozása érdekében. Gyakran előfordulhat, hogy egyéni e-mail-értesítéseket szeretne konfigurálni az összes kiadási folyamathoz, amelyeket egy mappa összes folyamata képvisel. Korábban több előfizetést kellett konfigurálnia, vagy összetett lekérdezéssel kellett rendelkeznie az előfizetésekben a szűrt e-mailek lekéréséhez. Ezzel a frissítéssel most már hozzáadhat egy kiadási mappa záradékot a üzembe helyezés befejeződött, és jóváhagyást események függőben, és egyszerűsítheti az előfizetéseket.

Munkaelemek összekapcsolása többfázisú YAML-folyamatokkal

Jelenleg a munkaelemeket automatikusan összekapcsolhatja a klasszikus buildekkel. A YAML-vezetékeihez azonban ez nem volt lehetséges. Ezzel a frissítéssel megoldottuk ezt a hiányosságot. Ha sikeresen futtat egy folyamatot végrehajtó csatornát egy adott ágból származó kód használatával, az Azure Pipelines automatikusan összekapcsolja a futtatást az összes munkaelemmel (amelyeket a kódban található véglegesítések alapján azonosít). A munkaelem megnyitásakor láthatja azokat a futtatásokat, amelyekben az adott munkaelem kódja készült. Ennek konfigurálásához használja a folyamat beállítások panelét.

Többfázisú YAML-folyamat végrehajtásának szakaszlemondása

Többfázisú YAML-folyamat futtatásakor most már megszakíthatja egy szakasz végrehajtását, amíg az folyamatban van. Ez akkor hasznos, ha tudja, hogy a szakasz sikertelen lesz, vagy ha van egy másik futtatás, amelyet el szeretne kezdeni.

Sikertelen újrapróbálkozás szakaszai

A többfázisú folyamatok egyik leggyakrabban igényelt funkciója a sikertelen fázisok újrapróbálkozásának lehetősége anélkül, hogy az elejétől kezdve kellene kezdenie. Ezzel a frissítéssel a funkció nagy részét hozzáadjuk.

Most már újrapróbálkozhat egy folyamatszakaszban, ha a végrehajtás sikertelen. Az első kísérlet során meghiúsult és a sikertelen feladatoktól tranzitív módon függő feladatok újrapróbálkozásra kerülnek.

Ezzel több módon is időt takaríthat meg. Ha például több feladatot futtat egy fázisban, előfordulhat, hogy az egyes fázisok egy másik platformon futtatják a teszteket. Ha az egyik platform tesztjei sikertelenek, míg mások átmennek, időt takaríthat meg, ha nem futtatja újra az átadott feladatokat. Egy másik példaként előfordulhat, hogy egy üzembe helyezési szakasz meghiúsult a pelyhes hálózati kapcsolat miatt. Ha újrapróbálkozza ezt a szakaszt, azzal időt takaríthat meg, ha nem kell újabb buildet létrehoznia.

A funkció néhány ismert hiányosságot tartalmaz. Nem próbálkozhat például olyan fázissal, amelyet kifejezetten megszakított. Dolgozunk ezen hiányosságok megszüntetésén a jövőbeli frissítésekben.

Jóváhagyások többfázisú YAML-folyamatokban

A YAML CD-folyamatok manuális jóváhagyásokat tartalmazhatnak. Az infrastruktúra-tulajdonosok megvédhetik környezetüket, és manuális jóváhagyást kérhetnek, mielőtt bármely folyamat egy szakasza üzembe helyezené őket. Az infrastruktúra (környezet) és az alkalmazás (folyamat) tulajdonosai közötti szerepkörök teljes elkülönítésével biztosíthatja a manuális kijelentkezést egy adott folyamatban való üzembe helyezéshez, és központi vezérlést kap abban, hogy ugyanazokat az ellenőrzéseket alkalmazza az összes üzembe helyezésre a környezetben.

A pipeline folyamata, amely a fejlesztői környezetbe történő telepítést végzi, a fázis elején megáll jóváhagyásra.

A kapuk időtúllépési limitjének és gyakoriságának növelése

Korábban a kiadási folyamatokban a kapu időtúllépési korlátja három nap volt. Ezzel a frissítéssel az időkorlát 15 napra növekedett, hogy lehetővé tegye a hosszabb időtartamú kapuk használatát. A kapu gyakoriságát 30 percnöveltük.

Új buildképsablon a Dockerfile-hoz

Korábban, amikor új csővezetéket hozott létre egy Dockerfile számára, a sablon azt ajánlotta, hogy a képet töltse fel egy Azure Container Registry-be, és helyezze üzembe egy Azure Kubernetes-szolgáltatás során. Új sablont adtunk hozzá, amely lehetővé teszi, hogy az ügynökkel képet hozzon létre anélkül, hogy le kellene küldenie egy tárolóregiszterbe.

Új feladat az Azure App Service alkalmazásbeállításainak konfigurálásához

Az Azure App Service különböző beállításokon keresztül teszi lehetővé a konfigurációt, például az alkalmazásbeállításokat, a kapcsolati sztringeket és más általános konfigurációs beállításokat. Most már rendelkezünk egy új Azure Pipelines-feladattal Azure App Service-beállítások, amely támogatja a beállítások tömeges konfigurálását a webalkalmazás JSON-szintaxisával vagy bármely üzembehelyezési helyével. Ez a feladat más App Service-feladatokkal együtt használható a üzembe helyezéséhez, a kezeléséhez és konfigurálásához a webalkalmazásokat, a függvényalkalmazásokat vagy bármely más tárolóalapú App Servicest.

Az Azure App Service mostantól támogatja a Felcserélés előnézettel való használatát.

Az Azure App Service mostantól támogatja a Felcserélést a előzetes verziójával az üzembehelyezési helyeken. Ez egy jó módszer az alkalmazás gyártási konfiguráció használatával történő ellenőrzésére, mielőtt az alkalmazás ténylegesen áttér egy előkészítési környezetből az éles környezetbe. Ez azt is biztosítaná, hogy a cél/éles pont ne tapasztalja az állásidőt.

Az Azure App Service-feladat mostantól támogatja ezt a többfázisú felcserélést az alábbi új műveleteken keresztül:

• Felcserélés indítása előzetes nézettel – Felcserélést indítva előzetes nézettel (többfázisú felcserélés), és a célrés (például az éles rés) konfigurációját alkalmazza a forráshelyre.
• Teljes csere előnézettel – Ha készen áll a függőben lévő csere befejezésére, válassza a Teljes csere előnézettel műveletet.
• Felcserélés lemondása előnézettel – Függőben lévő felcserélés lemondásához válassza a Felcserélés lemondása előnézettel lehetőséget.

Szakaszszintű szűrő az Azure Container Registryhez és a Docker Hub-összetevőkhöz

Korábban az Azure Container Registry és a Docker Hub-összetevők reguláris kifejezésszűrői csak a kiadási folyamat szintjén voltak elérhetők. Most már a színpad szintjén is hozzáadták őket.

A YAML-csővezetékek jóváhagyásainak fejlesztései

Engedélyeztük a jóváhagyások konfigurálását a szolgáltatáskapcsolatokon és az ügynökkészleteken. A jóváhagyásokhoz a szerepkörök elkülönítését követjük az infrastruktúra tulajdonosai és a fejlesztők között. Az erőforrások, például a környezetek, a szolgáltatáskapcsolatok és az ügynökkészletek jóváhagyásainak konfigurálásával biztos lehet abban, hogy az erőforrásokat használó összes folyamatfuttatáshoz először jóváhagyásra lesz szükség.

A felhasználói élmény hasonló a környezetek jóváhagyásának konfigurálásához. Ha egy fázisban hivatkozott erőforrás jóváhagyása függőben van, a folyamat végrehajtása megvárja a folyamat manuális jóváhagyását.

Tárolóstruktúra tesztelésének támogatása az Azure Pipelinesban

A tárolók használata egyre nő az alkalmazásokban, ezért robusztus tesztelésre és ellenőrzésre van szükség. Az Azure Pipelines mostantól támogatja a tárolószerkezet-teszteket. Ez a keretrendszer kényelmes és hatékony módot kínál a tárolók tartalmának és szerkezetének ellenőrzésére.

A rendszerkép struktúráját négy, együttesen futtatható tesztkategória alapján ellenőrizheti: parancstesztek, fájllétrehozási tesztek, fájltartalom-tesztek és metaadat-tesztek. A folyamat eredményeinek használatával go/no go döntéseket hozhat. A tesztadatok a folyamatfuttatásban egy hibaüzenettel érhetők el, amely segít a hibák jobb elhárításában.

Adja meg a konfigurációs fájl és a kép részleteit

Tesztadatok és összegzés

Kiadási csővezeték-dekorátorok

A pipeline dekorátorok lehetővé teszik, hogy lépéseket adjunk hozzá minden feladat elejéhez és végéhez. Ez nem ugyanaz, mint a lépések hozzáadása egyetlen definícióhoz, mert egy gyűjtemény összes folyamatára vonatkozik.

Támogatjuk a dekorátorokat az építési és YAML-csővezetékek során, így az ügyfelek központilag vezérelhetik a feladataik lépéseit. Most már a támogatást kiterjesztjük a kiadási folyamatokra, beleértve a release pipeline-eket is. Bővítményeket hozhat létre az új közreműködői pontot célzó lépések hozzáadásához, és azok a kiadási folyamatok összes ügynökfeladatához hozzá lesznek adva.

Az Azure Resource Manager (ARM) üzembe helyezése előfizetési és felügyeleti csoport szintjén

Korábban csak az erőforráscsoport szintjén támogattuk az üzembe helyezéseket. Ezzel a frissítéssel támogattuk az ARM-sablonok üzembe helyezését az előfizetés és a felügyeleti csoport szintjén is. Ez segít az erőforrások egy csoportjának együttes üzembe helyezésében, de különböző erőforráscsoportokba vagy előfizetésekbe helyezi őket. Az Azure Site Recovery biztonsági mentési virtuális gépének üzembe helyezése például egy külön erőforráscsoportban és helyen.

CD-képességek a többfázisú YAML-folyamatokhoz

Mostantól felhasználhatja a CI-folyamat által közzétett összetevőket, és engedélyezheti a folyamatvégzítési eseményindítókat. A többfázisú YAML-folyamatokban pipelines vezetünk be erőforrásként. A YAML-ben most már hivatkozhat egy másik folyamatra, és engedélyezheti a CD-eseményindítókat is.

Íme a folyamatok erőforrásának részletes YAML-sémája.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Emellett letöltheti a folyamaterőforrás által közzétett összetevőket a - download tevékenységgel.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

További részletekért tekintse meg az artifaktumok letöltésének dokumentációját, amely elérhető itt .

A Kubernetes környezeten a kanári telepítési stratégia vezénylése

Az alkalmazásfrissítések folyamatos bevezetésének egyik fő előnye, hogy a frissítéseket gyorsan be lehet vezetni az adott mikroszolgáltatások éles környezetébe. Ez lehetővé teszi, hogy gyorsan reagáljon az üzleti követelmények változásaira. Környezet első osztályú koncepcióként lett bevezetve, amely lehetővé teszi az üzembe helyezési stratégiák vezénylését és a nulla állásidővel történő kiadásokat. Korábban támogattuk a runOnce stratégiát, amely egymás után hajtotta végre a lépéseket. A többfázisú folyamatokban a kanári stratégia támogatásával csökkentheti a kockázatot, ha fokozatosan vezeti be a módosítást egy kisebb csoport számára. Az új verzióba vetett nagyobb bizalommal kezdheti el a bevezetést az infrastruktúra több kiszolgálójához, és több felhasználót irányíthat hozzá.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

A Kubernetes kanári-stratégiája először a módosításokat 10% poddal fogja üzembe helyezni, majd következik 20%, miközben figyeli az állapotot a postRouteTrafficsorán. Ha minden jól megy, akkor 100-ra növeli%.

Korai visszajelzést keresünk a virtuálisgép-erőforrás környezetekben való támogatásáról és a több gépen futó üzembe helyezési stratégia végrehajtásáról. A regisztrációhoz lépjen kapcsolatba velünk.

JÓVÁHAGYÁSI SZABÁLYZATOK YAML-folyamatokhoz

A YAML-folyamatokban egy erőforrás tulajdonos által vezérelt jóváhagyási konfigurációját követjük. Az erőforrás-tulajdonosok jóváhagyásokat konfigurálnak az erőforráson, és az összes olyan folyamat, amely használja az erőforrást, szünetel a jóváhagyások érdekében, mielőtt a fázis megkezdődne, amely az erőforrást felhasználja. A SOX-alapú alkalmazások tulajdonosai gyakran korlátozzák, hogy aki az üzembe helyezést kérelmezi, jóváhagyhassa a saját üzembe helyezéseiket.

Mostantól használhatja a speciális jóváhagyási beállításokat ahhoz, hogy olyan jóváhagyási szabályzatokat állítson be, mint például hogy a kérelmező ne hagyhassa jóvá, szükség legyen a jóváhagyásra a felhasználók egy részétől, és kezelje a jóváhagyási időkorlátot.

Az ACR mint első osztályú folyamaterőforrás

Ha a folyamat részeként az ACR-ben (Azure Container Registry) közzétett tárolórendszerképet kell használnia, és az új rendszerkép közzétételekor aktiválnia kell a folyamatot, használhatja az ACR-tárolóerőforrást.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Emellett az ACR-rendszerkép metaadatai előre definiált változókkal is elérhetők. Az alábbi lista tartalmazza azokat az ACR-változókat, amelyekkel definiálhat egy ACR-tárolóerőforrást a folyamatban.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Fejlesztések az artefaktumok ellenőrzési szabályzatának kiértékeléséhez a folyamatláncokban

Fejlesztettük a értékelési eszköz ellenőrzését, hogy egyszerűbb legyen a szabályzatok hozzáadása az előre definiált szabályzat-definíciók listájából. A szabályzatdefiníció automatikusan létrejön, és hozzáadódik a ellenőrzési konfigurációhoz, amelyet szükség esetén frissíteni lehet.

Kimeneti változók támogatása egy üzembe helyezési feladatban

Most már definiálhat kimeneti változókat az üzembehelyezési feladat életciklus-horgaiban, és felhasználhatja őket más alárendelt lépésekben és feladatokban ugyanabban a fázisban.

Az üzembehelyezési stratégiák végrehajtása során az alábbi szintaxissal érheti el a kimeneti változókat a feladatok között.

• runOnce stratégia esetén: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• kanári stratégiához: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• gördülő stratégiához: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

További információ a többfeladatos kimeneti változó beállításáról

A kritikus módosítások visszaállításának elkerülése

A klasszikus kiadási folyamatokban gyakori, hogy rendszeres frissítések ütemezett központi telepítéseire támaszkodnak. Ha azonban kritikus javítást végez, dönthet úgy, hogy sávon kívüli manuális üzembe helyezést indít el. Ha így tesz, a régebbi kiadások továbbra is ütemezettek maradnak. Ez kihívást jelentett, mivel a manuális üzembe helyezés vissza lett állítva, amikor az üzembe helyezések az ütemezés szerint folytatódtak. Sokan jelentették ezt a problémát, és már kijavítottuk. A javítással a környezet összes régebbi ütemezett üzembe helyezése törlődne, amikor manuálisan indítana el egy üzembe helyezést. Ez csak akkor alkalmazható, ha a sorbaállítási beállítás a "Legutóbbi telepítés és mások megszakítása" beállításként van kiválasztva.

Egyszerűsített erőforrás-engedélyezés YAML-folyamatokban

Az erőforrás bármi, amit a csővezeték használ, de nem része annak. Az erőforrásokat a használatuk előtt engedélyezni kell. Korábban, amikor jogosulatlan erőforrásokat használt egy YAML-folyamatban, az erőforrás-engedélyezési hibával meghiúsult. A sikertelen futtatás összefoglaló oldaláról kellett engedélyeznie az erőforrásokat. Emellett a folyamat meghiúsult, ha jogosulatlan erőforrásra hivatkozó változót használt.

Mostantól egyszerűbbé tesszük az erőforrás-engedélyezések kezelését. A futtatás sikertelensége helyett a futtatás megvárja az erőforrások engedélyeit az erőforrást használó szakasz elején. Az erőforrás tulajdonosa megtekintheti a folyamatot, és engedélyezheti az erőforrást a Biztonság lapon.

Összetevő-ellenőrzés kiértékelése

Most már definiálhat egy szabályzatkészletet, és hozzáadhatja a szabályzat kiértékelését a tárolólemezkép-összetevők környezetének ellenőrzéseként. Amikor egy folyamat fut, a végrehajtás szünetel, mielőtt elindít egy olyan szakaszt, amely a környezetet használja. A rendszer kiértékeli a megadott szabályzatot az üzembe helyezett rendszerkép elérhető metaadatai alapján. Az ellenőrzés akkor megy át, ha a szabályzat sikeres, és a szakaszt sikertelenként jelöli meg, ha az ellenőrzés meghiúsul.

Az ARM-sablon üzembehelyezési feladatának frissítései

Korábban nem szűrtük a szolgáltatáskapcsolatokat az ARM-sablon üzembe helyezési feladatában. Ez azt eredményezheti, hogy az üzembe helyezés meghiúsul, ha alacsonyabb hatókörű szolgáltatáskapcsolatot választ az ARM-sablonok szélesebb hatókörbe történő üzembe helyezéséhez. Most hozzáadtuk a szolgáltatáskapcsolatok szűrését, hogy kiszűrjük az alacsonyabb hatókörű szolgáltatáskapcsolatokat a választott üzembehelyezési hatókör alapján.

ReviewApp a környezetben

ReviewApp a Git-adattár minden lekéréses kérelmét üzembe helyezi egy dinamikus környezeti erőforrásba. A véleményezők láthatják, hogyan jelennek meg ezek a változtatások, illetve más függő szolgáltatásokkal is dolgozhatnak, mielőtt a főágba egyesítenék őket, és bevezetnék őket a termelési környezetbe. Így egyszerűen hozhat létre és kezelhet reviewApp-erőforrásokat, és kihasználhatja a környezeti funkciók nyomon követhetőségét és diagnosztizálását. Az reviewApp kulcsszó használatával létrehozhat egy erőforrás klónját (dinamikusan létrehozhat egy új erőforrást egy meglévő erőforrás alapján egy környezetben), és hozzáadhatja az új erőforrást a környezethez.

Az alábbiakban egy minta YAML-kódrészletet tekintünk meg, amely a reviewApp környezetekben való használatát ismerteti.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Automatikus és felhasználó által megadott metaadatok gyűjtése a folyamatból

Mostantól engedélyezheti az automatikus és felhasználó által megadott metaadatok gyűjtését a folyamatfeladatokból. Metaadatok segítségével érvényesítheti az artefaktum-szabályzatot egy környezetben az artefaktum-ellenőrzés kiértékelésével.

Virtuálisgép-telepítések környezetekkel

A környezetek egyik legkeresettebb funkciója a virtuális gépek üzembe helyezése volt. Ezzel a frissítéssel engedélyezzük a virtuálisgép-erőforrást a környezetekben. Mostantól több gépen is vezényelheti az üzembe helyezéseket, és YAML-folyamatokkal hajthat végre működés közbeni frissítéseket. Az ügynököt közvetlenül is telepítheti az egyes célkiszolgálókra, és működés közbeni üzembe helyezést is hajthat ezeken a kiszolgálókon. Emellett a célgépek teljes feladatkatalógusát is használhatja.

A működés közbeni üzembe helyezés az alkalmazás előző verziójának példányait felváltja az alkalmazás új verziójának példányaival az egyes iterációkban lévő gépeken (gördülő készleten).

Guruló telepítés például egyes iterációkban legfeljebb öt célt frissít. maxParallel határozza meg a párhuzamosan üzembe helyezhető célok számát. A kijelölés azoknak a céloknak a számát adja meg, amelyeknek bármikor rendelkezésre kell állniuk, kivéve azokat a célokat, amelyeken üzembe helyezve vannak. Az üzembe helyezés során a siker és a hibafeltételek meghatározására is használható.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Jegyzet

Ezzel a frissítéssel az aktuális folyamatból és a kapcsolódó folyamaterőforrásokból származó összes elérhető összetevő csak deploy életciklus-horogban lesz letöltve. A letöltést azonban Folyamatösszetevő letöltése feladatmegadásával választhatja. A funkció néhány ismert hiányosságot tartalmaz. Ha például újrapróbálkozott egy fázissal, az újrafuttatja az üzembe helyezést az összes virtuális gépen, nem csak sikertelen célokon. Dolgozunk ezen hiányosságok megszüntetésén a jövőbeli frissítésekben.

Az Ön telepítéseinek további vezérlése

Az Azure Pipelines már egy ideje támogatja a manuális jóváhagyással vezérelhető üzembe helyezéseket. A legújabb fejlesztésekkel mostantól további irányítással rendelkezik a telepítések felett. A jóváhagyások mellett az erőforrás-tulajdonosok mostantól automatizált checks-t is hozzáadhatnak a biztonsági és minőségi szabályzatok ellenőrzéséhez. Ezek az ellenőrzések műveleteket aktiválhatnak, majd megvárhatják, amíg befejeződnek. A további ellenőrzések használatával mostantól több forrás alapján is meghatározhatja az állapotfeltételeket, és meggyőződhet arról, hogy az erőforrásokat célzó összes üzembe helyezés biztonságos, függetlenül az üzembe helyezést végző YAML-folyamattól. Az egyes ellenőrzések kiértékelése rendszeres időközönként megismételhető a megadott újrapróbálkozási időköz alapján. A következő további ellenőrzések érhetők el:

• Bármely REST API meghívása és ellenőrzés végrehajtása a válasz tartalma vagy a külső szolgáltatás visszahívása alapján.
• Azure-függvény meghívása és érvényesítés végrehajtása a függvény válasza vagy visszahívása alapján
• Azure Monitor-szabályok lekérdezése aktív riasztásokhoz
• Győződjön meg arról, hogy a folyamat kibővít egy vagy több YAML-sablont

Jóváhagyási értesítés

Amikor jóváhagyást ad egy környezethez vagy egy szolgáltatáskapcsolathoz, az erőforrást használó összes többfázisú folyamat automatikusan megvárja a jóváhagyást a szakasz elején. A kijelölt jóváhagyóknak be kell fejezniük a jóváhagyást, mielőtt a folyamat folytatódhat.

Ezzel a frissítéssel a jóváhagyók e-mailben értesítést kapnak a függőben lévő jóváhagyásról. A felhasználók és a csoporttulajdonosok lemondhatják vagy konfigurálhatják az egyéni előfizetéseket értesítési beállításokhasználatával.

Üzembehelyezési stratégiák konfigurálása az Azure Portalról

Ezzel a funkcióval egyszerűbbé tettük a választott üzembehelyezési stratégiát használó folyamatok konfigurálását, például gördülő, Kanári-vagy Kék-zöld. Ezeket a beépített stratégiákat használva biztonságosan hozhatja létre a frissítéseket, és mérsékelheti a kapcsolódó üzembe helyezési kockázatokat. Ehhez kattintson egy Azure-beli virtuális gép "Folyamatos kézbesítés" beállítására. A konfigurációs panelen a rendszer arra kéri, hogy válassza ki a folyamatot létrehozó Azure DevOps-projekt részleteit, az üzembe helyezési csoportot, az üzembe helyezendő csomagot közzétevő buildelési folyamatot és a választott üzembehelyezési stratégiát. A folytatásban konfigurál egy teljesen működőképes folyamatot, amely üzembe helyezi a kijelölt csomagot ezen a virtuális gépen.

További részletekért tekintse meg az üzembehelyezési stratégiák konfigurálásával kapcsolatos dokumentációnkat.

Futtatókörnyezeti paraméterek

A futtatókörnyezeti paraméterekkel jobban szabályozhatja, hogy milyen értékeket lehet átadni egy folyamatnak. A változókkal ellentétben a futtatókörnyezeti paraméterek adattípusokkal rendelkeznek, és nem lesznek automatikusan környezeti változók. Futtatási paraméterekkel ezt teheti:

• Különböző értékek biztosítása szkriptekhez és feladatokhoz futásidőben
• Paramétertípusok, engedélyezett tartományok és alapértelmezett értékek szabályozása
• Feladatok és szakaszok dinamikus kiválasztása sablonkifejezéssel

A futtatókörnyezeti paraméterekkel kapcsolatos további információkért tekintse meg a dokumentációt, itt.

Használja az "extends" kulcsszót a folyamatokban

Jelenleg a csővezetékrendszerek sablonokba szervezhetők, elősegítve az újrafelhasználást és a sablonos kód csökkentését. A folyamat általános szerkezetét továbbra is a legfelső szintű YAML-fájl definiálta. Ezzel a frissítéssel strukturáltabb módszert adtunk hozzá a folyamatsablonok használatához. A gyökér YAML-fájl mostantól használhatja a extends kulcsszót annak jelzésére, hogy a fő folyamatstruktúra egy másik fájlban található. Ezzel szabályozhatja, hogy mely szegmensek bővíthetők vagy módosíthatók, és mely szegmensek vannak javítva. A folyamatparamétereket adattípusokkal is kibővítettük, hogy egyértelművé tegyük a megadható kapcsokat.

Ez a példa bemutatja, hogyan adhat egyszerű kapcsolódási pontokat a folyamat szerzőjének. A sablon mindig futtat egy buildet, opcionálisan futtatja a folyamat által biztosított további lépéseket, majd futtat egy opcionális tesztelési lépést.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

A sorba állítás idején felülbírálható változók vezérlése

Korábban a felhasználói felületen vagy a REST API-val frissítheti a változók értékeit az új futtatás megkezdése előtt. Bár a folyamat szerzője megjelölhet bizonyos változókat _settable at queue time_, a rendszer nem kényszerítette ezt, és más változók beállítását sem akadályozta meg. Más szóval a beállítás csak további bemenetek megadására szolgál egy új futtatás indításakor.

Hozzáadtunk egy új gyűjteménybeállítást, amely kikényszeríti a _settable at queue time_ paramétert. Ezzel szabályozhatja, hogy mely változók módosíthatók új futtatás indításakor. A továbbiakban nem módosíthatja azt a változót, amelyet a szerző nem jelölt meg _settable at queue time_.

Jegyzet

Ez a beállítás alapértelmezés szerint ki van kapcsolva a meglévő gyűjteményekben, de új Azure DevOps-gyűjtemény létrehozásakor alapértelmezés szerint be lesz kapcsolva.

Új előre definiált változók a YAML-folyamatban

A változók segítségével kényelmesen beviheti a fontos adatokat az adatfolyam különböző részeibe. Ezzel a frissítéssel hozzáadtunk néhány előre definiált változót egy üzembehelyezési feladathoz. Ezeket a változókat a rendszer automatikusan beállítja, az adott üzembehelyezési feladathoz van rendelve, és írásvédettek.

• Environment.Id – A környezet azonosítója.
• Environment.Name – Az üzembe helyezési feladat által megcélzott környezet neve.
• Environment.ResourceId – Az üzembe helyezési feladat által megcélzott környezetben lévő erőforrás azonosítója.
• Environment.ResourceName – Az üzembe helyezési feladat által megcélzott környezet erőforrásának neve.

Több adattár letöltése

Pipeline folyamatok gyakran több tárolóra támaszkodnak. A kód létrehozásához különböző adattárakat használhat forrásokkal, eszközökkel, szkriptekkel vagy egyéb elemekkel. Korábban ezeket az adattárakat almodulként vagy manuális szkriptként kellett hozzáadnia git-kivételfuttatásához. Most már lekérhet és megnézhet más tárházakat is, nem csak azt, amelyiket a YAML-folyamat tárolására használja.

Ha például egy MyCode nevű adattárral rendelkezik egy YAML-folyamattal és egy második, Toolsnevű adattárral, a YAML-folyamat a következőképpen fog kinézni:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

A harmadik lépésben két könyvtár jelenik meg, a MyCode és a Tools a forráskönyvtárban.

Az Azure Repos Git-adattárak támogatottak. További információ: több-adattárbeli kiválasztás.

Részletek lekérése futásidőben több adattárról

Amikor egy csővezeték fut, az Azure Pipelines információkat ad a futtatást kiváltó adattárról, ágról és commitről. Most, hogy a YAML-folyamatok támogatják több adattár kikönyvelését, érdemes lehet tudnia, hogy mely adattárakat, ágakat és elkötelezéseket könyvelt ki a rendszer a további adattárak esetében. Ezek az adatok egy futtatókörnyezeti kifejezésen keresztül érhetők el, amely most már megfeleltethető egy változónak. Például:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Tárházhivatkozások engedélyezése más Azure-tárház-gyűjteményekhez

Korábban, amikor egy YAML-folyamatban lévő adattárakra hivatkozott, az összes Azure-adattárnak ugyanabban a gyűjteményben kellett lennie, mint a folyamatnak. Most más gyűjtemények tárházaira mutathat szolgáltatáskapcsolat használatával. Például:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection egy másik Azure DevOps-gyűjteményre mutat, és olyan hitelesítő adatokkal rendelkezik, amelyek hozzáférhetnek egy másik projekt adattárához. Mindkét adattár, self és otherrepo, ki lesznek ellenőrizve.

Fontos

MyServiceConnection Azure Repos/Team Foundation Server szolgáltatáskapcsolatnak kell lennie, lásd az alábbi képet.

Folyamaterőforrás metaadatai előre definiált változókként

Előre definiált változókat adtunk a YAML-folyamatok erőforrásaihoz a folyamatban. Íme az elérhető folyamaterőforrás-változók listája.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

A kustomize és a kompose használata "bake" opcióként a KubernetesManifest feladatban

kustomize (a Kubernetes sig-cli része) lehetővé teszi a nyers, sablonmentes YAML-fájlok testreszabását több célra, és érintetlenül hagyja az eredeti YAML-t. A KubernetesManifest-feladat kustomize művelete alatt hozzáadtunk egy lehetőséget, hogy a kustomization.yaml fájlokat tartalmazó összes mappa a KubernetesManifest-feladat üzembe helyezési műveletében használt jegyzékfájlokat hozza létre.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose átalakítja a Docker Compose-fájlokat Kubernetes-erőforrássá.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Fürt adminisztrátori hitelesítő adatok támogatása a HelmDeploy feladatban

Korábban a HelmDeploy feladat a fürt felhasználói hitelesítő adatait használta a telepítésekhez. Ez interaktív bejelentkezési kéréseket és meghiúsult munkafolyamatokat eredményezett egy Azure Active Directory-alapú RBAC-kompatibilis fürt esetében. A probléma megoldásához hozzáadtunk egy jelölőnégyzetet, amely lehetővé teszi a fürt rendszergazdai hitelesítő adatainak használatát a fürt felhasználói hitelesítő adatai helyett.

Argumentumok megadása a Docker Compose feladatban

Új mező lett bevezetve a Docker Compose feladatban, amely lehetővé teszi olyan argumentumok hozzáadását, mint például a --no-cache. Az argumentumot a feladat átadja a parancsok, például a build futtatásakor.

A GitHub kiadási feladatának fejlesztései

Számos fejlesztést végeztünk a GitHub kiadási feladatán. Mostantól jobban szabályozhatja a kiadás létrehozását a címkeminta mező használatával, ha megad egy normál címkekifejezést, és a kiadás csak akkor jön létre, ha az eseményindító véglegesítés egyező sztringgel van megjelölve.

Emellett olyan képességeket is hozzáadtunk, amelyekkel testre szabható a változásnapló létrehozása és formázása. A változásnaplók konfigurálásának új szakaszában most megadhatja azt a kiadást, amelyhez az aktuális kiadást össze kell hasonlítani. A és kiadás összehasonlítása lehet az utolsó teljes kiadás (ami nem tartalmazza az előzetes kiadásokat), az utolsó nem piszkozat kiadás lehet, vagy bármely korábbi kiadás, amely megfelel a megadott kiadási címkének. Emellett a tevékenység a változásnapló típusmezőt is biztosítja a változásnapló formázásához. A kijelölés alapján a változásnapló megjeleníti a véglegesítések listáját, vagy a címkék alapján kategorizált problémák/PRS-ek listáját.

Open Policy Agent telepítési feladat megnyitása

Az Open Policy Agent egy nyílt forráskódú, általános célú szabályzatmotor, amely egységes, környezettudatos szabályzatkényszerítést tesz lehetővé. Hozzáadtuk az Open Policy Agent telepítőfeladatot. Különösen hasznos a folyamaton belüli szabályzatkényszerítéshez az infrastruktúra, mint kódszolgáltatók tekintetében.

Az Open Policy Agent például kiértékelheti a Rego szabályzatfájlokat és Terraform-terveket a csővezetékben.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

PowerShell-szkriptek támogatása az Azure CLI-feladatban

Korábban kötegelt és bash-szkripteket is végrehajthat egy Azure CLI-feladat részeként. Ezzel a frissítéssel hozzáadtuk a PowerShell- és PowerShell-alapszkriptek támogatását a feladathoz.

Service Mesh Interface alapú kanári telepítések a Kubernetes Manifest feladatban

Korábban, amikor a KubernetesManifest tevékenységben meghatározták a kanári-stratégiát, a tevékenység alapkonfigurációt és kanári számítási feladatokat hoz létre, amelyek replikái megegyeznek a stabil számítási feladatokhoz használt replikák százalékával. Ez nem volt pontosan ugyanaz, mint a forgalom felosztása a kívánt százalékra a kérelem szintjén. Ennek megoldásához a KubernetesManifest feladathoz hozzáadtuk Service Mesh Interface-alapú kanári-telepítések támogatását.

A Service Mesh interface absztrakciója lehetővé teszi a plug-and-play konfigurációt olyan szolgáltatásháló-szolgáltatókkal, mint a Linkerd és az Istio. A KubernetesManifest-feladat most elveszi az SMI TrafficSplit objektumainak az alap, stabil és kanári szolgáltatásokhoz való leképezésének nehezebb részét a telepítési stratégia életciklusa során. A stabil, az alapbeállítás és a kanári közötti forgalmi megoszlás pontosabb, mivel a forgalom százalékos felosztását a szolgáltatásháló síkon lévő kérések vezérlik.

Az alábbiakban az SMI-alapú kanári-telepítéseket gördülő módon hajtjuk végre.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Az Azure File Copy Task mostantól támogatja az AzCopy V10-et

Az Azure-fájlmásolási feladat egy buildelési vagy kiadási folyamatban használható fájlok Microsoft Storage-blobokra vagy virtuális gépekre való másolásához. A feladat az AzCopy, a parancssori segédprogramot használja az adatok gyors másolására az Azure Storage-fiókokból és -fiókokba. Ezzel a frissítéssel hozzáadtuk az AzCopy V10 támogatását, amely az AzCopy legújabb verziója.

A azcopy copy parancs csak a hozzá tartozó argumentumokat támogatja. Az AzCopy szintaxisának változása miatt néhány meglévő képesség nem érhető el az AzCopy V10-ben. Ezek a következők:

• Naplóhely megadása
• Napló- és tervfájlok tisztítása a másolás után
• Másolás folytatása, ha a feladat meghiúsul

A feladat ezen verziójában támogatott további képességek a következők:

• Helyettesítő karakterek a forrás fájlnevében/elérési útján
• A tartalomtípus következtetése fájlkiterjesztés alapján, ha nincsenek megadva argumentumok
• A naplófájl részletességének meghatározása argumentum átadásával

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

Az Azure Pipelinesban futó összes 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, feltöltjük a naplókat, teszteljük az eredményeket, az összetevőket, 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 következő fejlesztéseket adtuk hozzá.

• Megakadályozza, hogy a jogkivonat hozzáférjen a csoportprojekten kívüli erőforrásokhoz

  Eddig az összes folyamat alapértelmezett hatóköre a csapatprojekt-gyűjtemény volt. A hatókört módosíthatja úgy, hogy az a csapatprojekt legyen a klasszikus buildelési folyamatokban. A klasszikus kiadások vagy a YAML-folyamatok esetében azonban nem rendelkeztél ezzel a vezérlővel. Ezzel a frissítéssel bevezetünk egy beállítást, amely biztosítja, hogy minden feladat projekt-alapú tokent kapjon, függetlenül attól, hogy mi van konfigurálva a folyamatban. A beállítást a projekt szintjén is hozzáadtuk. Most minden újonnan létrehozott projekt és gyűjtemény automatikusan bekapcsolja ezt a beállítást.

  Jegyzet

  A gyűjteménybeállítás felülírja a projektbeállítást.

  Ha ezt a beállítást bekapcsolja a meglévő projektekben és gyűjteményekben, bizonyos folyamatok meghiúsulhatnak, ha a folyamatok hozzáférési jogkivonatokkal férnek hozzá a csoportprojekten kívüli erőforrásokhoz. A folyamathibák csökkentése érdekében explicit módon engedélyezheti Project Build szolgáltatásfiókjának hozzáférést a kívánt erőforráshoz. Javasoljuk, hogy kapcsolja be ezeket a biztonsági beállításokat.

• Korlátozza a Build Service adattárak hatókör-hozzáférését

  A folyamatbiztonság javítására a hozzáférési jogkivonat hatókörének korlátozásával építve az Azure Pipelines mostantól csak a YAML-alapú folyamatszükséges adattárakra korlátozhatja az adattárhoz való hozzáférést. Ez azt jelenti, hogy ha a pipeline-ek hozzáférési tokenje kiszivárogna, akkor csak az pipeline-ben használt adattár(ak) láthatnák. Korábban a hozzáférési jogkivonat jó volt a projekt bármely Azure-adattárához, vagy akár a teljes gyűjteményhez 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 Gyűjtemények beállításai>Folyamatok>Beállítások. A funkció használatakor a buildhez szükséges összes adattárat (még a szkripttel klónozottakat is) tartalmaznia kell a folyamat adattár-erőforrásokban.

• A hozzáférési jogkivonat bizonyos engedélyeinek eltávolítása

  Alapértelmezés szerint több engedélyt adunk a hozzáférési jogkivonathoz, az egyik ilyen engedély a Queue buildek. Ezzel a frissítéssel eltávolítottuk ezt az engedélyt a hozzáférési jogkivonatra. Ha a folyamatoknak szüksége van erre az engedélyre, a használt jogkivonattól függően explicit módon engedélyezheti a Project Build szolgáltatásfiókjának vagy projektgyűjtemény-összeállítási szolgáltatásfiókjának.

A szolgáltatáskapcsolatok projektszintű biztonsága

Központi szintű biztonságot adtunk hozzá a szolgáltatáskapcsolatokhoz. Mostantól hozzáadhat/eltávolíthat felhasználókat, szerepköröket rendelhet hozzá és kezelheti a hozzáférést egy központosított helyen az összes szolgáltatáskapcsolathoz.

Lépéscélzás és parancs izolálás

Az Azure Pipelines támogatja a feladatok tárolókban vagy az ügynök gazdagépen való futtatását. Korábban egy teljes feladat a két cél egyikére volt beállítva. Mostantól az egyes lépések (feladatok vagy szkriptek) futtathatók a választott célon. A lépések más tárolókat is megcélozhatnak, így egy folyamat minden lépést egy speciális, célra létrehozott tárolóban futtathat.

A tárolók elkülönítési határként működhetnek, így megakadályozhatják, hogy a kód váratlan módosításokat hajt végre a gazdagépen. Az, hogy a lépések hogyan kommunikálnak az ügynökkel és hogyan férnek hozzá a szolgáltatásokhoz, nem befolyásolja, ha a lépések tárolóban vannak elválasztva. Ezért bevezetünk egy parancskorlátozási módot is, amelyet lépéscélokkal használhat. Ha bekapcsolja ezt a beállítást, az korlátozza azokat a szolgáltatásokat, amelyek egy lépésben kérhetők az ügynöktől. A továbbiakban nem fog tudni naplókat csatolni, összetevőket feltölteni és bizonyos egyéb műveleteket.

Íme egy átfogó példa, amely egy feladattároló gazdagépén és egy másik tárolóban futtatási lépéseket mutat be:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Írásvédett változók

A rendszerváltozók nem módosíthatóként lettek dokumentálva, de a gyakorlatban egy tevékenység felülírhatja őket, és az alsóbb rétegbeli tevékenységek felveszik az új értéket. Ezzel a frissítéssel szigorítjuk a pipeline változók biztonságát, hogy a rendszerváltozók és a sorbanállási idő alatt változók írásvédettek legyenek. Emellett a YAML-változókat írásvédetté is teheti az alábbiak szerint megjelölve.

variables:
- name: myVar
  value: myValue
  readonly: true

Szerepköralapú hozzáférés szolgáltatáskapcsolatokhoz

Szerepköralapú hozzáférést adtunk hozzá a szolgáltatáskapcsolatokhoz. Korábban a szolgáltatáskapcsolatok biztonsága csak előre definiált Azure DevOps-csoportokon, például végpont-rendszergazdákon és végpontkészítőkön keresztül kezelhető.

Ennek a munkának a részeként bevezettük az olvasó, a felhasználó, a létrehozó és a rendszergazda új szerepkörét. Ezeket a szerepköröket a projekt szolgáltatáskapcsolatok lapján állíthatja be, és ezeket az egyes kapcsolatok öröklik. Minden szolgáltatáskapcsolatban be- vagy kikapcsolhatja az öröklést, és felülbírálhatja a szolgáltatáskapcsolat hatókörében lévő szerepköröket.

Tudjon meg többet a szolgáltatáskapcsolatok biztonságáról itt .

Szolgáltatáskapcsolatok projektközi megosztása

Engedélyeztük a szolgáltatáskapcsolatok projektek közötti megosztásának támogatását. Mostantól biztonságosan és biztonságosan megoszthatja a szolgáltatáskapcsolatokat a projektjeivel.

További információ a szolgáltatáskapcsolatok megosztásáról itt.

Csővezetékek és ACR-erőforrások nyomon követhetősége

Teljes végponttól végpontig nyomon követhetőséget biztosítunk, amikor csővezetékeket és ACR-tárolóerőforrásokat használnak egy csővezetékben. A YAML-folyamat által felhasznált összes erőforrás esetében visszakövetheti a véglegesítéseket, a munkaelemeket és az összetevőket.

A folyamatfuttatás összefoglaló nézetében a következő látható:

• A erőforrásverzió, amely elindította afuttatást. A folyamat most aktiválható egy másik Azure-folyamatfuttatás befejezésekor, vagy egy tárolórendszerkép ACR-be való leküldésekor.

  

• A véglegesíti a folyamat által felhasznált. A köteleződések lebontását a folyamatsor által felhasznált erőforrások szerint is megtalálhatja.

  

• A munkaelemek, amelyek a folyamat által felhasznált egyes erőforrásokhoz vannak társítva.

• A artefaktumok, amelyek a futtatáshoz rendelkezésre állnak.

  

A környezet üzembe helyezési nézetében láthatja a környezetbe telepített egyes erőforrások véglegesítéseit és munkaelemeit.

Nagyméretű tesztmellékletek támogatása

Az Azure Pipelines teszteredmény-közzétételi feladata lehetővé teszi a teszteredmények közzétételét a tesztek végrehajtásakor, hogy átfogó tesztjelentési és elemzési élményt nyújtson. Eddig 100 MB-os korlát volt a tesztmellékletekhez mind a tesztfuttatáshoz, mind a tesztelési eredményekhez. Ez korlátozta a nagy fájlok, például összeomlási jelentések vagy videók feltöltését. Ezzel a frissítéssel támogattuk a nagy méretű tesztmellékleteket, így minden rendelkezésre álló adat rendelkezésre áll a sikertelen tesztek hibaelhárításához.

A VSTest-feladat vagy a Teszteredmények közzététele feladat 403-at vagy 407-et eredményez a naplókban. Ha önkiszolgáló buildeket vagy kiadási ügynököket használ egy tűzfal mögött, amely kiszűri a kimenő kéréseket, néhány konfigurációs módosítást kell végrehajtania a funkció használatához. ​

A probléma megoldásához javasoljuk, hogy frissítse a tűzfalat a kimenő kérésekhezhttps://*.vstmrblob.vsassets.io-re. A hibaelhárítási információkat a dokumentációban találja, itt. ​

Jegyzet

Erre csak akkor van szükség, ha ön üzemeltetett Azure Pipelines-ügynököket használ, és olyan tűzfal mögött van, amely a kimenő forgalmat szűri. Ha Microsoft által üzemeltetett ügynököket használ a felhőben, vagy nem szűri a kimenő hálózati forgalmat, nem kell semmilyen műveletet végrehajtania.

A megfelelő pool információ megjelenítése minden egyes munkánál

Korábban, amikor egy mátrixot használt a feladatok kibontásához vagy egy változót egy készlet azonosításához, néha megoldottuk a helytelen készletadatokat a naplók oldalán. Ezeket a problémákat megoldottuk.

CI-eseményindítók új ágakhoz

Hosszú ideig függőben lévő kérés volt, hogy ne aktiválja a CI-buildeket egy új ág létrehozásakor, és amikor nincs változtatás az ágon. Vegye figyelembe a következő példákat:

• A webes felületen létrehozhat egy új ágat egy meglévő ág alapján. Ez azonnal elindít egy új CI-buildet, ha az ágszűrő megegyezik az új ág nevével. Ez nem kívánt, mert az új ág tartalma megegyezik a meglévő ág tartalmával.
• Van egy adattára két mappával – alkalmazással és dokumentumokkal. Beállít egy útvonalszűrőt a CI-hez, hogy megfeleljen az "alkalmazásnak". Más szóval nem szeretne új buildet létrehozni, ha egy módosítást leküldtek a dokumentumokba. Helyileg létrehoz egy új ágat, módosítja a dokumentumokat, majd leküldi az ágat a kiszolgálóra. Korábban egy új CI-buildet aktiváltunk. Ez nem kívánatos, mivel kifejezetten kérte, hogy ne keressen módosításokat a dokumentumok mappájában. Az új ágesemények kezelésének módja miatt azonban úgy tűnik, mintha az alkalmazásmappán is módosítás történt volna.

Most már van egy jobb módja az új ágak folyamatos integrációjának kezelésére, hogy megoldjuk ezeket a problémákat. Új ág közzétételekor kifejezetten az új commit-eket keressük az adott ágban, és ellenőrizzük, hogy megfelelnek-e az elérésiút-szűrőknek.

A feladatok hozzáférhetnek az előző szakaszok kimeneti változóihoz

A kimeneti változók mostantól a YAML-alapú folyamatok szakaszaiban használhatók. Ez segít átadni a hasznos információkat, például a go/no-go döntését vagy a generált kimenet azonosítóját az egyik fázisból a másikba. Az előző fázis és a feladatok eredménye (állapota) is elérhető.

A kimeneti változókat továbbra is a feladatokon belüli lépések állítják elő. A dependencies.jobName.outputs['stepName.variableName']helyett a szakaszok a stageDependencies.stageName.jobName.outputs['stepName.variableName']-re utalnak.

Jegyzet

Alapértelmezés szerint a folyamat minden szakasza az előzőtől függ a YAML-fájlban. Ezért minden fázis használhatja az előző fázis kimeneti változóit. Módosíthatja a függőségi gráfot, amely azt is módosítja, hogy mely kimeneti változók érhetők el. Ha például a 3. fázisnak szüksége van egy változóra az 1. fázisból, explicit függőséget kell deklarálnia az 1. fázisban.

Az automatikus ügynökök frissítésének letiltása készletszinten

A pipeline-ügynökök jelenleg szükség esetén automatikusan legújabb verzióra frissülnek. Ez általában akkor fordul elő, ha egy új funkció vagy feladat megköveteli, hogy egy újabb ügynökverzió megfelelően működjön. Ezzel a frissítéssel lehetővé tesszük az automatikus frissítések letiltását készletszinten. Ebben a módban, ha a megfelelő verzió egyik ügynöke sem csatlakozik a készlethez, a folyamatok ahelyett, hogy ügynökök frissítését kérik, egy egyértelmű hibaüzenettel hiúsulnak meg. Ez a funkció leginkább a saját üzemeltetésű készletekkel és nagyon szigorú változásvezérlési követelményekkel rendelkező ügyfelek számára érdekes. Az automatikus frissítések alapértelmezés szerint engedélyezve vannak, és nem javasoljuk, hogy a legtöbb ügyfél letiltsa őket.

Ügynökdiagnosztika

Diagnosztikát adtunk hozzá az ügynökkel kapcsolatos gyakori problémákhoz, például számos hálózati problémához és a frissítési hibák gyakori okaihoz. A diagnosztikával való ismerkedéshez használja a run.sh --diagnostics vagy Windows esetén a run.cmd --diagnostics.

Szolgáltatás-horgok YAML-folyamatokhoz

A szolgáltatások YAML-folyamatokkal való integrálása egyszerűbbé lett. A YAML-folyamatok szolgáltatáshook-eseményeinek használatával mostantól egyéni alkalmazásokban vagy szolgáltatásokban is hajthat tevékenységeket a folyamatfuttatások előrehaladása alapján. Létrehozhat például egy segélyszolgálati jegyet, ha jóváhagyásra van szükség, elindíthat egy monitorozási munkafolyamatot egy szakasz befejezése után, vagy leküldéses értesítést küldhet a csapat mobileszközére, ha egy szakasz meghiúsul.

A folyamatnév és a szakasznév szűrése minden esemény esetében támogatott. A jóváhagyási események adott környezetekre is szűrhetők. Hasonlóképpen, az állapotváltozási események szűrhetők a folyamatfuttatás vagy a fázis új állapota alapján.

Optimalizált integráció

Az Optimizely egy hatékony A/B tesztelési és funkciózászló platform a termékcsapatok számára. Az Azure Pipelines integrálása az Optimalizált kísérletezési platformmal lehetővé teszi a termékcsapatoknak, hogy gyorsított ütemben teszteljék, tanulják meg és helyezjék üzembe, miközben az Azure Pipelines minden DevOps-előnyét élvezhetik.

Az Azure DevOps optimalizált bővítménye kísérletezési és funkciójelző bevezetési lépéseket ad a buildelési és kiadási folyamatokhoz, így folyamatosan iterálhat, gördíthet ki funkciókat, és visszaállíthatja őket az Azure Pipelines használatával.

További információ az Azure DevOps Optimizely bővítményről, itt.

GitHub-kiadás hozzáadása összetevőforrásként

Most összekapcsolhatja a GitHub-kiadásokat összetevőforrásként az Azure DevOps kiadási folyamataiban. Lehetővé teszi, hogy a GitHub-kiadást a telepítések részeként használja.

Amikor a kiadási folyamat definíciójában Összetevő hozzáadása elemre kattint, megtalálja az új GitHub Release forrástípust. A GitHub-kiadás használatához megadhatja a szolgáltatáskapcsolatot és a GitHub-adattárat. Kiválaszthatja a GitHub-kiadás alapértelmezett verzióját is, amely a legújabb, adott címkeverzióként használható, vagy kiválaszthatja a kiadás létrehozásakor. A GitHub-kiadás csatolása után a rendszer automatikusan letölti és elérhetővé teszi a kiadási feladatokban.

Terraform-integráció az Azure Pipelinessal

A Terraform egy nyílt forráskódú eszköz az infrastruktúra biztonságos és hatékony fejlesztéséhez, módosításához és verziószámozásához. A Terraform deklaratív konfigurációs fájlokká kodifikálja az API-kat, így magas szintű konfigurációs nyelv használatával definiálhat és építhet ki infrastruktúrát. A Terraform bővítmény használatával erőforrásokat hozhat létre az összes főbb infrastruktúra-szolgáltatóban: az Azure-ban, az Amazon Web Servicesben (AWS) és a Google Cloud Platformban (GCP).

A Terraform bővítménnyel kapcsolatos további információkért lásd a dokumentációt itt.

Integráció a Google Analytics szolgáltatással

A Google Analytics kísérletek keretrendszerével szinte bármilyen módosítást vagy módosítást tesztelhet egy webhely vagy alkalmazás esetében annak egy adott célkitűzésre gyakorolt hatásának méréséhez. Lehetnek például olyan tevékenységei, amelyeket el szeretne végezni a felhasználók számára (pl. vásárlás, hírlevélre való feliratkozás) és/vagy a javítani kívánt metrikák (például bevétel, munkamenet időtartama, visszapattanási arány). Ezek a tevékenységek lehetővé teszik, hogy a szolgáltatás teljesítményére gyakorolt közvetlen hatásuk alapján azonosítsa a implementálni kívánt módosításokat.

Az Azure DevOps Google Analytics-kísérletek bővítménye kísérletezési lépésekkel bővíti a buildelési és kiadási folyamatokat, így folyamatosan iterálhat, tanulhat és helyezhet üzembe gyorsított ütemben a kísérletek folyamatos kezelésével, miközben az Azure Pipelines minden DevOps-előnyét kihasználhatja.

A Google Analytics-kísérletek bővítmény a Marketplace-ről tölthető le.

Frissített ServiceNow-integráció az Azure Pipelinessal

A ServiceNow Azure Pipelines-alkalmazás segít integrálni az Azure Pipelinest és a ServiceNow Change Managementet. Ezzel a frissítéssel integrálható a ServiceNow New York-i verziójával. A két szolgáltatás közötti hitelesítés mostantól az OAuth és az alapszintű hitelesítés használatával végezhető el. Emellett most már haladó sikerességi feltételeket is konfigurálhat, hogy bármely változási tulajdonság segítségével eldönthesse a kapu eredményét.

Azure Pipelines létrehozása a VSCode-ból

Új funkciót adtunk hozzá a VSCode-hoz készült Azure Pipelines-bővítményhez. Most közvetlenül a VSCode-ból hozhat létre Azure Pipelinesokat anélkül, hogy elhagyná az IDE-t.

Pelyhes hibakezelés és -megoldás

Bevezettük a pelyhes tesztkezelést, amely a teljes életciklust támogatja észleléssel, jelentéskészítéssel és megoldással. Továbbfejlesztés érdekében a megbízhatatlan tesztek hibakezelését és megoldását adjuk hozzá.

A pelyhes teszt vizsgálata során létrehozhat egy hibát a Hiba művelet használatával, amelyet aztán hozzárendelhet egy fejlesztőhöz a pelyhes teszt alapvető okának további vizsgálatához. A hibajelentés olyan információkat tartalmaz az adatfolyamról, mint a hibaüzenet, a veremkövetés, valamint egyéb, a teszthez kapcsolódó információk.

Amikor egy hibajelentést feloldanak vagy lezárnak, automatikusan eltávolítjuk a tesztről a megbízhatatlansági jelölést.

A VSTest-tevékenységek sikertelennek beállítása, ha a tesztek minimális száma nem fut

A VSTest-feladat felderíti és futtatja a teszteket felhasználói bemenetekkel (tesztfájlok, szűrési feltételek stb.), valamint egy, a használt tesztelési keretrendszerre jellemző tesztadapterrel. A felhasználói bemenetek vagy a tesztadapter módosításai olyan esetekhez vezethetnek, amikor a rendszer nem észleli a teszteket, és csak a várt tesztek egy részhalmaza fut. Ez olyan helyzetekhez vezethet, amikor a folyamatok sikeresek, mert a tesztek kihagyva vannak, és nem azért, mert a kód megfelelő minőségű. A helyzet elkerülése érdekében hozzáadtunk egy új lehetőséget a VSTest-tevékenységhez, amely lehetővé teszi a feladat elvégzéséhez futtatandó tesztek minimális számának megadását.

A VSTest TestResultsDirectory lehetőség elérhető a feladat felhasználói felületén

A VSTest-feladat a teszteredményeket és a kapcsolódó fájlokat a $(Agent.TempDirectory)\TestResults mappában tárolja. Hozzáadtunk egy lehetőséget a feladat felhasználói felületéhez, amely lehetővé teszi egy másik mappa konfigurálását a teszteredmények tárolásához. Most minden további feladat, amely egy adott helyen lévő fájlokat igényel, használhatja őket.

Markdown-támogatás automatizált tesztelési hibaüzenetekben

Az automatikus tesztekhez markdown-támogatást adtunk a hibaüzenetekhez. Mostantól egyszerűen formázhatja a hibaüzeneteket a tesztfuttatáshoz és a tesztelés eredményéhez is, hogy javítsa az olvashatóságot, és megkönnyítse a tesztelési hibák hibaelhárítási folyamatát az Azure Pipelinesban. A támogatott Markdown-szintaxis itt található.

Csővezeték dekorátorok használatával automatikusan injektálhat lépéseket egy telepítési feladatba.

Most már hozzáadhat csővezeték dekorátorokat a telepítési feladatokhoz. Bármilyen egyéni lépést (például biztonságirés-ellenőrzőt) automatikusan beszúrhat minden életciklus-kampóba, minden üzembe helyezési feladat végrehajtása. Mivel a folyamat-dekorátorok egy gyűjtemény összes folyamatára alkalmazhatók, ez a biztonságos üzembehelyezési eljárások végrehajtásának részeként használható.

Emellett az üzembehelyezési feladatok tárolófeladatként is futtathatók, valamint kiegészítő szolgáltatásokként, ha meg vannak adva.

Tesztcsomagok

Új tesztterv lap

Az összes Azure DevOps-gyűjteményhez elérhető egy új tesztcsomag-lap (tesztcsomagok *). Az új oldal egyszerűsített nézeteket biztosít, amelyekkel a feladatra összpontosíthat – teszttervezésre, létrehozásra vagy végrehajtásra. Emellett az Azure DevOps többi ajánlatával is zökkenőmentes és összhangban van.

Segítség az új lap megértéséhez

Az új Teszttervek lap összesen 6 szakaszt tartalmaz, amelyek közül az első 4 új, míg a Diagramok & Bővíthetőségi szakaszok a meglévő funkciók.

1. Tesztterv fejlécének: Ezzel kereshet, kedvencek közé tehet, szerkeszthet, másolhat vagy klónozhat egy teszttervet.
2. Tesztcsomagok fa: Ezzel a funkcióval adhat hozzá, kezelhet, exportálhat vagy rendelhet tesztcsomagokat. Ezzel konfigurációkat is hozzárendelhet, és felhasználói elfogadási teszteket hajthat végre.
3. Tabulátordefiniálása: Ezen a lapon keresztül rendezheti, veheti fel és kezelheti a teszteseteket egy tetszőleges tesztcsomagban.
4. Végrehajtás lap: Tesztek hozzárendelése és végrehajtása ezen a lapon, vagy egy teszteredmény megkeresése a részletezéshez.
5. Diagram lap: A teszt végrehajtásának és állapotának nyomon követése az irányítópultokra rögzíthető diagramokon keresztül.
6. Bővíthetőségi: Támogatja a terméken belüli jelenlegi bővíthetőségi pontokat.

Az alábbi új szakaszok széles vonásos nézetét tekintheti meg.

1. Tervfejléc tesztelése

Feladatok

A Tesztterv fejléce a következő feladatokat teszi lehetővé:

• Tesztterv megjelölése kedvencként
• Kedvenc tesztterv jelölésének megszüntetése
• Egyszerűen navigálhat kedvenc tesztcsomagjai között
• Tekintse meg a tesztterv iterációs útvonalát, amely egyértelműen jelzi, hogy a tesztterv aktuális vagy múltbeli-e
• A Tesztállapot jelentés gyors összefoglalásának megtekintése egy hivatkozással a jelentésre való navigáláshoz
• Lépjen vissza az Összes/Saját tesztcsomagok oldalra

Helyi menü beállításai

A Tesztterv fejléc helyi menüje a következő lehetőségeket kínálja:

• Tesztterv másolása: Ez egy új lehetőség, amely lehetővé teszi az aktuális tesztterv gyors másolását. További részletek alább.
• Tesztterv szerkesztése: Ezzel a beállítással szerkesztheti a Tesztterv munkaelem űrlapot a munkaelemmezők kezeléséhez.
• Tesztterv beállításai: Ezzel a beállítással konfigurálhatja a tesztfuttatás beállításait (a buildelési vagy kiadási folyamatok társításához) és a Teszteredmény-beállításokat

Tesztterv másolása (új képesség)

Javasoljuk, hogy sprintenként/kiadásonként hozzon létre egy új tesztcsomagot. Ebben az esetben általában az előző ciklus teszttervét lehet átmásolni, és kevés módosítással a másolt tesztterv készen áll az új ciklusra. A folyamat megkönnyítése érdekében engedélyeztük a "Tesztcsomag másolása" funkciót az új oldalon. A használatával tesztterveket másolhat vagy klónozhat. A REST API funkcionalitása itt található, és az API lehetővé teszi a teszttervek másolását vagy klónozását a projektek között is.
A tesztcsomagok használatára vonatkozó további útmutatásért tekintse meg itt.

2. Tesztcsomagok fa

Feladatok

A Tesztcsomag fejléce a következő feladatokat teszi lehetővé:

• kibontása/összecsukása: Ezzel az eszköztár-beállítással kibonthatja vagy összecsukhatja a csomag hierarchiafáját.
• Tesztpontok megjelenítése gyermekcsomagokból: Ez az eszköztár-beállítás csak akkor látható, ha a "Végrehajtás" lapon van. Így egyetlen nézetben tekintheti meg az adott csomag és gyermekei összes tesztpontját a tesztpontok egyszerűbb kezelése érdekében anélkül, hogy egyenként kellene külön csomagokat keresnie.
• Csomagrendek: A csomagokat húzással vagy áthúzással átrendezheti a csomagok hierarchiáját, vagy áthelyezheti őket az egyik csomaghierarchiából egy másikba a tesztterven belül.

Helyi menü beállításai

A Tesztcsomagok fa helyi menüje a következő lehetőségeket kínálja:

• Új csomagok létrehozása: 3 különböző csomagtípust hozhat létre az alábbiak szerint:
  • Statikus csomag vagy mappacsomag használatával rendszerezheti a teszteket.
  • A követelményalapú csomag használatával közvetlenül hivatkozhat a követelményekre/felhasználói történetekre a zökkenőmentes nyomon követhetőség érdekében.
  • Lekérdezésalapú használatával dinamikusan rendszerezheti a lekérdezési feltételeknek megfelelő teszteseteket.
• Konfigurációk hozzárendelése: Hozzárendelhet konfigurációkat a csomaghoz (például Chrome, Firefox, EdgeChromium), és ezek a csomaghoz később hozzáadott összes meglévő tesztesetre vagy új tesztesetre érvényesek lesznek.
• Exportálás pdf/e-mail formátumban: Exportálja a tesztterv tulajdonságait, a tesztcsomag tulajdonságait, valamint a tesztelési esetek és a tesztpontok részleteit "e-mailben" vagy "pdf-be nyomtatva".
• Tesztcsomag munkaelemének megnyitása: Ezzel a beállítással szerkesztheti a Tesztcsomag munkaelem űrlapot a munkaelemmezők kezeléséhez.
• Tesztelők hozzárendelése az összes teszt futtatásához: Ez a beállítás nagyon hasznos a Felhasználói elfogadás tesztelési (UAT) forgatókönyvekben, ahol ugyanazt a tesztet több tesztelőnek kell futtatnia/végrehajtania, általában különböző részlegekhez tartozva.
• Átnevezés/törlés: Ezekkel a beállításokkal kezelheti a csomag nevét, vagy eltávolíthatja a csomagot és annak tartalmát a tesztcsomagból.

3. Tabulátor meghatározása

A "Definiálás" fül lehetővé teszi a tesztcsomaghoz tartozó tesztesetek összeállítását, hozzáadását és kezelését. Míg a végrehajtási lap a tesztpontok hozzárendelésére és végrehajtására használható.

A Definiálás lap és bizonyos műveletek csak az Basic + Test Plans hozzáférési szinttel vagy azzal egyenértékű felhasználók számára érhetők el. Minden más a "Basic" hozzáférési szinttel rendelkező felhasználók számára is elérhető kell legyen.

Feladatok

A Definiálás lapon a következő feladatokat hajthatja végre:

• Új teszteset hozzáadása munkaelem űrlap használatával: Ezzel a beállítással új tesztesetet hozhat létre a munkaelem űrlap használatával. A létrehozott teszteset automatikusan hozzáadódik a tesztcsomaghoz.
• Új teszteset hozzáadása rácshasználatával: Ezzel a beállítással egy vagy több tesztesetet hozhat létre a tesztesetek rács nézetének használatával. A létrehozott tesztesetek automatikusan bekerülnek a csomagba.
• Meglévő tesztesetek hozzáadása lekérdezésihasználatával: Ezzel a beállítással meglévő teszteseteket adhat hozzá a csomaghoz egy lekérdezés megadásával.
• Teszteseteket húzással vagy elvetéssel rendezhet: A tesztesetek sorrendjét megváltoztathatja egy vagy több teszteset mozgatásával egy adott csomagon belül. A tesztelési esetek sorrendje csak a manuális tesztelési esetekre vonatkozik, az automatizált tesztekre nem.
• Tesztesetek áthelyezése egyik csomagból a másikba: A húzással a teszteseteket áthelyezheti egyik tesztcsomagból a másikba.
• Rács megjelenítése: A rács módot használhatja a tesztesetek és a tesztelési lépések megtekintésére vagy szerkesztésére.
• Teljes képernyős nézet: Ezzel a beállítással teljes képernyős módban tekintheti meg a teljes Definiálás lap tartalmát.
• szűrési: A szűrősáv segítségével szűrheti a tesztesetek listáját a "teszteset címe", "hozzárendelt" és "állapot" mezők alapján. A listát az oszlopfejlécekre kattintva is rendezheti.
• Oszlopbeállítások: A Definiálás lapon látható oszlopok listáját az "Oszlopbeállítások" használatával kezelheti. A kiválasztáshoz elérhető oszlopok listája elsősorban a teszteset munkaelem-űrlapjának mezői.

Helyi menü beállításai

A Define lap Teszteset csomópontjának helyi menüje a következő lehetőségeket kínálja:

• Teszteset munkaelem űrlapjának megnyitása/szerkesztése: Ez a beállítás lehetővé teszi a teszteset szerkesztését a munkaelem űrlap használatával, amelyben szerkesztheti a munkaelemmezőket, beleértve a tesztlépéseket is.
• Tesztesetek szerkesztése: Ezzel a beállítással tömegesen szerkesztheti a Teszteset munkaelem mezőit. Ezzel a beállítással azonban nem szerkesztheti tömegesen a tesztlépéseket.
• A rácsosteszteseteinek szerkesztése: Ezzel a beállítással tömegesen szerkesztheti a kiválasztott teszteseteket, beleértve a rácsnézetet használó tesztlépéseket is.
• Konfigurációk hozzárendelése: Ezzel a beállítással felülbírálhatja a csomagszintű konfigurációkat a tesztesetszintű konfigurációkkal.
• Tesztesetek eltávolítása: Ezzel a beállítással eltávolíthatja a teszteseteket az adott csomagból. Ez azonban nem módosítja az alapul szolgáló teszteset munkaelemét.
• Tesztesetek másolatának/klónjának létrehozása: Ezzel a beállítással létrehozhatja a kiválasztott tesztesetek másolatát/klónját. További részletekért lásd alább.
• Csatolt elemek megtekintése: Ezzel a beállítással megtekintheti egy adott teszteset csatolt elemeit. További részletekért lásd alább.

másolási/klónozási tesztesetek (új képesség)

Azokban az esetekben, amikor tesztesetet szeretne másolni/klónozni, használhatja a "Teszteset másolása" lehetőséget. Megadhatja a célprojektet, a célteszttervet és a céltesztcsomagot, amelyben létre szeretné hozni a másolási/klónozott tesztesetet. Emellett azt is megadhatja, hogy meglévő hivatkozásokat vagy mellékleteket szeretne-e hozzáadni a klónozott példányba való átvitelhez.

Csatolt elemek megtekintése (új képesség)

A tesztösszetevők, a követelmények és a hibák nyomon követhetősége a Teszttervek termék kritikus fontosságú értékajánlata. A "Csatolt elemek megtekintése" beállítással egyszerűen áttekintheti a tesztesethez csatolt összes csatolt követelményt, az összes tesztcsomagot/tesztcsomagot, ahol ezt a tesztesetet használták, valamint az összes olyan hibát, amelyet a teszt végrehajtása során nyújtottak be.

4. Végrehajtás fül

A "Definiálás" fül lehetővé teszi a tesztcsomaghoz tartozó tesztesetek összeállítását, hozzáadását és kezelését. Míg a végrehajtási lap a tesztpontok hozzárendelésére és végrehajtására használható.

Mi az a tesztpont? tesztesetek önmagukban nem végrehajthatók. Amikor tesztesetet ad hozzá egy tesztcsomaghoz, a rendszer létrehozza a tesztpont(ok)t. A tesztpont a teszteset, a tesztcsomag, a konfiguráció és a tesztelő egyedülálló kombinációja. Például: ha van egy teszteset "Bejelentkezési funkciók tesztelése" néven, és 2 konfigurációt ad hozzá Edge és Chrome formátumban, akkor ez 2 tesztpontot eredményez. Most már végrehajthatók ezek a tesztpontok. A végrehajtás során a rendszer létrehozza a teszteredményeket. A teszteredmények nézet (végrehajtási előzmények) segítségével megtekintheti egy tesztpont összes végrehajtását. A tesztpont legújabb végrehajtása a végrehajtás lapon látható.
Ezért a tesztelési esetek újrafelhasználható entitások. A teszttervbe vagy tesztcsomagba való belevételük révén tesztpontok jönnek létre. A tesztpontok végrehajtásával meghatározhatja a fejlesztendő termék vagy szolgáltatás minőségét.

Az új oldal egyik elsődleges előnye, hogy azok a felhasználók, akik főként tesztvégrehajtást/nyomon követést végeznek (csak "Alapszintű" hozzáférési szinttel kell rendelkezniük), nem terhelik őket a csomagkezelés összetettsége (a definiálási lap rejtett az ilyen felhasználók számára).

A Definiálás lap és bizonyos műveletek csak az Basic + Test Plans hozzáférési szinttel vagy azzal egyenértékű felhasználók számára érhetők el. Mindent, beleértve a "Végrehajtás" lapot is, az "Alapszintű" hozzáféréssel rendelkező felhasználónak kell tudnia használni.

Feladatok

A Végrehajtás lapon a következő feladatokat hajthatja végre:

• Tesztpontok tömeges megjelölése: Ezzel a beállítással gyorsan megjelölheti a tesztpontok eredményét – átadott, sikertelen, letiltott vagy nem alkalmazható – anélkül, hogy a tesztesetet a tesztfuttatón keresztül kellene futtatnia. Az eredmény egy lépésben egy vagy több tesztpontra is megjelölhető.
• Tesztpontok futtatása: Ezzel a beállítással futtathatja a teszteseteket úgy, hogy egyenként végigmegy az egyes tesztlépéseken, és egy tesztfuttatóval megjelöli az átmenő/sikertelen teszteket. A tesztelt alkalmazástól függően a "Web Runner" használatával tesztelheti a "webalkalmazást" vagy az asztali futót asztali és/vagy webalkalmazások teszteléséhez. A "Futtatás a beállításokkal" parancsot is meghívva megadhatja azt a buildet, amelynek a tesztelését el szeretné végezni.
• Oszlopbeállítások: A Végrehajtás lapon látható oszlopok listáját az "Oszlopbeállítások" paranccsel kezelheti. A kiválasztáshoz elérhető oszlopok listája olyan tesztpontokhoz van társítva, mint a Futtatás, a Hozzárendelt tesztelő, a Konfiguráció stb.
• Teljes képernyős nézet: Ezzel a beállítással teljes képernyős módban tekintheti meg a teljes Végrehajtás lap tartalmát.
• Szűrés: A szűrősáv segítségével szűrheti a tesztpontok listáját a "teszteset címe", "hozzárendelt személy", "állapot", "teszteredmény", "tesztelő" és "konfiguráció" mezők alapján. A listát az oszlopfejlécekre kattintva is rendezheti.

Helyi menü beállításai

Az Execute (Végrehajtás) lapon található Tesztpont csomópont helyi menüje a következő lehetőségeket kínálja:

• Teszteredmény megjelölése: A fentiekkel megegyező módon gyorsan megjelölheti a tesztpontok eredményét – átadott, sikertelen, letiltott vagy nem alkalmazható.
• Tesztpontok futtatása: A fentihez hasonlóan lehetővé teszi a tesztesetek futtatását tesztfuttatón keresztül.
• Teszt visszaállítása aktív: Ezzel a beállítással visszaállíthatja a teszt eredményét aktívra, így figyelmen kívül hagyhatja a tesztpont utolsó eredményét.
• Teszteset munkaelem űrlapjának megnyitása/szerkesztése: Ez a beállítás lehetővé teszi a teszteset szerkesztését a munkaelem űrlap használatával, amelyben szerkesztheti a munkaelemmezőket, beleértve a tesztlépéseket is.
• Tesztelőhozzárendelése: Ezzel a beállítással a tesztpontokat a tesztelőkhöz rendelheti a tesztvégrehajtáshoz.
• Teszteredmények megtekintése: Ezzel a beállítással megtekintheti a teszt eredményeinek legfrissebb részleteit, beleértve az egyes tesztlépések eredményét, a hozzáadott megjegyzéseket vagy a hibákat.
• Végrehajtási előzmények megtekintése: Ezzel a beállítással megtekintheti a kijelölt tesztpont teljes végrehajtási előzményeit. Ekkor megnyílik egy új oldal, amelyen a szűrőket úgy módosíthatja, hogy ne csak a kiválasztott tesztpont, hanem a teljes teszteset végrehajtási előzményeit is megtekinthesse.

Teszttervek – előrehaladási jelentés

Ez a beépített jelentés segít nyomon követni egy vagy több tesztterv végrehajtását és állapotát egy projektben. A jelentés használatának megkezdéséhez látogasson el a Teszttervek > Folyamatjelentés* lapra.

A jelentés három szakasza a következőket tartalmazza:

1. Összefoglaló: a kiválasztott teszttervek összesített nézetét jeleníti meg.
2. eredmények trendje: napi pillanatképet jelenít meg a végrehajtás és az állapot trendvonalának megjelenítéséhez. 14 napra (alapértelmezett), 30 napra vagy egyéni tartományra vonatkozó adatokat jeleníthet meg.
3. Részletek: ez a szakasz lehetővé teszi az egyes tesztcsomagok részletezését, és fontos elemzéseket biztosít az egyes tesztcsomagokhoz.

Műtárgyak

Jegyzet

Az Azure DevOps Server 2020 nem importálja a lomtárban lévő hírcsatornákat az adatimportálás során. Ha a lomtárban lévő hírcsatornákat szeretné importálni, az adatimportálás megkezdése előtt állítsa vissza őket a lomtárból.

Licenckifejezések és beágyazott licencek

Most már megtekintheti az Azure Artifactsben tárolt NuGet-csomagok licencadatainak részleteit, miközben a Visual Studióban böngészi a csomagokat. Ez a licenckifejezések vagy beágyazott licencek használatával képviselt licencekre vonatkozik. Most a Visual Studio csomaginformációs lapján (az alábbi képen piros nyíl) láthatja a licencinformációkra mutató hivatkozást.

A hivatkozásra kattintva egy weblapra léphet, ahol megtekintheti a licenc részleteit. Ez a felület a licenckifejezések és a beágyazott licencek esetében is ugyanaz, így az Azure Artifactsben tárolt csomagok licencadatait egy helyen tekintheti meg (olyan csomagok esetében, amelyek licencinformációkat adnak meg, és amelyeket a Visual Studio támogat).

Egyszerűsített hitelesítési feladatok

Mostantól egyszerű hitelesítési feladatokkal végezhet hitelesítést az Azure Pipelines népszerű csomagkezelőivel. Ide tartozik a NuGet, az npm, a PIP, a Twine és a Maven. Korábban ezeket a csomagkezelőket olyan feladatokkal hitelesítheti, amelyek nagy mennyiségű funkciót biztosítottak, beleértve a csomagok közzétételének és letöltésének lehetőségét. Ehhez azonban ezeket a feladatokat kellett használnia a csomagkezelőkkel interakcióba lépő összes tevékenységhez. Ha saját szkripteket futtatna olyan feladatok végrehajtásához, mint a csomagok közzététele vagy letöltése, akkor nem használhatja őket a folyamaton belül. Most már használhatja a saját tervezésű szkripteket a folyamat YAML-ben, és elvégezheti a hitelesítést ezekkel az egyszerűsített feladatokkal. Példa az npm használatával:

Az ábrán a "ci" és a "publish" parancs használata tetszőleges, az Azure Pipelines YAML által támogatott parancsokat használhatja. Ez lehetővé teszi a parancshívások teljes vezérlését, és megkönnyíti a megosztott szkriptek használatát a folyamatkonfigurációban. További információ: NuGet, npm, PIP, Twineés Maven hitelesítési feladat dokumentációja.

A hírcsatorna lap betöltési idejének fejlesztései

Örömmel jelentjük be, hogy javítottuk a hírcsatornaoldal betöltési idejét. A hírcsatorna oldal betöltési ideje átlagosan 10%-nal csökkent. A legnagyobb hírcsatornák a legnagyobb javulást a 99. percentilis adatcsatorna lapbetöltési ideje (az összes adatcsatorna legnagyobb 99% betöltési ideje) 75%csökkent.

Ossza meg csomagjait nyilvános hírcsatornákon keresztül

Most már létrehozhatja és tárolhatja a csomagjait nyilvános tárolókban. A nyilvános hírcsatornákban tárolt csomagok hitelesítés nélkül érhetők el az interneten, függetlenül attól, hogy a gyűjteményben vannak-e, vagy akár bejelentkeztek egy Azure DevOps-gyűjteménybe. További információt a nyilvános hírcsatornákról a hírcsatornák dokumentációja-ban talál, vagy ugorjon közvetlenül a oktatóanyagunkba, hogy megtudja, hogyan oszthatja meg a csomagokat nyilvánosan.

Upstreamok konfigurálása különböző gyűjteményekben egy Azure Active Directory bérlőn belül

Mostantól hozzáadhat egy hírcsatornát egy másik gyűjteményhez, amely az Azure Active Directory-bérlőhöz (AAD) van társítva, mint felsőbb rétegbeli forrást az Artifacts-hírcsatornához. A hírcsatorna megkeresheti és használhatja a felsőbb rétegbeli forrásként konfigurált hírcsatornák csomagjait, így a csomagok könnyen megoszthatók az AAD-bérlőhöz társított gyűjtemények között. Tekintse meg, hogyan beállítani ezt a dokumentumokat.

A Python hitelesítőadat-szolgáltató használata a pip és a twine hitelesítéséhez az Azure Artifacts-hírcsatornákkal

Most már telepítheti és használhatja a Python hitelesítőadat-szolgáltatót (artifacts-keyring), hogy automatikusan beállítsa a hitelesítést Python-csomagok közzétételéhez vagy felhasználásához egy Azure Artifacts-csatornán. A hitelesítőadat-szolgáltatónál nem kell konfigurációs fájlokat beállítania (pip.ini/pip.conf/.pypirc), a rendszer egyszerűen végigvezeti egy hitelesítési folyamaton a webböngészőben, amikor először hívja meg a pipet vagy a zsineget. További információért lásd a dokumentációt .

Azure Artifacts-hírcsatornák a Visual Studio Package Managerben

Mostantól a Visual Studio NuGet Package Managerben megjelenítjük a csomagikonokat, a leírásokat és a szerzőket az Azure Artifacts-hírcsatornákból kiszolgált csomagokhoz. Korábban a metaadatok többsége nem lett megadva a VS-nek.

Frissített Csatlakozás a hírcsatorna felületéhez

A Csatlakozás a hírcsatornához párbeszédpanel az Azure Artifacts használatának belépési útja; Információkat tartalmaz arról, hogyan konfigurálhatja az ügyfeleket és az adattárakat csomagok leküldésére és lekérésére az Azure DevOps csatornáiból. Frissítettük a párbeszédpanelt, hogy részletes beállítási információkat adjunk hozzá, és kibővítsük azokat az eszközöket, amelyekhez útmutatást adunk.

A nyilvános hírcsatornák mostantól általánosan elérhetők a felsőbb rétegbeli támogatással

A nyilvános hírcsatornák előzetes verziója nagyszerű elterjedést és visszajelzést kapott. Ebben a kiadásban további funkciókat bővítettünk az általános rendelkezésre állásra. Most beállíthat egy nyilvános hírcsatornát felsőbb rétegbeli forrásként egy privát hírcsatornából. A konfigurációs fájlok egyszerűek maradnak azáltal, hogy mind privát, mind projekt körébe tartozó hírcsatornákba fel- és visszaküldhetők.

Projekt hatókörű hírcsatornák létrehozása a portálról

Nyilvános hírcsatornák kiadásakor projekt hatókörű hírcsatornákat is kiadtunk. Eddig a projekthatókörű hírcsatornák REST API-kkal vagy egy nyilvános hírcsatorna létrehozásával hozhatók létre, majd a projekt privátvá alakításával. Mostantól bármelyik projektből létrehozhat projekthatókörű hírcsatornákat, ha rendelkezik a szükséges engedélyekkel. Azt is láthatja, hogy mely hírcsatornák projekthez kötődnek, és melyek gyűjteményhez tartoznak a hírcsatorna-választóban.

Az npm teljesítménybeli fejlesztései

Módosítottuk az alapvető kialakítást, hogy jobb legyen az npm-csomagok tárolása és kézbesítése az Azure Artifacts-hírcsatornákban. Ez hozzájárult ahhoz, hogy akár tízszeresére csökkentsünk a késést az npm-hez használt legmagasabb API-k közül.

Akadálymentességi fejlesztések

A hírcsatornák oldalán üzembe helyeztünk javításokat az akadálymentességi problémák megoldásához. A javítások a következőket tartalmazzák:

• Hírcsatorna-élmény létrehozása
• Globális hírcsatorna-beállítások felhasználói élménye
• Csatlakozás a hírcsatorna felületéhez

Wiki

Kód wiki oldalak gazdag szerkesztése

Korábban a kód wikilapjának szerkesztésekor a rendszer átirányította az Azure Repos hubra szerkesztés céljából. A Repo Hub jelenleg nincs markdown-szerkesztésre optimalizálva.

Most már szerkesztheti a kód wikilapját a wikin belüli egymás melletti szerkesztőben. Ez lehetővé teszi, hogy a rich markdown eszköztár használatával hozza létre a tartalmat, így a szerkesztési élmény megegyezik a projekt wikijében lévővel. Az adattárakban a helyi menü Szerkesztés a Tárakban lehetőség kiválasztásával továbbra is szerkesztheti az adattárakban.

Munkaelemek létrehozása és beágyazása wikilapról

Amikor meghallgattuk a visszajelzését, azt hallottuk, hogy a wiki használatával készít ötletgyűjtési dokumentumokat, dokumentumokat tervez, ötleteket a funkciókról, specifikációs dokumentumokat, értekezleti jegyzőkönyveket készít. Mostantól egyszerűen létrehozhat funkciókat és felhasználói történeteket közvetlenül egy tervezési dokumentumból anélkül, hogy elhagyná a wikilapot.

Munkaelem létrehozásához jelölje ki azt a szöveget a wikilapon, ahová beágyazni szeretné a munkaelemet, majd válassza Új munkaelemlehetőséget. Ez időt takarít meg Önnek, mivel nem kell először létrehoznia a munkaelemet, majd szerkesztenie és megkeresnie azt a beágyazáshoz. Emellett csökkenti a környezetváltást is, mivel nem lép ki a wiki hatóköréből.

Ha többet szeretne megtudni egy munkaelem wikiből való létrehozásáról és beágyazásáról, tekintse meg dokumentációnkat, itt.

Megjegyzések a wikilapokban

Korábban nem volt módja arra, hogy más wikifelhasználókkal is kommunikáljon a wikiben. Ezzel a tartalommal való együttműködés és a kérdések megválaszolása kihívást jelentett, mivel a beszélgetéseknek e-mailben vagy csevegőcsatornán keresztül kellett történnie. Megjegyzésekkel mostantól közvetlenül a wikin belül is együttműködhet másokkal. A @mention felhasználók megjegyzésen belüli funkcióit kihasználva felhívhatja a többi csapattag figyelmét. Ezt a funkciót a javaslati jegy alapján rangsorolták. A megjegyzésekről további információt a dokumentációnkban talál, itt.

Mappák és fájlok elrejtése a következővel kezdődően: "." wiki fában

Eddig a wikifa a wikifán egy ponttal (.) kezdődő összes mappát és fájlt megmutatta. A kód wiki forgatókönyvekben ez azt okozta, hogy a rejtettnek szánt mappák, mint a .vscode, megjelentek a wiki struktúrában. Mostantól a ponttal kezdődő összes fájl és mappa rejtve marad a wikifában, így csökken a felesleges zsúfoltság.

Ezt a funkciót a javaslati jegy alapján rangsorolták.

Rövid és olvasható wikilap URL-címei

Többé nem kell többsoros URL-címet használnia a wikioldal-hivatkozások megosztásához. Az URL-cím oldalazonosítóit felhasználva eltávolítjuk a paramétereket, így az URL-cím rövidebb és könnyebben olvasható.

Az URL-címek új struktúrája a következőképpen fog kinézni:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Ez egy példa egy üdvözli az Azure DevOps Wiki lap új URL-címét:

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Ez prioritást kapott a Fejlesztői Közösségtől származó funkciójavaslat-jegy alapján.

Szinkron görgetés wikilapok szerkesztéséhez

A wikilapok szerkesztése mostantól egyszerűbbé vált a szerkesztés és az előnézeti ablaktábla közötti szinkron görgetéssel. Az egyik oldalon való görgetés automatikusan görget a másik oldalon a megfelelő szakaszok leképezéséhez. A váltógombbal letilthatja a szinkron görgetést.

Jegyzet

A szinkron görgetőkapcsoló állapota felhasználónként és fiókonként lesz mentve.

Wikioldalak oldallátogatásai

Most már betekintést nyerhet a wikilapok oldallátogatásaiba. A REST API lehetővé teszi az oldallátogatások adatainak elérését az elmúlt 30 napban. Ezekkel az adatokkal jelentéseket hozhat létre a wikilapokhoz. Emellett ezeket az adatokat az adatforrásban is tárolhatja, és irányítópultokat hozhat létre, hogy konkrét megállapításokat kapjon, például a legnézettebb lapokat.

A laplátogatások összesített száma is megjelenik az elmúlt 30 napban minden oldalon.

Jegyzet

Az oldallátogatásokat egy adott felhasználó oldalnézetként definiálja 15 perces időközönként.

Jelentési

Csővezeték hiba és időtartamjelentések

A metrikák és elemzések segítségével folyamatosan javíthatja a folyamatok átviteli sebességét és stabilitását. Két új jelentést adtunk hozzá, amelyek betekintést nyújtanak a pipeline-ekbe.

1. A kudarcjelentés a build sikerességi rátát és a hibatrendet mutatja. Emellett a feladathibák trendje is látható lesz, így betekintést nyerhet abba, hogy a folyamat mely tevékenysége járul hozzá a hibák maximális számához.

2. A csővezeték-folyamat időtartamáról szóló jelentés megmutatja a csővezeték futtatásához szükséges idő trendjét. Azt is megmutatja, hogy a folyamat mely tevékenységei veszik a legtöbb időt.

A Lekérdezési eredmények widget továbbfejlesztése

A lekérdezési eredmények widget az egyik legnépszerűbb widget, és jó okkal. A widget közvetlenül az irányítópulton jeleníti meg a lekérdezés eredményeit, és sok esetben hasznos.

Ezzel a frissítéssel számos régóta várt fejlesztést tartalmaztunk:

• Mostantól annyi oszlopot választhat ki, amennyit meg szeretne jeleníteni a widgetben. Nincs több 5 oszlopos korlát!
• A widget minden méretet támogat, 1x1-től 10x10-esig.
• Ha átméretez egy oszlopot, az oszlop szélességelesz mentve.
• A widgetet kibonthatja teljes képernyős nézetre. Kibontva megjeleníti a lekérdezés által visszaadott összes oszlopot.

Átvezetési és ciklusidő vezérlők speciális szűrése

csapatok az átfutási és ciklusidőt használják annak megtekintéséhez, hogy mennyi ideig tart a munka a fejlesztési folyamatokon keresztül, és végső soron értéket nyújtsanak az ügyfeleiknek.

Eddig az átvezetési és ciklusidő widgetek nem támogatták a speciális szűrési feltételeket, hogy olyan kérdéseket tegyenek fel, mint például: "mennyi időbe telik, amíg a csapatom bezárja a magasabb prioritású elemeket?"

Ezzel a frissítéssel az ehhez hasonló kérdésekre a tábla úszósávjának szűrésével lehet válaszolni.

Munkaelem-szűrőket is tartalmaztunk, hogy korlátozzuk a diagramon megjelenő munkaelemeket.

Inline sprint burndown a történeti pontok használatával

A Sprint Burndown mostantól leéghet a Stories alapján. A fejlesztői közösségvisszajelzéseire reagálunk.

A Sprint Hubon válassza az Elemzés lapot. Ezután konfigurálja a jelentést az alábbiak szerint:

1. Válassza ki a függőben lévő történeteket
2. Válassza ki a leégést Történeti pontok összegzése

Egy Sprint Burndown widget mindennel, amit mindig is szeretett volna

Az új Sprint Burndown widget támogatja a leépítést történetpontok, feladatok száma alapján vagy egyéni mezők összegzésével. A funkciókhoz vagy az Epicshez akár sprint burndownt is létrehozhat. A widget megjeleníti az átlagos felhasználást, a % megteljesítettséget és a terjedelem növekedését. Konfigurálhatja a csapatokat, lehetővé téve, hogy több csapat sprint teljesítményét jelenítse meg ugyanazon a műszerfalon. Ezzel a nagyszerű információval megjelenítés céljából akár 10x10 méretekre is átméretezheti az irányítópulton.

A kipróbáláshoz hozzáadhatja a widgetkatalógusból, vagy a meglévő Sprint Burndown widget konfigurációjának szerkesztésével és a Az új verzió kipróbálása most jelölőnégyzet bejelölésével próbálhatja ki.

Jegyzet

Az új widget az Analytics szolgáltatást használja. Megtartottuk a régebbi Sprint Burndownt, arra az esetre, ha nem férne hozzá az Analyticshez.

Beágyazott sprint visszaszámláló miniatűr kép

A Sprint Burndown visszatért! Néhány sprintekkel ezelőtt eltávolítottuk a környezetbeli sprint burndown táblázatot a Sprint Burndown és a Taskboard fejezetekből. Visszajelzése alapján továbbfejlesztettük és újra bevezettük a sprint burndown bélyegképét.

A miniatűrre kattintva azonnal megjelenik a diagram egy nagyobb verziója, és az Elemzés lap alatt megtekintheti a teljes jelentést. A teljes jelentés módosításai megjelennek a fejlécben megjelenő diagramon. Így mostantól úgy is konfigurálhatja, hogy a történetek, a történeti pontok vagy a tevékenységek száma alapján leégjen a hátralévő munka mennyisége helyett.

Irányítópult létrehozása csapat nélkül

Most már létrehozhat egy irányítópultot anélkül, hogy társítaná egy csapathoz. Irányítópult létrehozásakor válassza ki a Projekt irányítópult típusát.

A projekt irányítópultja olyan, mint egy csapat irányítópultja, kivéve, hogy nincs csapathoz társítva, és ön döntheti el, hogy ki szerkesztheti vagy kezelheti az irányítópultot. A Csapat irányítópulthoz hasonlóan a projekt minden tagja számára látható.

A csapatkörnyezetet igénylő összes Azure DevOps-widget frissült, hogy lehetővé tegyék a csapat kiválasztását a konfiguráció során. Ezeket a widgeteket hozzáadhatja a Project-irányítópultokhoz, és kiválaszthatja a kívánt csapatot.

Jegyzet

Egyéni vagy külső widgetek esetén a Project irányítópultja átadja az alapértelmezett csapat kontextusát ezeknek a widgeteknek. Ha van egy egyéni widgetje, amely a csapatkörnyezetre támaszkodik, frissítse a konfigurációt, hogy lehetővé tegye a csapat kiválasztását.

---

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