zpráva k vydání verze Azure DevOps Server 2020

| Developer Community Požadavky systému | Licenční podmínky | ProDevOps Blog | Hash SHA-1

V tomto článku najdete informace týkající se nejnovější verze Azure DevOps Server.

Další informace o instalaci nebo upgradu nasazení Azure DevOps Server najdete v tématu Azure DevOps Server Požadavky. Pokud si chcete stáhnout produkty Azure DevOps, navštivte stránku Azure DevOps Server stažení.

Přímý upgrade na Azure DevOps Server 2020 se podporuje od Azure DevOps Server 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud je vaše nasazení TFS na TFS 2010 nebo starší, musíte před upgradem na Azure DevOps Server 2019 provést některé dílčí kroky. Další informace najdete v tématu Instalace a konfigurace Azure DevOps místně.

---

Bezpečný upgrade z Azure DevOps Server 2019 na Azure DevOps Server 2020

Azure DevOps Server 2020 zavádí nový model uchovávání dat spuštění kanálu (sestavení), který funguje na základě nastavení na úrovni projektu.

Azure DevOps Server 2020 zpracovává uchovávání sestavení odlišně v závislosti na zásadách uchovávání informací na úrovni kanálu. Některé konfigurace zásad vedou k odstranění spuštění kanálu po upgradu. Spuštění kanálu, která byla ručně zachována nebo jsou zachována ve vydané verzi, se po upgradu neodstraní.

Další informace o tom, jak bezpečně upgradovat z Azure DevOps Server 2019 na Azure DevOps Server 2020, najdete v našem blogovém příspěvku.

Azure DevOps Server 2020 Update 0.2 Patch 6 Datum vydání: 14. listopadu 2023

Vydali jsme opravu pro aktualizaci Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• Rozšířili seznam povolených znaků úloh PowerShellu pro ověřování parametrů parametrů povolit úlohy prostředí.

Poznámka

Pokud chcete implementovat opravy této opravy, budete muset ručně aktualizovat úlohy pomocí několika kroků.

Instalace oprav

Důležité

Vydali jsme aktualizace agenta Azure Pipelines s opravou Patch 4, která byla vydána 12. září 2023. Pokud jste nenainstalovali aktualizace agenta, jak je popsáno v poznámkách k verzi 4, doporučujeme tyto aktualizace nainstalovat před instalací opravy Patch 6. Nová verze agenta po instalaci opravy Patch 4 bude 3.225.0.

Konfigurace TFX

1. Postupujte podle kroků v dokumentaci k nahrání úkolů do kolekce projektů a nainstalujte a přihlaste se pomocí tfx-cli.

Aktualizace úloh pomocí TFX

File	Hodnota hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Stáhněte a extrahujte Tasks20231103.zip.
2. Změňte adresář na extrahované soubory.
3. Spuštěním následujících příkazů nahrajte úlohy:

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 

Požadavky na kanál

Pokud chcete použít nové chování, musí být proměnná AZP_75787_ENABLE_NEW_LOGIC = true nastavena v kanálech, které používají ovlivněné úlohy.

• Na klasickém:

  Definujte proměnnou na kartě proměnné v kanálu.

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Datum vydání: 10. října 2023

Důležité

Vydali jsme aktualizace agenta Azure Pipelines s opravou Patch 4, která byla vydána 12. září 2023. Pokud jste nenainstalovali aktualizace agenta, jak je popsáno v poznámkách k verzi 4, doporučujeme tyto aktualizace nainstalovat před instalací opravy Patch 5. Nová verze agenta po instalaci opravy Patch 4 bude 3.225.0.

Vydali jsme opravu pro Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• Opravili jsme chybu, kdy se identita vlastníka analýzy na počítačích s upgradem oprav zobrazovala jako neaktivní identita.

Azure DevOps Server 2020 Update 0.2 Patch 4 Datum vydání: 12. září 2023

Vydali jsme opravu pro aktualizaci Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• CVE-2023-33136: Azure DevOps Server ohrožení zabezpečení z důvodu vzdáleného spuštění kódu.
• CVE-2023-38155: Ohrožení zabezpečení Azure DevOps Server a Team Foundation Server z důvodu zvýšení oprávnění.

Důležité

Před použitím opravy v produkčním prostředí nasaďte opravu do testovacího prostředí a ujistěte se, že kanály prostředí fungují podle očekávání.

Poznámka

Pokud chcete implementovat opravy této opravy, budete muset ručně aktualizovat agenta a úlohy pomocí několika kroků.

Instalace oprav

1. Stáhněte a nainstalujte aktualizaci Azure DevOps Server 2020 Update 0.2 patch 4.

Aktualizace agenta Azure Pipelines

1. Stáhněte si agenta z: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. K nasazení agenta použijte postup popsaný v dokumentaci k agentům v místním prostředí pro Windows .  

Poznámka

Aby se zabránilo downgradu agenta, musí být AZP_AGENT_DOWNGRADE_DISABLED nastavená na hodnotu true. V systému Windows je možné na příkazovém řádku pro správu použít následující příkaz následovaný restartováním. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurace TFX

1. Postupujte podle kroků v dokumentaci k nahrání úkolů do kolekce projektů a nainstalujte a přihlaste se pomocí tfx-cli.

Aktualizace úloh pomocí TFX

1. Stáhněte a extrahujte Tasks_20230825.zip.
2. Změňte adresář na extrahované soubory.
3. Spuštěním následujících příkazů nahrajte úlohy:

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 

Požadavky na kanál

Pokud chcete použít nové chování, musí být proměnná AZP_75787_ENABLE_NEW_LOGIC = true nastavena v kanálech, které používají ovlivněné úlohy.

• Na klasickém:

  Definujte proměnnou na kartě proměnné v kanálu.

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 3 Datum vydání: 8. srpna 2023

Vydali jsme opravu pro Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• Opravili jsme chybu, která bránila při odesílání balíčků při upgradu z verze 2018 nebo starší.

Azure DevOps Server 2020 Update 0.2 Patch 2 Datum vydání: 13. června 2023

Vydali jsme opravu pro Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• Opravili jsme chybu, která bránila při odesílání balíčků při upgradu z verze 2018 nebo starší.

Azure DevOps Server 2020 Update 0.2 Patch 1 Datum vydání: 18. října 2022

Vydali jsme opravu pro Azure DevOps Server 2020 Update 0.2, která obsahuje opravy pro následující:

• Vyřešte problém s nově přidanými identitami AD, které se nezobrazují ve výběrech identit dialogového okna zabezpečení.
• Opravte problém s filtrem Requested by Member of Group v nastavení web hooku.
• Opravili jsme chybu sestavení s gateýmými kontrolou, když nastavení organizace pro kanál mělo nakonfigurovaný obor autorizace úloh jako Omezit rozsah autorizace úloh na aktuální projekt pro kanály, které nejsou vydané verze.

Azure DevOps Server 2020.0.2 Datum vydání: 17. května 2022

Azure DevOps Server 2020.0.2 je soubor oprav chyb. Můžete přímo nainstalovat Azure DevOps Server 2020.0.2 nebo upgradovat z Azure DevOps Server 2020 nebo Team Foundation Serveru 2013 nebo novějšího.

Poznámka

Nástroj pro migraci dat bude k dispozici pro Azure DevOps Server 2020.0.2 přibližně tři týdny po této verzi. Náš seznam aktuálně podporovaných verzí pro import najdete tady.

Tato verze obsahuje opravy pro následující:

• Frontu sestavení nejde přeskočit pomocí tlačítka Spustit další. Dříve bylo tlačítko Spustit další povolené jenom pro správce kolekcí projektů.

• Po zakázání účtu Služby Active Directory uživatele odvoláte všechny tokeny osobního přístupu.

Azure DevOps Server 2020.0.1 Patch 9 Datum vydání: 26. ledna 2022

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která obsahuje opravy pro následující:

• Email oznámení nebyla odeslána při použití @mention ovládacího prvku v pracovní položce.
• Oprava TF400813 chyby při přepínání účtů K této chybě došlo při upgradu z TFS 2018 na Azure DevOps Server 2020.0.1.
• Oprava potíží se selháním načtení stránky souhrnu přehledu projektu
• Vylepšení synchronizace uživatelů služby Active Directory.
• Byla vyřešena chyba zabezpečení Elasticsearch odebráním třídy jndilookup z binárních souborů log4j.

Kroky instalace

1. Upgradujte server pomocí opravy Patch 9.
2. Zkontrolujte hodnotu registru na adrese HKLM:\Software\Elasticsearch\Version. Pokud hodnota registru neexistuje, přidejte řetězcovou hodnotu a nastavte Hodnotu Verze na 5.4.1 (Název = Verze, Hodnota = 5.4.1).
3. Spusťte příkaz PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update, jak je uvedeno v souboru readme. Může se vrátit upozornění typu: Nejde se připojit ke vzdálenému serveru. Nezavírejte okno, protože aktualizace provádí opakované pokusy, dokud se nedokončí.

Poznámka

Pokud jsou Azure DevOps Server a Elasticsearch nainstalované na různých počítačích, postupujte podle níže uvedených kroků.

1. Upgradujte server pomocí opravy Patch 9.
2. Zkontrolujte hodnotu registru na adrese HKLM:\Software\Elasticsearch\Version. Pokud hodnota registru neexistuje, přidejte řetězcovou hodnotu a nastavte Hodnotu Verze na 5.4.1 (Název = Verze, Hodnota = 5.4.1).
3. Zkopírujte obsah složky s názvem zip, která se nachází na C:\Program Files\{TFS Version Folder}\Search\zip , do složky se vzdálenými soubory Elasticsearch.
4. Na počítači serveru Elasticsearch spusťte příkaz Configure-TFSSearch.ps1 -Operation update .

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 Patch 8 Datum vydání: 15. prosince 2021

Oprava 8 pro Azure DevOps Server 2020.0.1 obsahuje opravy pro následující:

• Problém s lokalizací pro vlastní stavy rozložení pracovních položek
• Problém s lokalizací v šabloně e-mailových oznámení
• Problém se zkrácením protokolů konzoly, když je v řádku více identických odkazů
• Problém s vyhodnocením pravidel NOTSAMEAS, když bylo pro pole definováno více pravidel NOTSAMEAS

Azure DevOps Server 2020.0.1 Patch 7 Datum vydání: 26. října 2021

Oprava 7 pro Azure DevOps Server 2020.0.1 obsahuje opravy pro následující:

• Dříve Azure DevOps Server mohly vytvářet pouze připojení k Serveru GitHub Enterprise. Díky této opravě můžou správci projektů vytvářet připojení mezi Azure DevOps Server a úložišti na GitHub.com. Toto nastavení najdete na stránce připojení GitHubu v části Nastavení projektu.
• Vyřešte problém s widgetem Testovací plán. V sestavě provádění testu se ve výsledcích zobrazoval nesprávný uživatel.
• Oprava potíží se selháním načtení stránky souhrnu přehledu projektu
• Oprava potíží s neposílanými e-maily pro potvrzení upgradu produktu

Azure DevOps Server 2020.0.1 Patch 6 Datum vydání: 14. září 2021

Oprava 6 pro Azure DevOps Server 2020.0.1 obsahuje opravy pro následující:

• Opravte selhání stahování nebo nahrávání artefaktů.
• Vyřešte problém s nekonzistentními daty výsledků testů.

Azure DevOps Server 2020.0.1 Patch 5 Datum vydání: 10. srpna 2021

Oprava 5 pro Azure DevOps Server 2020.0.1 obsahuje opravy pro následující:

• Oprava chyby uživatelského rozhraní definice sestavení
• Změna historie procházení tak, aby zobrazovala soubory místo kořenového úložiště.
• Oprava potíží s úlohami doručování e-mailů u některých typů pracovních položek

Azure DevOps Server 2020.0.1 Patch 4 Datum vydání: 15. června 2021

Oprava 4 pro Azure DevOps Server 2020.0.1 obsahuje opravy pro následující:

• Oprava problému s importem dat Zákazníkům, kteří mají spoustu zastaralých testovacích případů, trval import dat dlouhou dobu. Důvodem byly odkazy, které zvětšily tbl_testCaseReferences velikost tabulky. Touto opravou jsme odebrali odkazy na zastaralé testovací případy, abychom urychlili proces importu dat.

Azure DevOps Server 2020.0.1 Patch 3 Datum vydání: 11. května 2021

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která opravuje následující:

• Nekonzistentní data výsledků testu při použití Microsoft.TeamFoundation.TestManagement.Client.

Pokud máte Azure DevOps Server 2020.0.1, měli byste nainstalovat Azure DevOps Server 2020.0.1 Patch 3.

Ověření instalace

• Možnost 1: Spusťte devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe je soubor, který se stáhne z výše uvedeného odkazu. Výstup příkazu buď bude hlásit, že oprava je nainstalovaná, nebo že nainstalovaná není.

• Možnost 2: Zkontrolujte verzi následujícího souboru: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 je ve výchozím nastavení nainstalovaný.c:\Program Files\Azure DevOps Server 2020 Po instalaci Azure DevOps Server 2020.0.1 Patch 3 bude verze 18.170.31228.1.

datum vydání patche 2 Azure DevOps Server 2020.0.1: 13. dubna 2021

Poznámka

Pokud máte Azure DevOps Server 2020, měli byste nejprve aktualizovat na Azure DevOps Server 2020.0.1. Jakmile bude verze 2020.0.1, nainstalujte Azure DevOps Server 2020.0.1 Patch 2.

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která opravuje následující:

• CVE-2021-27067: Zpřístupnění informací
• CVE-2021-28459: Zvýšení oprávnění

Pokud chcete implementovat opravy této opravy, budete muset postupovat podle níže uvedených kroků pro instalaci obecných oprav, AzureResourceGroupDeploymentV2 a AzureResourceManagerTemplateDeploymentV3 .

Obecná instalace oprav

Pokud máte Azure DevOps Server 2020.0.1, měli byste nainstalovat opravu 2 Azure DevOps Server 2020.0.1.

Ověření instalace

• Možnost 1: Spusťte devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe je soubor, který se stáhne z výše uvedeného odkazu. Výstup příkazu buď bude hlásit, že oprava je nainstalovaná, nebo že nainstalovaná není.

• Možnost 2: Zkontrolujte verzi následujícího souboru: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 je ve výchozím nastavení nainstalovaný.c:\Program Files\Azure DevOps Server 2020 Po instalaci Azure DevOps Server 2020.0.1 Patch 2 bude verze 18.170.31123.3.

Instalace úlohy AzureResourceGroupDeploymentV2

Poznámka

Všechny kroky uvedené níže je potřeba provést na počítači s Windows.

Instalace

1. Extrahujte balíčekAzureResourceGroupDeploymentV2.zip do nové složky v počítači. Příklad: D:\tasks\AzureResourceGroupDeploymentV2.

2. Stáhněte a nainstalujte Node.js 14.15.1 a npm (součástí Node.js stažení) podle svého počítače.

3. Otevřete příkazový řádek v režimu správce a spuštěním následujícího příkazu nainstalujte tfx-cli.

npm install -g tfx-cli

4. Create token PAT s úplnými přístupovými oprávněními a zkopírujte ho. Tento osobní přístupový token se použije při spuštění příkazu tfx login .

5. Z příkazového řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a osobní přístupový token.

~$ tfx login
Copyright Microsoft Corporation

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

6. Spuštěním následujícího příkazu nahrajte úlohu na server. Použijte cestu k extrahovanému souboru .zip z kroku 1.

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

Instalace úlohy AzureResourceManagerTemplateDeploymentV3

Poznámka

Všechny kroky uvedené níže je potřeba provést na počítači s Windows.

Instalace

1. Extrahujte balíčekAzureResourceManagerTemplateDeploymentV3.zip do nové složky v počítači. Příklad:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Stáhněte a nainstalujte Node.js 14.15.1 a npm (je součástí Node.js ke stažení) podle potřeby pro váš počítač.

3. Otevřete příkazový řádek v režimu správce a spuštěním následujícího příkazu nainstalujte tfx-cli.

npm install -g tfx-cli

4. Create token PAT s úplnými přístupovými oprávněními a zkopírujte ho. Tento osobní přístupový token se použije při spuštění příkazu tfx login .

5. Z příkazového řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a osobní přístupový token.

~$ tfx login
Copyright Microsoft Corporation

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

6. Spuštěním následujícího příkazu nahrajte úlohu na server. Použijte cestu k extrahovanému souboru .zip z kroku 1.

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

Azure DevOps Server 2020.0.1 Patch 1 Datum vydání: 9. února 2021

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• Řešení problému nahlášeného v tomto lístku Developer Community zpětné vazby| Tlačítko Nový testovací případ nefunguje
• Zahrňte opravy vydané v Azure DevOps Server 2020 Patch 2.

datum vydání aktualizace Patch 3 Azure DevOps Server 2020: 9. února 2021

Vydali jsme opravu pro Azure DevOps Server 2020, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• Řešení problému nahlášeného v tomto lístku Developer Community zpětné vazby| Tlačítko Nový testovací případ nefunguje

datum vydání Azure DevOps Server 2020.0.1: 19. ledna 2021

Azure DevOps Server 2020.0.1 je soubor oprav chyb. Můžete přímo nainstalovat Azure DevOps Server 2020.0.1 nebo upgradovat z existující instalace. Podporované verze pro upgrade jsou Azure DevOps Server 2020, Azure DevOps Server 2019 a Team Foundation Server 2012 nebo novější.

Tato verze zahrnuje opravy následujících chyb:

• Vyřešte problém s upgradem z Azure DevOps Server 2019, kdy po upgradu může přestat fungovat proxy Git.
• Oprava výjimky System.OutOfMemoryException pro jiné kolekce než ENU před Team Foundation Server 2017 při upgradu na Azure DevOps Server 2020. Řeší problém nahlášený v tomto lístku Developer Community zpětné vazby.
• Selhání údržby způsobené chybějícími Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll Řeší problém nahlášený v tomto lístku Developer Community zpětné vazby.
• Oprava chyby kvůli neplatnému názvu sloupce v Analytics při upgradu na Azure DevOps Server 2020 Řeší problém nahlášený v tomto lístku Developer Community zpětné vazby.
• Uložené XSS při zobrazení kroků testovacího případu ve výsledcích testovacího případu.
• Selhání kroku upgradu při migraci dat výsledků bodů do TCM.

Datum vydání patche 2 Azure DevOps Server 2020: 12. ledna 2021

Vydali jsme opravu pro Azure DevOps Server 2020, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• Podrobnosti o testovacím běhu nezobrazují podrobnosti o testovacích krocích pro testovací data migrovaná pomocí migrace OpsHubu
• Výjimka inicializátoru pro Microsoft.TeamFoundation.TestManagement.Server.TCMLogger
• Neudržovaná sestavení se po migraci na Azure DevOps Server 2020 okamžitě odstraní.
• Oprava výjimky zprostředkovatele dat

Azure DevOps Server 2020 Patch 1 Datum: 8. prosince 2020

Vydali jsme opravu pro Azure DevOps Server 2020, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-17145: Ohrožení zabezpečení z důvodu falšování identity služeb Azure DevOps Server a Team Foundation Services

Datum vydání Azure DevOps Server 2020: 6. října 2020

Azure DevOps Server 2020 je soubor oprav chyb. Obsahuje všechny funkce dříve vydané verze Azure DevOps Server 2020 RC2.

Poznámka

Azure DevOps 2020 Server má problém s instalací jednoho ze sestavení používaných systémem GVFS (Git Virtual File System).

Pokud upgradujete z Azure DevOps 2019 (libovolné verze) nebo z kandidáta verze Azure DevOps 2020 a instalujete ho do stejného adresáře jako předchozí verze, sestavení Microsoft.TeamFoundation.Git.dll se nenainstaluje. Pokud chcete ověřit, že jste na problém narazili, vyhledejte Microsoft.TeamFoundation.Git.dll ve složkách a <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools .<Install Dir>\Version Control Proxy\Web Services\bin Pokud soubor chybí, můžete chybějící soubory obnovit spuštěním opravy.

Pokud chcete spustit opravu, přejděte Settings -> Apps & Features na Azure DevOps Server počítači nebo virtuálním počítači na a spusťte opravu na Serveru Azure DevOps 2020. Po dokončení opravy můžete počítač nebo virtuální počítač restartovat.

datum vydání Azure DevOps Server 2020 RC2: 11. srpna 2020

Azure DevOps Server 2020 RC2 obsahuje opravy chyb. Obsahuje všechny funkce dříve vydané verze Azure DevOps Server 2020 RC1.

datum opětovného vydání Azure DevOps Server RC1 2020: 10. července 2020

Znovu jsme vydali Azure DevOps Server 2020 RC1, abychom tento lístek Developer Community zpětné vazby opravili.

Dříve jste po upgradu z Azure DevOps Server 2019 Update 1.1 na Azure DevOps Server 2020 RC1 nemohli zobrazit soubory v repos, kanálech a wikiwebu webového uživatelského rozhraní. V této oblasti stránky se zobrazila chybová zpráva oznamující, že došlo k neočekávané chybě. Můžete zkusit znovu načíst tuto komponentu nebo aktualizovat celou stránku. V této verzi jsme tento problém opravili. Další informace najdete v tomto blogovém příspěvku.

datum vydání Azure DevOps Server 2020 RC1: 30. června 2020

Shrnutí novinek v Azure DevOps Server 2020

Azure DevOps Server 2020 přináší mnoho nových funkcí. Mezi nejzajímavější z nich patří:

• Kanály s více fázemi
• Průběžné nasazování v YAML
• Sledování průběhu nadřazených položek pomocí kumulativního backlogu v backlogu Boards
• Přidání filtru Nadřazená pracovní položka na panel úkolů a backlog sprintů
• Nové webové uživatelské rozhraní pro Azure Repos cílové stránky
• Správa zásad větve mezi úložišti
• Stránka Nový testovací plán
• Bohaté úpravy pro stránky wikiwebu kódu
• Sestavy selhání a doby trvání kanálu

Můžete také přejít na jednotlivé oddíly, abyste viděli všechny nové funkce pro jednotlivé služby:

• Obecné
• Boards
• Repos
• Pipelines
• Test Plans
• Artifacts
• Wiki
• Generování sestav

---

Obecné

Obecná dostupnost rozhraní příkazového řádku Azure DevOps

V únoru jsme představili rozšíření Azure DevOps pro Azure CLI. Rozšíření umožňuje interakci s Azure DevOps z příkazového řádku. Shromáždili jsme vaši zpětnou vazbu, která nám pomohla rozšíření vylepšit a přidat další příkazy. S radostí oznamujeme, že rozšíření je obecně dostupné.

Další informace o rozhraní příkazového řádku Azure DevOps najdete v této dokumentaci.

Použití profilu publikování k nasazení Azure WebApps pro Windows z Deployment Center

Teď můžete pomocí publikování ověřování na základě profilu nasadit azure WebApps pro Windows z webu Deployment Center. Pokud máte oprávnění k nasazení do webové aplikace Azure pro Windows pomocí jejího profilu publikování, budete moct nastavit kanál pomocí tohoto profilu v pracovních postupech deployment center.

Boards

Přidání filtru Nadřazená pracovní položka na panel úkolů a backlog sprintů

Přidali jsme nový filtr na panel Sprint i do backlogu Sprint. To umožňuje filtrovat položky backlogu na úrovni požadavků (první sloupec vlevo) podle jejich nadřazené položky. Například na následujícím snímku obrazovky jsme vyfiltrovali zobrazení tak, aby se zobrazovaly jenom uživatelské scénáře, ve kterých je nadřazená položka "Moje velká funkce".

Vylepšení prostředí pro zpracování chyb – povinná pole pro chybu nebo úlohu

Historicky platí, že pokud jste z panelu Kanbanu přesunuli pracovní položku z jednoho sloupce do druhého, kde změna stavu aktivovala pravidla polí, zobrazila by se na kartě červená chybová zpráva, která vás přinutí otevřít pracovní položku, abyste porozuměli původní příčině. Ve sprintu 170 jsme vylepšili prostředí, takže teď můžete kliknout na červenou chybovou zprávu a zobrazit podrobnosti o chybě, aniž byste museli otevírat samotnou pracovní položku.

Opětovné načtení pracovní položky za provozu

Dříve při aktualizaci pracovní položky a druhý člen týmu dělal změny stejné pracovní položky, druhý uživatel o své změny přišel. Pokud teď oba upravujete různá pole, uvidíte živé aktualizace změn provedených v pracovní položce.

Správa iterace a cest k oblastem z příkazového řádku

Iterace a cesty k oblastem teď můžete spravovat z příkazového řádku pomocí az boards iteration příkazů a az boards area . Iterace a cesty k oblastem můžete například nastavit a spravovat interaktivně z rozhraní příkazového řádku nebo automatizovat celé nastavení pomocí skriptu. Další podrobnosti o příkazech a syntaxi najdete v dokumentaci tady.

Možnost Nadřazený sloupec pracovní položky jako sloupec

Teď máte možnost zobrazit nadřazenou položku každé pracovní položky v backlogu produktu nebo v backlogu sprintu. Pokud chcete tuto funkci povolit, přejděte v požadovaném backlogu do části Možnosti sloupce a přidejte sloupec Nadřazený .

Změna procesu používaného projektem

Vaše nástroje by se měly měnit stejně jako váš tým. Teď můžete přepnout projekty z libovolné předefinované šablony procesu na jakýkoli jiný předefinovaný proces. Můžete například změnit projekt z agilního na Scrum nebo z úrovně Basic na agilní. Úplnou podrobnou dokumentaci najdete tady.

Skrytí vlastních polí v rozložení

Při přizpůsobení procesu teď můžete v rozložení formuláře skrýt vlastní pole. Pole bude stále dostupné z dotazů a rozhraní REST API. To se hodí pro sledování dalších polí při integraci s jinými systémy.

Získejte přehled o stavu týmu pomocí tří nových sestav Azure Boards

Nemůžete opravit to, co nevidíte. Proto chcete sledovat stav a stav jejich pracovních procesů. Díky těmto sestavám vám usnadňujeme sledování důležitých metrik s minimálním úsilím v Azure Boards.

Tři nové interaktivní sestavy jsou: Burndown, Kumulativní diagram toku (CFD) a Rychlost. Sestavy si můžete prohlédnout na nové kartě Analýza.

Metriky, jako je burndown sprintu, tok práce a rychlost týmu, poskytují přehled o průběhu vašeho týmu a pomáhají odpovídat na otázky, jako jsou:

• Kolik práce nám zbývá v tomto sprintu? Jsme na cestě, abychom to dokončili?
• Jaký krok vývojového procesu trvá nejdéle? Můžeme s tím něco udělat?
• Kolik práce bychom na základě předchozích iterací měli naplánovat na další sprint?

Poznámka

Grafy dříve zobrazené v záhlavích byly nahrazeny těmito rozšířenými sestavami.

Nové sestavy jsou plně interaktivní a umožňují je upravit podle svých potřeb. Nové sestavy najdete v každém centru na kartě Analýza .

• Graf burndownu najdete v centru Sprints .

  

• Sestavy CFD a Velocity jsou přístupné z karty Analýza v části Boards and Backlogs kliknutím na příslušnou kartu.

  

S novými sestavami získáte větší kontrolu nad týmem a informace. Tady je několik příkladů:

• Sestavy Sprint Burndown a Velocity je možné nastavit tak, aby používaly počet pracovních položek nebo součet zbývající práce.
• Časový rámec burndownu sprintu můžete upravit, aniž by to mělo vliv na data projektu. Pokud tedy váš tým obvykle tráví první den plánování sprintu, můžete teď graf spárovat, aby to odráželo.
• Graf Burndown teď obsahuje vodoznak zobrazující víkendy.
• Sestava CFD umožňuje odebrat sloupce desky, jako je Návrh, abyste se více zaměřili na tok, který mají týmy pod kontrolou.

Tady je příklad sestavy CFD zobrazující tok za posledních 30 dnů backlogu stories.

Graf rychlosti je teď možné sledovat pro všechny úrovně backlogu. Teď můžete například přidat funkce i náměty, zatímco předchozí graf podporoval pouze požadavky. Tady je příklad sestavy rychlosti pro posledních 6 iterací backlogu funkcí.

Přizpůsobení sloupců taskboardu

S radostí oznamujeme, že jsme přidali možnost, která vám umožní přizpůsobit sloupce na taskboardu. Teď můžete sloupce přidávat, odebírat, přejmenovávat a měnit jejich pořadí.

Pokud chcete nakonfigurovat sloupce na taskboardu, přejděte na Možnosti sloupce.

Tato funkce byla upřednostněna na základě návrhu z Developer Community.

Přepnutí zobrazení nebo skrytí dokončených podřízených pracovních položek v backlogu

Při upřesňování backlogu často chcete zobrazit jenom položky, které nebyly dokončeny. Teď máte možnost zobrazit nebo skrýt dokončené podřízené položky v backlogu.

Pokud je přepínač zapnutý, zobrazí se všechny podřízené položky v dokončeném stavu. Když je přepínač vypnutý, budou všechny podřízené položky v dokončeném stavu skryté v backlogu.

Nejnovější značky zobrazené při označování pracovní položky

Při označování pracovní položky teď možnost automatického dokončování zobrazí až pět naposledy použitých značek. To vám usnadní přidávání správných informací do pracovních položek.

Pravidla jen pro čtení a požadovaná pravidla pro členství ve skupinách

Pravidla pracovních položek umožňují nastavit konkrétní akce pro pole pracovních položek a automatizovat jejich chování. Můžete vytvořit pravidlo, které nastaví pole jen pro čtení nebo povinné na základě členství ve skupině. Můžete například vlastníkům produktů udělit možnost nastavit prioritu vašich funkcí a zároveň nastavit, aby byly jen pro čtení pro všechny ostatní.

Přizpůsobení hodnot systémového rozevíracího seznamu

Teď můžete přizpůsobit hodnoty pro libovolný rozevírací seznam systému (s výjimkou pole důvodu), například Závažnost, Aktivita, Priorita atd. Přizpůsobení rozevíracího seznamu je vymezeno tak, abyste mohli spravovat různé hodnoty pro stejné pole pro každý typ pracovní položky.

Nový parametr adresy URL pracovní položky

Odkazy na pracovní položky můžete sdílet s kontextem panelu nebo backlogu pomocí našeho nového parametru adresy URL pracovní položky. Teď můžete otevřít dialogové okno pracovní položky na panelu, backlogu nebo sprintu připojením parametru ?workitem=[ID] k adrese URL.

Každý, s kým odkaz sdílíte, se pak dostane se stejným kontextem, jako jste měli při sdílení odkazu!

Zmínka o osobách, pracovních položkách a žádosti o přijetí změn v textových polích

Když jsme si vyslechli vaši zpětnou vazbu, slyšeli jsme, že chcete, aby bylo možné v oblasti popisu pracovní položky (a dalších políCH HTML) u pracovní položky zmínit osoby, pracovní položky a žádosti o přijetí změn, a to nejen v komentářích. Někdy s někým spolupracujete na pracovní položce nebo chcete v popisu pracovní položky zvýraznit žádost o přijetí změn, ale neměli jste způsob, jak tyto informace přidat. Teď můžete osoby, pracovní položky a žádosti o přijetí změn zmínit ve všech dlouhých textových polích pracovní položky.

Příklad najdete tady.

• Pokud chcete použít zmínky o lidech, zadejte znaménko @ a jméno osoby, kterou chcete zmínit. @mentions v polích pracovních položek budou generovat e-mailová oznámení, jako co dělá pro komentáře.
• Pokud chcete použít zmínky o pracovní položce, zadejte znaménko # následované ID nebo nadpisem pracovní položky. #mentions vytvoří propojení mezi těmito dvěma pracovními položkami.
• Pokud chcete použít zmínky o žádosti o přijetí změn, přidejte ! a pak svoje ID nebo jméno žádosti o přijetí změn.

Reakce na komentáře k diskuzi

Jedním z našich hlavních cílů je zajistit, aby pracovní položky byly pro týmy pravděpodobnější. Nedávno jsme provedli hlasování na Twitteru , abychom zjistili, jaké funkce pro spolupráci chcete v diskuzích o pracovní položce. Připojování reakcí na komentáře vyhrálo hlasování, tak je přidáme! Tady jsou výsledky hlasování na Twitteru.

Můžete přidat reakce na libovolný komentář a existují dva způsoby, jak přidat své reakce – ikona smajlíku v pravém horním rohu libovolného komentáře a také v dolní části komentáře vedle existujících reakcí. Můžete přidat všech šest reakcí, pokud chcete, nebo jen jednu nebo dvě. Pokud chcete reakci odebrat, klikněte na reakci v dolní části komentáře a odebere se. Níže si můžete prohlédnout možnosti přidání reakce a také to, jak reakce vypadají v komentáři.

Připnutí Azure Boards sestav na řídicí panel

Do aktualizace Sprint 155 Jsme zahrnuli aktualizované verze sestav CFD a Velocity. Tyto sestavy jsou k dispozici na kartě Analýza v části Panely a backlogy. Teď můžete sestavy připnout přímo na řídicí panel. Pokud chcete sestavy připnout, najeďte myší na sestavu a vyberte tři tečky "... a kopírovat na řídicí panel.

Sledování průběhu nadřazených položek pomocí kumulativního backlogu na panelech

Souhrnné sloupce zobrazují indikátory průběhu nebo součty číselných polí nebo následných položek v hierarchii. Následné položky odpovídají všem podřízeným položkám v hierarchii. Do backlogu produktu nebo portfolia je možné přidat jeden nebo více souhrnných sloupců.

Tady například zobrazujeme průběh podle pracovních položek , které zobrazují indikátory průběhu pro vzestupné pracovní položky na základě procenta následných položek, které byly uzavřeny. Následné položky pro náměty zahrnují všechny podřízené funkce a jejich podřízené pracovní položky. Následné položky pro funkce zahrnují všechny podřízené uživatelské scénáře a jejich podřízené pracovní položky.

Živé aktualizace taskboardu

Když dojde ke změnám, panel úloh se teď automaticky aktualizuje. Když ostatní členové týmu přesunují nebo mění pořadí karet na hlavním panelu, panel se automaticky aktualizuje s těmito změnami. K zobrazení nejnovějších změn už nemusíte stisknout klávesu F5.

Podpora vlastních polí ve sloupcích souhrnů

Souhrn je teď možné provést u libovolného pole, včetně vlastních polí. I když přidáváte sloupec Souhrn, můžete vybrat sloupec Souhrn ze seznamu Rychlý, ale pokud chcete provést souhrn s číselnými poli, která nejsou součástí šablony předostavěného procesu, můžete nakonfigurovat vlastní podle následujícího postupu:

1. V backlogu klikněte na Možnosti sloupce. Potom na panelu klikněte na Přidat sloupec souhrnu a nakonfigurujte vlastní kumulativní aktualizaci.

   

2. Vyberte mezi indikátorem průběhu a součtem.
3. Vyberte typ pracovní položky nebo úroveň backlogu (obvykle backlogy agregují několik typů pracovních položek).
4. Vyberte typ agregace. Počet pracovních položek nebo součet. V poli Součet budete muset vybrat pole, které chcete sumarizovat.
5. Tlačítko OK vás vrátí na panel možností sloupce, kde můžete změnit pořadí nového vlastního sloupce.

Všimněte si, že po kliknutí na OK nemůžete vlastní sloupec upravit. Pokud potřebujete provést změnu, odeberte vlastní sloupec a podle potřeby přidejte další.

Nové pravidlo pro skrytí polí ve formuláři pracovní položky na základě podmínky

Do modulu zděděných pravidel jsme přidali nové pravidlo, které umožňuje skrýt pole ve formuláři pracovní položky. Toto pravidlo skryje pole na základě členství ve skupině uživatelů. Pokud například uživatel patří do skupiny vlastníka produktu, můžete skrýt pole specifické pro vývojáře. Další podrobnosti najdete v dokumentaci tady.

Vlastní nastavení oznámení o pracovní položce

Udržování přehledu o pracovních položkách, které jsou pro vás nebo váš tým relevantní, je neuvěřitelně důležité. Pomáhá týmům spolupracovat a udržet si přehled o projektech a zajišťuje zapojení všech správných stran. Různé zúčastněné strany však mají různé úrovně investic do různých úsilí a domníváme se, že by se to mělo odrážet ve vaší schopnosti sledovat stav pracovní položky.

Pokud jste dříve chtěli sledovat pracovní položku a dostávat oznámení o provedených změnách, dostávali byste e-mailová oznámení o všech změnách provedených v pracovní položce. Po zvážení vaší zpětné vazby děláme sledování pracovní položky flexibilnější pro všechny zúčastněné strany. Teď uvidíte nové tlačítko nastavení vedle tlačítka Sledovat v pravém horním rohu pracovní položky. Tím přejdete do automaticky otevírané okno, které vám umožní nakonfigurovat následující možnosti.

V nastavení oznámení si můžete vybrat ze tří možností oznámení. Nejprve se můžete úplně odhlásit. Za druhé se můžete plně přihlásit k odběru, kde budete dostávat oznámení o všech změnách pracovních položek. Nakonec se můžete rozhodnout dostávat oznámení o některých hlavních a zásadních událostech změn pracovních položek. Můžete vybrat jenom jednu nebo všechny tři možnosti. Členové týmu tak budou moct sledovat pracovní položky na vyšší úrovni a nebudou rozptylováni každou změnou, která se provede. Díky této funkci eliminujeme nepotřebné e-maily a umožníme vám zaměřit se na klíčové úkoly, které máte k dispozici.

Propojení pracovních položek s nasazeními

S radostí vydáváme řízení nasazení ve formuláři pracovní položky. Tento ovládací prvek prováže pracovní položky s vydanou verzí a umožňuje snadno sledovat, kde byla pracovní položka nasazena. Další informace najdete v dokumentaci tady.

Import pracovních položek ze souboru CSV

Až dosud byl import pracovních položek ze souboru CSV závislý na použití modulu plug-in Excelu. V této aktualizaci poskytujeme prostředí pro import první třídy přímo z Azure Boards, abyste mohli importovat nové nebo aktualizovat stávající pracovní položky. Další informace najdete v dokumentaci tady.

Přidání nadřazeného pole na karty pracovních položek

Nadřazený kontext je teď k dispozici na panelu Kanban jako nové pole pro karty pracovních položek. Teď můžete na karty přidat pole Nadřazený, abyste nemuseli používat alternativní řešení, jako jsou značky a předpony.

Přidání nadřazeného pole do backlogu a dotazů

Nadřazené pole je teď k dispozici při prohlížení backlogů a výsledků dotazů. Pokud chcete přidat nadřazené pole, použijte zobrazení Možnosti sloupce .

Repos

Metriky pokrytí kódu a zásady větve pro žádosti o přijetí změn

Teď můžete zobrazit metriky pokrytí kódu pro změny v zobrazení žádosti o přijetí změn. Tím zajistíte, že jste změny odpovídajícím způsobem otestovali prostřednictvím automatizovaných testů. Stav pokrytí se zobrazí jako komentář v přehledu žádosti o přijetí změn. Můžete zobrazit podrobnosti informací o pokrytí pro každý řádek kódu, který se změní v zobrazení rozdílu souboru.

Vlastníci úložiště teď navíc můžou nastavit zásady pokrytí kódu a zabránit tomu, aby se velké neotestované změny sloučily do větve. Požadované prahové hodnoty pokrytí lze definovat v azurepipelines-coverage.yml souboru nastavení, který je vrácený se změnami v kořenovém adresáři úložiště, a zásady pokrytí lze definovat pomocí existující konfigurace zásad větve pro další funkce služeb v Azure Repos.

Filtrování oznámení komentářů z žádostí o přijetí změn

Komentáře v žádostech o přijetí změn můžou často generovat velké množství šumu kvůli oznámením. Přidali jsme vlastní předplatné, které vám umožňuje filtrovat, která oznámení o komentářích se přihlásíte k odběru podle věku komentáře, komentátora, odstraněného komentáře, uvedených uživatelů, autora žádosti o přijetí změn, cílové větve a účastníků vlákna. Tato odběry oznámení můžete vytvořit kliknutím na ikonu uživatele v pravém horním rohu a přechodem na Nastavení uživatele.

Zachytávejte služby pro komentáře žádostí o přijetí změn

Teď můžete vytvořit připojení služby pro komentáře v žádosti o přijetí změn na základě úložiště a cílové větve.

Zásady blokování souborů se zadanými vzory

Správci teď můžou nastavit zásadu, která zabrání odesílání potvrzení do úložiště na základě typů souborů a cest. Zásady ověření názvu souboru budou blokovat nabízená oznámení, která odpovídají zadanému vzoru.

Řešení pracovních položek pomocí potvrzení pomocí klíčových slov

Pracovní položky teď můžete vyřešit pomocí potvrzení provedeného ve výchozí větvi pomocí klíčových slov, jako je oprava, opravy nebo oprava. Můžete například napsat, že "tato změna opravena #476" ve zprávě o potvrzení a pracovní položka #476 bude dokončena, když se potvrzení vloží nebo sloučí do výchozí větve. Další podrobnosti najdete v této dokumentaci.

Členitost pro automatické revidující

Dříve se při přidávání kontrolorů na úrovni skupiny do žádosti o přijetí změn vyžadovalo jenom jedno schválení ze skupiny, která byla přidána. Teď můžete nastavit zásady, které při přidávání automatických kontrolorů vyžadují, aby žádost o přijetí změn schválilo více než jeden revidující z týmu. Kromě toho můžete přidat zásadu, která zabrání žadateli schvalovat vlastní změny.

Použití ověřování na základě účtu služby pro připojení k AKS

Dříve jsme při konfiguraci Služby Azure Pipelines z centra nasazení AKS použili připojení Azure Resource Manager. Toto připojení mělo přístup k celému clusteru, nejen k oboru názvů, pro který byl kanál nakonfigurovaný. S touto aktualizací budou naše kanály používat ověřování pomocí účtu služby pro připojení ke clusteru, aby měl přístup pouze k oboru názvů přidruženému ke kanálu.

Náhled souborů Markdownu v žádosti o přijetí změn vedle sebe

Pomocí nového tlačítka Náhled se teď můžete podívat na náhled toho, jak bude soubor Markdownu vypadat. Kromě toho můžete zobrazit úplný obsah souboru z rozdílu vedle sebe tak, že vyberete tlačítko Zobrazit .

Vypršení platnosti zásad sestavení pro ruční sestavení

Zásady vynucuje standardy správy změn a kvality kódu vašeho týmu. Dříve jste mohli nastavit zásady vypršení platnosti buildu pro automatizovaná sestavení. Zásady vypršení platnosti sestavení teď můžete nastavit i pro ruční sestavení.

Přidání zásady pro blokování potvrzení na základě e-mailu autora potvrzení

Správci teď můžou nastavit zásady nabízených oznámení, které zabrání vložení potvrzení do úložiště, pro které e-mail autora potvrzení neodpovídá zadanému vzoru.

Tato funkce byla upřednostněna na základě návrhu od Developer Community pro zajištění podobného prostředí. Dál zůstane lístek otevřený a doporučíme uživatelům, aby nám řekli, jaké další typy zásad nabízení změn byste chtěli vidět.

Označení souborů jako zkontrolovaných v žádosti o přijetí změn

Někdy potřebujete zkontrolovat žádosti o přijetí změn, které obsahují změny velkého počtu souborů, a může být obtížné sledovat, které soubory jste už zkontrolovali. Teď můžete soubory označit jako zkontrolované v žádosti o přijetí změn.

Soubor můžete označit jako zkontrolovaný pomocí rozevírací nabídky vedle názvu souboru nebo tak, že na název souboru narazíte myší a kliknete na jeho název.

Poznámka

Tato funkce slouží jenom ke sledování průběhu při kontrole žádosti o přijetí změn. Nepředstavuje hlasování o žádostech o přijetí změn, takže tyto značky budou viditelné pouze revidujícímu.

Tato funkce byla upřednostněna na základě návrhu z Developer Community.

Nové webové uživatelské rozhraní pro Azure Repos cílové stránky

Nyní můžete vyzkoušet naše nové moderní, rychlé a mobilní cílové stránky v rámci Azure Repos. Tyto stránky jsou k dispozici jako cílové stránky nových úložišť. Cílové stránky zahrnují všechny stránky s výjimkou podrobností o žádosti o přijetí změn, podrobností potvrzení a porovnání větví.

Web

Mobilní

Správa zásad větve mezi úložišti

Zásady větví jsou jednou z výkonných funkcí Azure Repos, které pomáhají chránit důležité větve. I když v rozhraní REST API existuje možnost nastavit zásady na úrovni projektu, nebylo pro ni k dispozici žádné uživatelské rozhraní. Teď můžou správci nastavit zásady pro konkrétní větev nebo výchozí větev ve všech úložištích ve svém projektu. Správce může například vyžadovat dva minimální revidující pro všechny žádosti o přijetí změn provedené v každé hlavní větvi ve všech úložištích v projektu. Funkci Přidat ochranu větví najdete v nastavení projektu Repos.

Nové cílové stránky převodu webové platformy

Aktualizovali jsme uživatelské prostředí cílových stránek Repos tak, aby byly moderní, rychlé a přívětivé pro mobilní zařízení. Tady jsou dva příklady stránek, které byly aktualizovány. Další stránky budeme aktualizovat i v budoucích aktualizacích.

Webové prostředí:

Mobilní prostředí:

Podpora jazyka Kotlin

S radostí oznamujeme, že teď podporujeme zvýrazňování jazyka Kotlin v editoru souborů. Zvýraznění zlepší čitelnost textového souboru Kotlin a pomůže vám rychle najít chyby. Tuto funkci jsme upřednostnili na základě návrhu z Developer Community.

Vlastní odběr oznámení pro koncepty žádostí o přijetí změn

Pokud chcete snížit počet e-mailových oznámení ze žádostí o přijetí změn, můžete teď vytvořit vlastní odběr oznámení pro žádosti o přijetí změn, které se vytvářejí nebo aktualizují ve stavu konceptu. Můžete dostávat e-maily určené speciálně pro koncepty žádostí o přijetí změn nebo odfiltrovat e-maily z konceptů žádostí o přijetí změn, aby váš tým nedostal oznámení, než bude žádost o přijetí změn připravená ke kontrole.

Vylepšená akceschopnost žádostí o přijetí změn

Pokud potřebujete zkontrolovat mnoho žádostí o přijetí změn, může být obtížné pochopit, kde byste měli provést akci jako první. Pokud chcete zlepšit použitelnost žádostí o přijetí změn, můžete teď na stránce seznamu žádostí o přijetí změn vytvořit několik vlastních dotazů s několika novými možnostmi filtrování, například podle stavu konceptu. Tyto dotazy vytvoří na stránce žádosti o přijetí změn samostatné a sbalitelné oddíly, a to kromě položek "Vytvořeno mnou" a "Přiřazeno mně". Můžete také odmítnout revizi žádosti o přijetí změn, do které jste byli přidáni, prostřednictvím nabídky Hlas nebo místní nabídky na stránce seznamu žádostí o přijetí změn. Ve vlastních oddílech se teď zobrazí samostatné karty pro žádosti o přijetí změn, které jste zadali ke kontrole nebo které jste odmítli zkontrolovat. Tyto vlastní dotazy budou fungovat napříč úložišti na kartě Moje žádosti o přijetí změn na domovské stránce kolekce. Pokud se chcete vrátit k žádosti o přijetí změn, můžete ji označit příznakem a zobrazí se v horní části vašeho seznamu. Nakonec žádosti o přijetí změn, u kterých je nastavené automatické dokončování, budou v seznamu označeny pilulkou s textem Automatické dokončování.

Pipelines

Kanály s více fázemi

Pracujeme na aktualizovaném uživatelském prostředí pro správu vašich kanálů. Díky těmto aktualizacím jsou prostředí kanálů moderní a konzistentní se směrem Azure DevOps. Tyto aktualizace navíc spojují klasické kanály buildu a kanály YAML s více fázemi do jednoho prostředí. Je vhodný pro mobilní zařízení a přináší různá vylepšení správy kanálů. Můžete přejít k podrobnostem a zobrazit podrobnosti o kanálu, podrobnosti o spuštění, analýzu kanálu, podrobnosti o úlohách, protokoly a další.

V novém prostředí jsou zahrnuty následující funkce:

• zobrazení a správa více fází
• schvalování spuštění kanálu
• posouvání úplně zpět v protokolech, zatímco kanál stále probíhá
• stav kanálu podle jednotlivých větví.

Průběžné nasazování v YAML

S radostí vám oznamujeme, že pro Azure Pipelines můžeme poskytovat funkce YAML CD. Nyní nabízíme jednotné prostředí YAML, abyste mohli nakonfigurovat všechny kanály tak, aby společně provedly CI, CD nebo CI a CD. Funkce YAML CD zavádí několik nových pokročilých funkcí, které jsou dostupné pro všechny kolekce s vícefázovými kanály YAML. Mezi nejzajímavější z nich patří:

• Kanály YAML s více fázemi (pro CI a CD)
• Schválení a kontroly prostředků
• Prostředí a strategie nasazení
• Prostředky Kubernetes a virtuálních počítačů v prostředí
• Kontrola spolupráce v aplikacích
• Aktualizované uživatelské prostředí pro připojení služeb
• Prostředky v kanálech YAML

Pokud jste připraveni začít sestavovat, projděte si dokumentaci nebo blog věnovaný vytváření kanálů CI/CD s více fázemi.

Správa proměnných kanálu v editoru YAML

Aktualizovali jsme prostředí pro správu proměnných kanálu v editoru YAML. Pokud chcete přidat nebo aktualizovat proměnné v kanálech YAML, nemusíte už přecházet do klasického editoru.

Schválení vydaných verzí přímo z centra Releases

Zpracování čekajících schválení bylo jednodušší. Dříve bylo možné verzi schválit na stránce s podrobnostmi o vydané verzi. Teď můžete schvalovat vydané verze přímo z centra Vydané verze.

Vylepšení v začátcích s kanály

Běžným dotazem průvodce Začínáme je možnost přejmenovat vygenerovaný soubor. V současné době je vrácená se změnami jako azure-pipelines.yml v kořenovém adresáři vašeho úložiště. Před uložením kanálu teď můžete soubor aktualizovat na jiný název nebo umístění.

Nakonec budeme mít větší kontrolu nad vrácením azure-pipelines.yml souboru do jiné větve, protože můžete přeskočit vytváření žádosti o přijetí změn z této větve.

Náhled plně analyzovaného dokumentu YAML bez potvrzení nebo spuštění kanálu

Přidali jsme verzi Preview, ale ne režim spouštění pro kanály YAML. Teď můžete vyzkoušet kanál YAML, aniž byste ho museli zadávat do úložiště nebo ho spouštět. Vzhledem k existujícímu kanálu a volitelné nové datové části YAML vám toto nové rozhraní API vrátí úplný kanál YAML. V budoucích aktualizacích bude toto rozhraní API použito v nové funkci editoru.

Pro vývojáře: POST to dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview s textem JSON, jako je tento:

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

Odpověď bude obsahovat vykreslený YAML.

Plány Cron v YAML

Dříve jste mohli pomocí editoru uživatelského rozhraní určit naplánovanou aktivační událost pro kanály YAML. V této verzi můžete plánovat sestavení pomocí syntaxe cron v souboru YAML a využívat následující výhody:

1. Konfigurace jako kód: Jako součást kódu můžete sledovat plány spolu s kanálem.
2. Expresivní: Při definování plánů máte výraznější sílu, než jakou jste byli schopni v uživatelském rozhraní. Například je jednodušší zadat jeden plán, který spustí spuštění každou hodinu.
3. Oborový standard: Mnoho vývojářů a správců už syntaxi cron zná.

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

Také jsme vám usnadnili diagnostiku problémů s plány Cron. Naplánovaná spuštění v nabídce Spustit kanál zobrazí náhled několika nadcházejících naplánovaných spuštění pro váš kanál, který vám pomůže diagnostikovat chyby v plánech Cron.

Aktualizace do uživatelského rozhraní připojení služeb

Pracujeme na aktualizovaném uživatelském prostředí pro správu připojení vašich služeb. Díky těmto aktualizacím je prostředí připojení služby moderní a konzistentní se směrem Azure DevOps. Začátkem tohoto roku jsme představili nové uživatelské rozhraní pro připojení služeb jako funkci Preview. Děkujeme všem, kteří vyzkoušeli nové prostředí a poskytli nám svoji cennou zpětnou vazbu.

Spolu s aktualizací uživatelského prostředí jsme také přidali dvě možnosti, které jsou důležité pro využívání připojení služeb v kanálech YAML: autorizaci kanálů a schvalování a kontroly.

Nové uživatelské prostředí bude ve výchozím nastavení s touto aktualizací zapnuté. I nadále budete mít možnost vyjádřit výslovný nesouhlas s verzí Preview.

Poznámka

Meziprojektové sdílení Connections služeb plánujeme zavést jako novou funkci. Další podrobnosti o prostředí pro sdílení a rolích zabezpečení najdete tady.

Přeskočení fází v kanálu YAML

Když spustíte ruční spuštění, můžete někdy chtít přeskočit několik fází v kanálu. Například pokud nechcete nasadit do produkčního prostředí nebo pokud chcete přeskočit nasazení do několika prostředí v produkčním prostředí. Teď k tomu můžete použít kanály YAML.

Aktualizovaný panel kanálu spuštění obsahuje seznam fází ze souboru YAML a máte možnost jednu nebo více těchto fází přeskočit. Při přeskakování fází je nutné postupovat opatrně. Pokud například vaše první fáze vytváří určité artefakty, které jsou potřeba pro následující fáze, neměli byste první fázi přeskočit. Panel spuštění zobrazí obecné upozornění, kdykoli přeskočíte fáze, které mají podřízené závislosti. Je na vás, zda jsou tyto závislosti skutečnými závislostmi artefaktů, nebo zda jsou přítomny pouze pro sekvencování nasazení.

Přeskočení fáze je ekvivalentem opětovného zobrazení závislostí mezi fázemi. Všechny přímé podřízené závislosti vynechané fáze závisí na nadřazeném nadřazeném objektu vynechané fáze. Pokud se spuštění nezdaří a pokusíte se znovu spustit neúspěšnou fázi, bude mít tento pokus stejné přeskočení. Pokud chcete změnit, které fáze se přeskočí, musíte spustit nové spuštění.

Nové uživatelské rozhraní připojení služeb jako výchozí prostředí

K dispozici je nové uživatelské rozhraní připojení služeb. Toto nové uživatelské rozhraní je postavené na moderních standardech návrhu a dodává se s různými důležitými funkcemi pro podporu vícefázových kanálů YAML CD, jako jsou schvalování, autorizace a sdílení mezi projekty.

Další informace o připojeních služeb najdete tady.

Výběr verze prostředku kanálu v dialogovém okně pro vytvoření spuštění

V dialogovém okně pro vytvoření spuštění jsme přidali možnost ručního převzetí verzí prostředků kanálu. Pokud kanál využíváte jako prostředek v jiném kanálu, můžete teď při vytváření spuštění vybrat verzi tohoto kanálu.

az Vylepšení rozhraní příkazového řádku pro Azure Pipelines

Příkazy pro správu skupin proměnných kanálu a proměnných

Přenos kanálů založených na YAML z jednoho projektu do jiného může být náročný, protože potřebujete ručně nastavit proměnné kanálu a skupiny proměnných. Pomocí skupiny proměnných kanálu a příkazů pro správu proměnných teď ale můžete nastavení a správu proměnných kanálu a skupin proměnných skriptovat, což vám umožní snadno sdílet pokyny k přesunu a nastavení kanálů z jednoho projektu do druhého.

Spuštění kanálu pro větev PR

Při vytváření žádosti o přijetí změn může být obtížné ověřit, jestli změny můžou narušit spuštění kanálu v cílové větvi. Díky možnosti aktivovat spuštění kanálu nebo zařadit sestavení do fronty pro větev ŽÁDOSTI o přijetí změn teď můžete ověřit a vizualizovat probíhající změny spuštěním v cílovém kanálu. Další informace najdete v dokumentaci k příkazům az pipelines run a az pipelines build queue .

Přeskočení prvního spuštění kanálu

Při vytváření kanálů někdy chcete vytvořit a potvrdit soubor YAML a neaktivovat spuštění kanálu, protože to může mít za následek chybné spuštění z různých důvodů – infrastruktura není připravená nebo potřebuje vytvářet a aktualizovat skupiny proměnných nebo proměnných atd. Pomocí Azure DevOps CLI teď můžete přeskočit první automatizované spuštění kanálu při vytváření kanálu zahrnutím parametru --skip-first-run. Další informace najdete v dokumentaci k příkazu az pipeline create .

Vylepšení příkazu koncového bodu služby

Příkazy rozhraní příkazového řádku koncového bodu služby podporovaly pouze nastavení a správu koncových bodů služby Azure RM a GitHub. V této verzi ale příkazy koncového bodu služby umožňují vytvořit libovolný koncový bod služby poskytnutím konfigurace prostřednictvím souboru a poskytují optimalizované příkazy – az devops service-endpoint github a az devops service-endpoint azurerm, které poskytují prvotřídní podporu pro vytváření koncových bodů služby těchto typů. Další informace najdete v dokumentaci k příkazům .

Úlohy nasazení

Úloha nasazení je speciální typ úlohy , která se používá k nasazení aplikace do prostředí. V této aktualizaci jsme přidali podporu odkazů na krok v úloze nasazení. Můžete například definovat sadu kroků v jednom souboru a odkazovat na ni v úloze nasazení.

Do úlohy nasazení jsme také přidali podporu dalších vlastností. Tady je například několik vlastností úlohy nasazení, které teď můžete nastavit.

• timeoutInMinutes – doba spuštění úlohy před automatickým zrušením.
• cancelTimeoutInMinutes – kolik času se má před ukončením úkolů spustit vždy, i když byly zrušeny.
• condition – podmíněné spuštění úlohy
• proměnné – pevně zakódované hodnoty je možné přidat přímo nebo můžete odkazovat na skupiny proměnných, na skupinu proměnných zálohovanou službou Azure Key Vault nebo můžete odkazovat na sadu proměnných definovaných v souboru.
• continueOnError – jestli by se budoucí úlohy měly spustit i v případě, že tato úloha nasazení selže; výchozí hodnota je false.

Další podrobnosti o úlohách nasazení a úplnou syntaxi pro určení úlohy nasazení najdete v tématu Úloha nasazení.

Zobrazení informací o přidružených kanálech CD v kanálech CI

Přidali jsme podporu pro podrobnosti o kanálech CD YAML, kde se kanály CI označují jako prostředky kanálu. V zobrazení spuštění kanálu CI teď uvidíte novou kartu Přidružené kanály, kde najdete všechna spuštění kanálu, která využívají váš kanál, a artefakty z něj.

Podpora balíčků GitHubu v kanálech YAML

Nedávno jsme zavedli nový typ prostředku s názvem packages , který přidává podporu využívání balíčků NuGet a npm z GitHubu jako prostředku v kanálech YAML. Jako součást tohoto prostředku teď můžete zadat typ balíčku (NuGet nebo npm), který chcete využívat z GitHubu. Automatické triggery kanálu můžete povolit také při vydání nové verze balíčku. V současné chvíli je podpora k dispozici pouze pro využívání balíčků z GitHubu, ale v budoucnu plánujeme rozšířit podporu pro využívání balíčků z jiných úložišť balíčků, jako jsou NuGet, npm, AzureArtifacts a mnoho dalších. Podrobnosti najdete v následujícím příkladu:

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

Poznámka

Balíčky GitHubu v současnosti podporují pouze ověřování na základě tokenu PAT, což znamená, že připojení služby GitHub v prostředku balíčku by mělo být typu PAT. Jakmile toto omezení zrušíte, poskytneme podporu pro jiné typy ověřování.

Ve výchozím nastavení se balíčky ve vašich úlohách automaticky nestáhnou, proto jsme zavedli makro getPackage , které umožňuje využívat balíček definovaný v prostředku. Podrobnosti najdete v následujícím příkladu:

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

Azure Kubernetes Service propojení clusteru v zobrazení prostředků prostředí Kubernetes

Přidali jsme odkaz na zobrazení prostředků prostředí Kubernetes, abyste mohli přejít do okna Azure pro příslušný cluster. To platí pro prostředí, která jsou mapována na obory názvů v clusterech Azure Kubernetes Service.

Filtry složek vydaných verzí v odběrech oznámení

Složky umožňují uspořádat kanály pro snadnější zjistitelnost a kontrolu zabezpečení. Často můžete chtít nakonfigurovat vlastní e-mailová oznámení pro všechny kanály verze, které jsou reprezentované všemi kanály ve složce. Dříve jste museli nakonfigurovat několik odběrů nebo mít v odběrech složité dotazy, abyste získali prioritní e-maily. Díky této aktualizaci teď můžete do dokončeného nasazení a událostí čekajících na schválení přidat klauzuli o složce vydaných verzí a zjednodušit odběry.

Propojení pracovních položek s vícefázovými kanály YAML

V současné době můžete pracovní položky automaticky propojit s klasickými sestaveními. To však nebylo možné s kanály YAML. Touto aktualizací jsme tuto mezeru vyřešili. Když úspěšně spustíte kanál pomocí kódu ze zadané větve, Azure Pipelines automaticky přidruží spuštění ke všem pracovním položkám (které se odvozují prostřednictvím potvrzení v daném kódu). Když otevřete pracovní položku, uvidíte spuštění, ve kterých byl kód pro tuto pracovní položku sestaven. Ke konfiguraci použijte panel nastavení kanálu.

Zrušení fáze při spuštění kanálu YAML s více fázemi

Při spouštění vícefázového kanálu YAML teď můžete zrušit provádění fáze, zatímco probíhá. To je užitečné, pokud víte, že fáze selže, nebo pokud máte další spuštění, které chcete spustit.

Opakování neúspěšných fází

Jednou z nejžádanějších funkcí ve vícefázových kanálech je možnost opakovat neúspěšnou fázi bez nutnosti začínat od začátku. S touto aktualizací přidáváme velkou část této funkce.

Když se spuštění nezdaří, můžete teď zkusit fázi kanálu zopakovat. Všechny úlohy, které selhaly při prvním pokusu, a úlohy, které na nich přechodně závisejí, se znovu pokusí.

Můžete tak ušetřit čas několika způsoby. Pokud například ve fázi spouštíte více úloh, můžete chtít, aby každá fáze spouštěla testy na jiné platformě. Pokud testy na jedné platformě selžou, zatímco ostatní projdou, můžete ušetřit čas tím, že znovu nespusíte úspěšné úlohy. Dalším příkladem může být selhání fáze nasazení kvůli nespolehlivému síťovému připojení. Opakováním této fáze ušetříte čas, protože nebudete muset vytvářet další sestavení.

Tato funkce obsahuje několik známých mezer. Nemůžete například opakovat fázi, kterou explicitně zrušíte. Pracujeme na tom, abychom tyto mezery v budoucích aktualizacích odstranili.

Schválení ve vícefázových kanálech YAML

Kanály YAML CD můžou obsahovat ruční schválení. Vlastníci infrastruktury můžou chránit svá prostředí a požádat o ruční schválení před tím, než se do nich nasadí fáze kanálu. Díky úplnému oddělení rolí mezi vlastníky infrastruktury (prostředí) a aplikace (kanálu) zajistíte ruční odhlášení pro nasazení v konkrétním kanálu a získáte centrální kontrolu při provádění stejných kontrol napříč všemi nasazeními do prostředí.

Spuštění kanálu nasazení do vývojového prostředí se zastaví ke schválení na začátku fáze.

Zvýšení limitu časového limitu a četnosti bran

Dříve byl limit časového limitu brány v kanálech verze tři dny. S touto aktualizací se časový limit zvýšil na 15 dnů , aby byly povoleny brány s delší dobou trvání. Také jsme zvýšili frekvenci brány na 30 minut.

Nová šablona image sestavení pro Dockerfile

Dříve se při vytváření nového kanálu pro dockerfile při vytváření nového kanálu doporučuje šablona nasdílení image do Azure Container Registry a nasazení do Azure Kubernetes Service. Přidali jsme novou šablonu, která vám umožní vytvořit image pomocí agenta, aniž byste museli odesílat změny do registru kontejneru.

Nová úloha konfigurace nastavení aplikace Azure App Service

Azure App Service umožňuje konfiguraci prostřednictvím různých nastavení, jako jsou nastavení aplikace, připojovací řetězce a další obecná nastavení konfigurace. Teď máme novou úlohu Azure Pipelines Azure App Service Nastavení, která podporuje hromadnou konfiguraci těchto nastavení pomocí syntaxe JSON ve webové aplikaci nebo v libovolném z jejích slotů nasazení. Tuto úlohu je možné použít společně s dalšími úlohami služby App Service k nasazení, správě a konfiguraci webových aplikací, aplikací funkcí nebo jiných kontejnerizovaných služeb App Services.

Azure App Service teď podporuje prohození s verzí Preview.

Azure App Service teď ve svých slotech nasazení podporuje prohození s verzí Preview. Je to dobrý způsob, jak ověřit aplikaci s produkční konfigurací ještě před tím, než se aplikace skutečně prohodí z přípravného slotu do produkčního slotu. Tím by se také zajistilo, že u cílového/produkčního slotu nedojde k výpadku.

Azure App Service úloha teď podporuje toto vícefázové prohození prostřednictvím následujících nových akcí:

• Zahájit prohození s verzí Preview – Zahájí prohození s verzí Preview (vícefázové prohození) a použije konfiguraci cílového slotu (například produkčního slotu) na zdrojový slot.
• Dokončit prohození s náhledem – Až budete připraveni dokončit nevyřízené prohození, vyberte akci Dokončit prohození s náhledem.
• Zrušit prohození s verzí Preview – Pokud chcete zrušit nevyřízené prohození, vyberte Zrušit prohození s verzí Preview.

Filtr na úrovni fáze pro artefakty Azure Container Registry a Docker Hub

Dříve byly filtry regulárních výrazů pro artefakty Azure Container Registry a Docker Hub k dispozici pouze na úrovni kanálu verze. Nyní byly přidány také na úrovni fáze.

Vylepšení schvalování v kanálech YAML

Povolili jsme konfiguraci schválení pro připojení služeb a fondy agentů. U schvalování postupujeme podle oddělení rolí mezi vlastníky infrastruktury a vývojáři. Konfigurací schválení prostředků, jako jsou prostředí, připojení služeb a fondy agentů, budete mít jistotu, že všechna spuštění kanálu, která používají prostředky, budou nejprve vyžadovat schválení.

Prostředí je podobné konfiguraci schvalování pro prostředí. Pokud čeká na schválení prostředku, na který se odkazuje ve fázi, spuštění kanálu počká na ruční schválení kanálu.

Podpora testování struktury kontejnerů ve službě Azure Pipelines

Využití kontejnerů v aplikacích se zvyšuje, a proto je potřeba robustního testování a ověřování. Azure Pipelines teď nabízí podporu pro testy struktury kontejneru. Tato architektura poskytuje pohodlný a výkonný způsob, jak ověřit obsah a strukturu kontejnerů.

Strukturu obrázku můžete ověřit na základě čtyř kategorií testů, které lze spustit společně: testy příkazů, testy existence souborů, testy obsahu souborů a testy metadat. Výsledky v kanálu můžete použít k rozhodování o tom, jak je jít/nechodí. Testovací data jsou k dispozici při spuštění kanálu s chybovou zprávou, která vám pomůže lépe řešit chyby.

Zadejte podrobnosti o konfiguračním souboru a imagi.

Testování dat a souhrnu

Dekorátory kanálů pro kanály verze

Dekorátory kanálů umožňují přidávání kroků na začátek a konec každé úlohy. To se liší od přidání kroků do jedné definice, protože to platí pro všechny kanály v kolekci.

Podporujeme dekorátory pro buildy a kanály YAML, přičemž zákazníci je používají k centrálnímu řízení kroků ve svých úlohách. Teď rozšiřujeme podporu také na kanály verzí. Můžete vytvořit rozšíření, která budou přidávat kroky, které cílí na nový bod příspěvku, a tato rozšíření se přidají do všech úloh agentů v kanálech verze.

Nasazení Azure Resource Manager (ARM) na úrovni předplatného a skupiny pro správu

Dříve jsme podporovali nasazení pouze na úrovni skupiny prostředků. V této aktualizaci jsme přidali podporu nasazení šablon ARM na úrovni předplatného i skupiny pro správu. To vám pomůže při společném nasazování sady prostředků, ale jejich umístění do různých skupin prostředků nebo předplatných. Například nasazení zálohovacího virtuálního počítače pro Azure Site Recovery do samostatné skupiny prostředků a umístění.

Možnosti CD pro vícefázové kanály YAML

Teď můžete využívat artefakty publikované kanálem CI a povolit triggery dokončení kanálu. Ve vícefázových kanálech YAML představujeme pipelines jako prostředek. V YAML teď můžete odkazovat na jiný kanál a také povolit triggery CD.

Tady je podrobné schéma YAML pro prostředek kanálů.

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/*  

Kromě toho můžete pomocí - download úlohy stáhnout artefakty publikované prostředkem kanálu.

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

Další podrobnosti najdete v dokumentaci ke stažení artefaktů tady.

Orchestrace strategie nasazení kanárů v prostředí pro Kubernetes

Jednou z klíčových výhod průběžného doručování aktualizací aplikací je možnost rychlého nabízení aktualizací do produkčního prostředí pro konkrétní mikroslužby. Získáte tak možnost rychle reagovat na změny v obchodních požadavcích. Prostředí bylo představeno jako prvotřídní koncept, který umožňuje orchestraci strategií nasazení a usnadňuje vydávání verzí s nulovými výpadky. Dříve jsme podporovali strategii runOnce , která prováděla kroky jednou postupně. Díky podpoře kanárkové strategie ve vícefázových kanálech teď můžete snížit riziko pomalým zaváděním změny na malou podmnožinu. Jakmile získáte větší důvěru v novou verzi, můžete ji začít zavádět pro více serverů ve vaší infrastruktuře a směrovat na ni více uživatelů.

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

Kanárská strategie pro Kuberenetes nejprve nasadí změny s 10 % podů následovaných 20 % při monitorování stavu během postRouteTraffic. Pokud vše půjde dobře, zvýší se na 100 %.

Hledáme včasnou zpětnou vazbu k podpoře prostředků virtuálních počítačů v prostředích a provádění strategie postupného nasazení na více počítačích. Pokud se chcete zaregistrovat, kontaktujte nás.

Zásady schvalování pro kanály YAML

V kanálech YAML postupujeme podle konfigurace schvalování řízené vlastníkem prostředku. Vlastníci prostředků konfigurují schválení pro prostředek a všechny kanály, které používají pozastavení prostředku ke schválení před zahájením fáze využívající prostředek. Vlastníci aplikací založených na SOX běžně omezují žadatele o nasazení ve schvalování vlastních nasazení.

Pomocí rozšířených možností schválení teď můžete nakonfigurovat zásady schválení, jako je například to, že žadatel by neměl schvalovat, vyžadovat schválení od podmnožina uživatelů a vypršení časového limitu schválení.

ACR jako prostředek kanálu první třídy

Pokud potřebujete využít image kontejneru publikovanou do ACR (Azure Container Registry) jako součást kanálu a aktivovat kanál pokaždé, když se publikuje nová image, můžete použít prostředek kontejneru ACR.

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

K metadatům image ACR je navíc možné přistupovat pomocí předdefinovaných proměnných. Následující seznam obsahuje proměnné ACR, které jsou k dispozici pro definování prostředku kontejneru ACR ve vašem kanálu.

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

Vylepšení zásad pro vyhodnocení kontrol artefaktů v kanálech

Vylepšili jsme kontrolu artefaktů vyhodnocení , abychom usnadnili přidávání zásad ze seznamu předpřipočtových definic zásad. Definice zásady se vygeneruje automaticky a přidá se do konfigurace kontroly , kterou je možné v případě potřeby aktualizovat.

Podpora výstupních proměnných v úloze nasazení

Výstupní proměnné teď můžete definovat v hookech životního cyklu úloh nasazení a využívat je v dalších podřízených krocích a úlohách ve stejné fázi.

Při provádění strategií nasazení můžete přistupovat k výstupním proměnným napříč úlohami pomocí následující syntaxe.

• Strategie runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Pro kanárkovou strategii: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Pro strategii zajištění provozu : $[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

Další informace o nastavení výstupní proměnné s více úlohami

Vyhněte se vrácení kritických změn zpět

V klasických kanálech verzí se při pravidelných aktualizacích běžně spoléháte na plánovaná nasazení. Pokud ale máte kritickou opravu, můžete se rozhodnout spustit ruční nasazení mimo pásmo. Když to uděláte, budou se starší verze dál plánovat. To představovalo výzvu, protože ruční nasazení by se vrátilo zpět, když se nasazení obnovila podle plánu. Mnoho z vás tento problém nahlásilo a my ho teď opravili. Díky této opravě by se při ručním spuštění nasazení zrušila všechna starší plánovaná nasazení do prostředí. To platí jenom v případě, že je možnost zařadit do fronty vybraná jako Nasadit nejnovější a zrušit ostatní.

Zjednodušená autorizace prostředků v kanálech YAML

Prostředek je cokoli, co používá kanál, který je mimo kanál. Prostředky musí být autorizovány, aby bylo možné je použít. Při použití neautorizovaných prostředků v kanálu YAML dříve došlo k selhání s chybou autorizace prostředků. Museli jste autorizovat prostředky ze souhrnné stránky neúspěšného spuštění. Kromě toho kanál selhal, pokud používal proměnnou, která odkazovala na neautorizovaný prostředek.

Teď usnadňujeme správu autorizace prostředků. Místo toho, aby spuštění selhalo, počká na oprávnění k prostředkům na začátku fáze, která prostředek spotřebovává. Vlastník prostředku může zobrazit kanál a autorizovat prostředek na stránce Zabezpečení.

Vyhodnocení kontroly artefaktů

Teď můžete definovat sadu zásad a přidat vyhodnocení zásad jako kontrolu artefaktů image kontejneru v prostředí. Při spuštění kanálu se provádění pozastaví před zahájením fáze, která používá prostředí. Zadaná zásada se vyhodnotí podle dostupných metadat pro nasazovanou image. Kontrola proběhne, když je zásada úspěšná, a pokud se nezdaří, označí fázi jako neúspěšnou.

Aktualizace úlohy nasazení šablony ARM

Dříve jsme nefiltrovali připojení služeb v úloze nasazení šablony ARM. To může vést k selhání nasazení, pokud vybíráte připojení služby s nižším rozsahem, abyste mohli provádět nasazení šablony ARM do širšího rozsahu. Teď jsme přidali filtrování připojení služeb, abychom odfiltrovali připojení služeb s nižším oborem na základě zvoleného rozsahu nasazení.

ReviewApp in Environment

Aplikace ReviewApp nasadí všechny žádosti o přijetí změn z úložiště Git do prostředku dynamického prostředí. Revidující můžou vidět, jak tyto změny vypadají, a pracovat s dalšími závislými službami před tím, než se sloučí do hlavní větve a nasadí do produkčního prostředí. To vám usnadní vytváření a správu prostředků aplikace a výhody všech možností sledovatelnosti a diagnostiky funkcí prostředí. Pomocí klíčového slova reviewApp můžete vytvořit klon prostředku (dynamicky vytvořit nový prostředek na základě existujícího prostředku v prostředí) a přidat nový prostředek do prostředí.

Následuje ukázkový fragment kódu YAML s využitím reviewApp v prostředích.

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

Shromažďování automatických a uživatelem zadaných metadat z kanálu

Teď můžete povolit automatické shromažďování metadat určených uživatelem z úloh kanálu. Metadata můžete použít k vynucení zásad artefaktů v prostředí pomocí vyhodnocení kontroly artefaktů.

Nasazení virtuálních počítačů s prostředími

Jednou z nejžádanějších funkcí v prostředích byla nasazení virtuálních počítačů. Touto aktualizací povolíme prostředek virtuálního počítače v prostředích. Teď můžete orchestrovat nasazení na více počítačů a provádět aktualizace se zajištěním provozu pomocí kanálů YAML. Agenta můžete také nainstalovat přímo na každý z cílových serverů a řídit postupné nasazování na tyto servery. Kromě toho můžete na cílových počítačích použít celý katalog úloh.

Postupné nasazení nahradí instance předchozí verze aplikace instancemi nové verze aplikace na sadě počítačů (klouzavá sada) v každé iteraci.

Například níže uvedené postupné nasazení aktualizuje v každé iteraci až pět cílů. maxParallel určí počet cílů, které je možné nasadit paralelně. Výběr určuje počet cílů, které musí být kdykoli k dispozici, s výjimkou cílů, na které se nasazují. Používá se také k určení podmínek úspěchu a selhání během nasazení.

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

Poznámka

V této aktualizaci se všechny dostupné artefakty z aktuálního kanálu a z přidružených prostředků kanálu stáhnou jenom v deploy rámci hooku životního cyklu. Ke stažení se ale můžete rozhodnout zadáním úlohy Stáhnout artefakt kanálu. Tato funkce obsahuje několik známých mezer. Například při opakování fáze se nasazení znovu spustí na všech virtuálních počítačích, nejen na neúspěšných cílech. Pracujeme na tom, abychom tyto mezery v budoucích aktualizacích odstranili.

Další kontrola nad nasazeními

Azure Pipelines už nějakou dobu podporuje nasazení řízená ručním schvalováním. S nejnovějšími vylepšeními teď máte nad nasazeními ještě větší kontrolu. Kromě schválení teď můžou vlastníci prostředků přidávat automatizované checks ověřování zásad zabezpečení a kvality. Tyto kontroly je možné použít k aktivaci operací a následnému čekání na jejich dokončení. Pomocí dalších kontrol teď můžete definovat kritéria stavu na základě více zdrojů a mít jistotu, že všechna nasazení, která cílí na vaše prostředky, jsou bezpečná bez ohledu na kanál YAML, který nasazení provádí. Vyhodnocení jednotlivých kontrol se může pravidelně opakovat na základě zadaného intervalu opakování kontroly. Nyní jsou k dispozici následující další kontroly:

• Vyvolání libovolného rozhraní REST API a ověření na základě textu odpovědi nebo zpětného volání z externí služby
• Vyvolání funkce Azure a ověření na základě odpovědi nebo zpětného volání z funkce
• Dotazování pravidel služby Azure Monitor pro aktivní upozornění
• Ujistěte se, že kanál rozšiřuje jednu nebo více šablon YAML.

Oznámení o schválení

Když přidáte schválení do prostředí nebo připojení služby, všechny vícefázové kanály, které používají prostředek, automaticky čekají na schválení na začátku fáze. Určení schvalovatelé musí dokončit schválení, aby mohli kanál pokračovat.

S touto aktualizací se schvalovatelům odešle e-mailové oznámení čekající na schválení. Uživatelé a vlastníci týmů můžou vyjádřit výslovný nesouhlas s vlastními odběry nebo je konfigurovat pomocí nastavení oznámení.

Konfigurace strategií nasazení z Azure Portal

Díky této funkci jsme vám usnadnili konfiguraci kanálů, které používají strategii nasazení podle vašeho výběru, například Rolling, Canary nebo Blue-Green. Pomocí těchto předefinovaných strategií můžete zavádět aktualizace bezpečným způsobem a zmírnit související rizika nasazení. Pokud k tomu chcete získat přístup, klikněte na nastavení Průběžné doručování na virtuálním počítači Azure. V podokně konfigurace se zobrazí výzva k výběru podrobností o projektu Azure DevOps, ve kterém se kanál vytvoří, skupině nasazení, kanálu sestavení, který publikuje balíček, který se má nasadit, a strategii nasazení podle vašeho výběru. V další fázi nakonfigurujete plně funkční kanál, který nasadí vybraný balíček do tohoto virtuálního počítače.

Další podrobnosti najdete v naší dokumentaci ke konfiguraci strategií nasazení.

Parametry modulu runtime

Parametry modulu runtime umožňují větší kontrolu nad tím, jaké hodnoty je možné předávat kanálu. Na rozdíl od proměnných mají parametry modulu runtime datové typy a nestanou se automaticky proměnnými prostředí. Pomocí parametrů modulu runtime můžete:

• Zadání různých hodnot skriptům a úlohám za běhu
• Typy parametrů řízení, povolené rozsahy a výchozí hodnoty
• Dynamické výběr úloh a fází pomocí výrazu šablony

Další informace o parametrech modulu runtime najdete v této dokumentaci.

Použití klíčového slova extends v kanálech

V současné době je možné kanály převést do šablon, což podporuje opakované použití a snižuje často používané možnosti. Celková struktura kanálu byla stále definována kořenovým souborem YAML. V této aktualizaci jsme přidali strukturovanější způsob, jak používat šablony kanálů. Kořenový soubor YAML teď může pomocí klíčového slova extends označit, že hlavní strukturu kanálu je možné najít v jiném souboru. Díky tomu máte kontrolu nad tím, které segmenty je možné rozšířit nebo změnit a které segmenty jsou pevné. Vylepšili jsme také parametry kanálu o datové typy, aby bylo jasné, co můžete zadávat.

Tento příklad ukazuje, jak můžete autorovi kanálu poskytnout jednoduché hooky. Šablona vždy spustí sestavení, volitelně spustí další kroky poskytované kanálem a pak spustí volitelný testovací krok.

# 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 }}

Řízení proměnných, které je možné přepsat v době fronty

Dříve jste mohli před spuštěním nového spuštění aktualizovat hodnoty libovolné proměnné pomocí uživatelského rozhraní nebo rozhraní REST API. I když autor kanálu může určité proměnné označit jako _settable at queue time_, systém to nevynucoval, ani nezabránil nastavení jiných proměnných. Jinými slovy, nastavení bylo použito pouze k zobrazení výzvy k zadání dalších vstupů při spuštění nového spuštění.

Přidali jsme nové nastavení kolekce, které vynucuje _settable at queue time_ parametr . Získáte tak kontrolu nad tím, které proměnné je možné změnit při spuštění nového spuštění. V budoucnu nemůžete změnit proměnnou, která není autorem označena jako _settable at queue time_.

Poznámka

Toto nastavení je ve výchozím nastavení ve stávajících kolekcích vypnuté, ale při vytváření nové kolekce Azure DevOps bude ve výchozím nastavení zapnuté.

Nové předdefinované proměnné v kanálu YAML

Proměnné poskytují pohodlný způsob, jak do různých částí kanálu dostat klíčové části dat. V této aktualizaci jsme do úlohy nasazení přidali několik předdefinovaných proměnných. Tyto proměnné jsou automaticky nastaveny systémem, jsou vymezeny na konkrétní úlohu nasazení a jsou jen pro čtení.

• Environment.Id – ID prostředí.
• Environment.Name – název prostředí, na které cílí úloha nasazení.
• Environment.ResourceId – ID prostředku v prostředí, na které cílí úloha nasazení.
• Environment.ResourceName – název prostředku v prostředí, na které cílí úloha nasazení.

Rezervace několika úložišť

Kanály často spoléhají na více úložišť. Můžete mít různá úložiště se zdroji, nástroji, skripty nebo jinými položkami, které potřebujete k sestavení kódu. Dříve jste museli tato úložiště přidat jako dílčí moduly nebo jako ruční skripty, abyste mohli spustit git checkout. Teď můžete načíst a rezervovat další úložiště kromě toho, které používáte k uložení kanálu YAML.

Pokud máte například úložiště s názvem MyCode s kanálem YAML a druhé úložiště s názvem Tools, bude váš kanál YAML vypadat takto:

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

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

Ve třetím kroku se v adresáři sources zobrazí dva adresáře , MyCode a Tools .

Azure Repos úložiště Git jsou podporovaná. Další informace najdete v tématu Rezervace s více úložišti.

Získání podrobností o několika úložištích za běhu

Když je kanál spuštěný, Azure Pipelines přidá informace o úložišti, větvi a potvrzení, které spuštění aktivovaly. Teď, když kanály YAML podporují rezervaci více úložišť, můžete také vědět, jaké úložiště, větev a potvrzení byly rezervovány pro jiná úložiště. Tato data jsou k dispozici prostřednictvím výrazu modulu runtime, který teď můžete namapovat na proměnnou. Příklad:

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"

Povolit odkazy na úložiště na jiné kolekce Azure Repos

Když jste dříve odkazovali na úložiště v kanálu YAML, všechna úložiště Azure Repos musela být ve stejné kolekci jako kanál. Teď můžete odkazovat na úložiště v jiných kolekcích pomocí připojení služby. Příklad:

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

MyServiceConnection odkazuje na jinou kolekci Azure DevOps a má přihlašovací údaje, které mají přístup k úložišti v jiném projektu. Obě úložiště self i otherrepose nakonec budou rezervovat.

Důležité

MyServiceConnectionMusí se jednat o připojení služby Azure Repos / Team Foundation Server, viz následující obrázek.

Metadata prostředků kanálu jako předdefinované proměnné

Přidali jsme do kanálu předdefinované proměnné pro prostředky kanálů YAML. Tady je seznam dostupných proměnných prostředků kanálu.

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

Možnosti kustomize a kompose as bake v úloze KubernetesManifest

Kustomize (součást Kubernetes sig-cli) umožňuje přizpůsobit nezpracované soubory YAML bez šablon pro různé účely a původní YAML zůstane nedotčený. V rámci akce bake úlohy KubernetesManifest byla přidána možnost kustomize, aby se všechny složky obsahující soubory kustomization.yaml daly použít ke generování souborů manifestu použitých v akci nasazení úlohy KubernetesManifest.

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 transformuje soubory Docker Compose na prostředek Kubernetes.

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)

Podpora přihlašovacích údajů správce clusteru v úloze HelmDeploy

Dříve úloha HelmDeploy používala přihlašovací údaje uživatele clusteru pro nasazení. Výsledkem byly interaktivní výzvy k přihlášení a selhání kanálů pro cluster s podporou řízení přístupu na základě role založeného na Azure Active Directory. Abychom tento problém vyřešili, přidali jsme zaškrtávací políčko, které umožňuje místo přihlašovacích údajů uživatele clusteru použít přihlašovací údaje správce clusteru.

Zadávání argumentů v úloze Docker Compose

V úloze Docker Compose bylo zavedeno nové pole, které umožňuje přidat argumenty, jako --no-cacheje . Argument bude předán úlohou při spouštění příkazů, jako je sestavení.

Vylepšení úloh vydání na GitHubu

V úloze vydání GitHubu jsme provedli několik vylepšení. Teď můžete mít lepší kontrolu nad vytvářením vydané verze pomocí pole vzoru značky zadáním regulárního výrazu značky a vydání se vytvoří pouze v případech, kdy je aktivační potvrzení označeno odpovídajícím řetězcem.

Přidali jsme také možnosti pro přizpůsobení vytváření a formátování protokolu změn. V nové části pro konfiguraci protokolu změn teď můžete zadat verzi, se kterou se má aktuální verze porovnávat. Porovnání s vydanou verzí může být poslední úplná verze (nezahrnuje předběžné verze), poslední vydaná verze bez konceptu nebo jakákoli předchozí verze odpovídající zadané značce vydané verze. Kromě toho úkol poskytuje pole typu protokolu změn pro formátování protokolu změn. V závislosti na výběru se v protokolu změn zobrazí buď seznam potvrzení, nebo seznam problémů nebo žádostí o přijetí změn rozdělených do kategorií podle popisků.

Otevřít úlohu instalačního programu Agenta zásad

Open Policy Agent je open source modul zásad pro obecné účely, který umožňuje jednotné vynucování zásad s podporou kontextu. Přidali jsme úlohu instalačního programu Open Policy Agent. Je obzvláště užitečná pro vynucování zásad v kanálu s ohledem na poskytovatele infrastruktury jako kódu.

Například Open Policy Agent může vyhodnotit soubory zásad Rego a plány Terraformu v kanálu.

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

Podpora skriptů PowerShellu v úloze Azure CLI

Dříve jste mohli spouštět dávkové skripty a skripty Bash jako součást úlohy Azure CLI. V této aktualizaci jsme do úlohy přidali podporu základních skriptů PowerShellu a PowerShellu.

Kanárová nasazení založená na rozhraní Service Mesh v úloze KubernetesManifest

Když byla dříve v úloze KubernetesManifest zadána kanárová strategie, úloha vytvořila základní a kanárkové úlohy, jejichž repliky se rovnaly procentu replik používaných pro stabilní úlohy. Nebylo to úplně stejné jako rozdělení provozu na požadované procento na úrovni požadavku. Abychom tento problém vyřešili, přidali jsme do úlohy KubernetesManifest podporu kanárových nasazení založených na rozhraní Service Mesh .

Abstrakce rozhraní Service Mesh umožňuje konfiguraci plug-and-play s poskytovateli sítě služeb, jako jsou Linkerd a Istio. Úloha KubernetesManifest teď odvádí tvrdou práci při mapování objektů TrafficSplit služby SMI na stabilní, základní a kanárské služby během životního cyklu strategie nasazení. Požadované procentuální rozdělení provozu mezi stabilní, standardní a kanárské je přesnější, protože procento rozdělení provozu se řídí požadavky v rovině sítě služby.

Následuje ukázka provádění kanárových nasazení založených na SMI se zajištěním provozu.

- 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'

Úloha kopírování souborů Azure teď podporuje AzCopy V10

Úlohu kopírování souborů Azure je možné použít v kanálu sestavení nebo verze ke kopírování souborů do objektů blob nebo virtuálních počítačů úložiště Microsoftu. Úloha používá AzCopy, nástroj příkazového řádku, který umožňuje rychlé kopírování dat z účtů úložiště Azure a do účtů úložiště Azure. V této aktualizaci jsme přidali podporu nástroje AzCopy V10, což je nejnovější verze nástroje AzCopy.

Příkaz azcopy copy podporuje pouze přidružené argumenty . Kvůli změně syntaxe nástroje AzCopy nejsou některé z existujících funkcí v nástroji AzCopy v10 k dispozici. Tady jsou některé z nich:

• Určení umístění protokolu
• Čištění souborů protokolů a plánů po kopírování
• Obnovení kopírování v případě selhání úlohy

Tato verze úlohy podporuje další funkce:

• Zástupné symboly v názvu souboru nebo cestě ke zdroji
• Odvození typu obsahu na základě přípony souboru, pokud nejsou zadány žádné argumenty
• Definování podrobností protokolu pro soubor protokolu předáním argumentu

Zlepšení zabezpečení kanálu omezením rozsahu přístupových tokenů

Každá úloha spuštěná v Azure Pipelines získá přístupový token. Přístupový token používají úlohy a vaše skripty k zpětnému volání do Azure DevOps. Přístupový token používáme například k získání zdrojového kódu, nahrávání protokolů, výsledků testů, artefaktů nebo k volání REST do Azure DevOps. Pro každou úlohu se vygeneruje nový přístupový token, který po dokončení úlohy vyprší. V této aktualizaci jsme přidali následující vylepšení.

• Zabránění tokenu v přístupu k prostředkům mimo týmový projekt

  Až dosud byla výchozím oborem všech kanálů kolekce týmových projektů. Obor můžete změnit na týmový projekt v klasických kanálech buildu. Tuto kontrolu jste ale neměli pro klasické kanály vydané verze nebo KANÁLy YAML. V této aktualizaci zavádíme nastavení kolekce, které vynutí, aby každá úloha získala token v rámci projektu bez ohledu na to, co je v kanálu nakonfigurované. Také jsme přidali nastavení na úrovni projektu. Teď bude toto nastavení automaticky zapnuté u každého nového projektu a kolekce, kterou vytvoříte.

  Poznámka

  Nastavení kolekce přepíše nastavení projektu.

  Zapnutí tohoto nastavení v existujících projektech a kolekcích může způsobit selhání určitých kanálů, pokud vaše kanály přistupují k prostředkům mimo týmový projekt pomocí přístupových tokenů. Pokud chcete zmírnit selhání kanálu, můžete účtu služby sestavení projektu explicitně udělit přístup k požadovanému prostředku. Důrazně doporučujeme tato nastavení zabezpečení zapnout.

• Omezení přístupu k oboru úložišť buildovací služby

  Azure Pipelines teď může na základě vylepšení zabezpečení kanálu omezením rozsahu přístupového tokenu omezit přístup k úložišti jenom na úložiště potřebná pro kanál založený na JAZYCE YAML. To znamená, že v případě úniku přístupového tokenu kanálů by se zobrazila pouze úložiště použitá v kanálu. Dříve byl přístupový token vhodný pro jakékoli úložiště Azure Repos v projektu nebo potenciálně pro celou kolekci.

  Tato funkce bude u nových projektů a kolekcí ve výchozím nastavení zapnutá. U existujících kolekcí ho musíte povolit v Nastavení kolekce Nastavení>Kanály>Nastavení. Při použití této funkce musí být všechna úložiště potřebná sestavením (i ta, která klonujete pomocí skriptu), zahrnutá do prostředků úložiště kanálu.

• Odebrání určitých oprávnění pro přístupový token

  Ve výchozím nastavení udělujeme přístupovým tokenům několik oprávnění. Jedním z těchto oprávnění je sestavení fronty. Touto aktualizací jsme odebrali toto oprávnění pro přístupový token. Pokud vaše kanály potřebují toto oprávnění, můžete ho explicitně udělit účtu služby sestavení projektu nebo účtu služby sestavení kolekce projektů v závislosti na tokenu, který používáte.

Zabezpečení na úrovni projektu pro připojení služeb

Přidali jsme zabezpečení na úrovni centra pro připojení služeb. Teď můžete přidávat nebo odebírat uživatele, přiřazovat role a spravovat přístup na centrálním místě pro všechna připojení služeb.

Cílení na kroky a izolace příkazů

Azure Pipelines podporuje spouštění úloh v kontejnerech nebo na hostiteli agenta. Dříve byla celá úloha nastavena na jeden z těchto dvou cílů. Jednotlivé kroky (úkoly nebo skripty) se teď můžou spouštět na zvoleném cíli. Kroky můžou také cílit na jiné kontejnery, takže kanál může každý krok spustit ve specializovaném kontejneru vytvořeném pro účely.

Kontejnery můžou fungovat jako hranice izolace a bránit kódu v provádění neočekávaných změn na hostitelském počítači. Izolování kroků v kontejneru nemá vliv na způsob, jakým kroky komunikují se službami agenta a přistupují ke službám z agenta. Proto také zavádíme režim omezení příkazů, který můžete použít s cíli kroků. Zapnutím této možnosti omezíte služby, které může krok od agenta vyžadovat. Už nebude moct připojovat protokoly, nahrávat artefakty a některé další operace.

Tady je komplexní příklad znázorňující spuštění kroků na hostiteli v kontejneru úloh a v jiném kontejneru:

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

Proměnné jen pro čtení

Systémové proměnné byly zdokumentovány jako neměnné, ale v praxi by mohly být přepsány úkolem a podřízené úkoly by převzaly novou hodnotu. S touto aktualizací zpřísníme zabezpečení proměnných kanálu, aby byly systémové proměnné a proměnné v čase fronty jen pro čtení. Kromě toho můžete proměnnou YAML nastavit jen pro čtení tak, že ji označíte následujícím způsobem.

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

Přístup na základě role pro připojení služeb

Přidali jsme přístup na základě role pro připojení služeb. Dříve bylo možné zabezpečení připojení služeb spravovat pouze prostřednictvím předdefinovaných skupin Azure DevOps, jako jsou správci koncových bodů a tvůrci koncových bodů.

V rámci této práce jsme představili nové role Čtenář, Uživatel, Tvůrce a Správce. Tyto role můžete nastavit prostřednictvím stránky připojení služeb ve vašem projektu, které zdědí jednotlivá připojení. A v každém připojení služby máte možnost zapnout nebo vypnout dědičnost a přepsat role v oboru připojení služby.

Další informace o zabezpečení připojení služeb najdete tady.

Sdílení připojení služeb mezi projekty

Povolili jsme podporu sdílení připojení služeb mezi projekty. Připojení služeb teď můžete bezpečně a bezpečně sdílet se svými projekty.

Další informace o sdílení připojení ke službám najdete tady.

Sledovatelnost kanálů a prostředků ACR

Zajišťujeme úplnou sledovatelnost E2E při použití kanálů a prostředků kontejneru ACR v kanálu. Pro každý prostředek spotřebovaný kanálem YAML můžete trasovat zpět k potvrzením, pracovním položkám a artefaktům.

V zobrazení souhrnu spuštění kanálu vidíte:

• Verze prostředku, která aktivovala spuštění. Kanál se teď může aktivovat po dokončení jiného spuštění kanálu Azure nebo při nasdílení image kontejneru do služby ACR.

  

• Potvrzení, která kanál využívá. Můžete také najít rozpis potvrzení podle jednotlivých prostředků spotřebovaných kanálem.

  

• Pracovní položky, které jsou přidružené ke každému prostředku spotřebovanému kanálem.

• Artefakty, které jsou k dispozici pro použití při spuštění.

  

V zobrazení nasazení prostředí můžete zobrazit potvrzení a pracovní položky pro každý prostředek nasazený do prostředí.

Podpora velkých testovacích příloh

Úloha publikování výsledků testů v Azure Pipelines umožňuje publikovat výsledky testů při provádění testů, aby poskytovala komplexní sestavy testů a analytické prostředí. Doteď existoval limit 100 MB pro přílohy testů pro výsledky testu i běhu testů. To omezilo nahrávání velkých souborů, jako jsou výpisy stavu systému nebo videa. V této aktualizaci jsme přidali podporu velkých testovacích příloh, abyste měli všechna dostupná data pro řešení potíží s neúspěšnými testy.

V protokolech se může zobrazit úloha VSTest nebo Úloha publikování výsledků testu vracející chybu 403 nebo 407. Pokud používáte sestavení v místním prostředí nebo agenty vydaných verzí za bránou firewall, která filtruje odchozí požadavky, budete muset provést nějaké změny konfigurace, abyste mohli tuto funkci používat. ​

Pokud chcete tento problém vyřešit, doporučujeme aktualizovat bránu firewall pro odchozí požadavky na https://*.vstmrblob.vsassets.ioadresu . Informace o řešení potíží najdete v dokumentaci tady. ​

Poznámka

To je nutné jenom v případě, že používáte agenty Azure Pipelines v místním prostředí a nacházíte se za bránou firewall, která filtruje odchozí provoz. Pokud používáte agenty hostované Microsoftem v cloudu nebo nefiltrujete odchozí síťový provoz, nemusíte nic dělat.

Zobrazit správné informace o fondu pro každou úlohu

Když jste dříve použili matici k rozšíření úloh nebo proměnnou k identifikaci fondu, někdy jsme na stránkách protokolů vyřešili nesprávné informace o fondu. Tyto problémy byly vyřešeny.

Triggery CI pro nové větve

Byl to dlouho čekající požadavek, aby se neaktivovala sestavení CI, když se vytvoří nová větev a tato větev neobsahuje změny. Představte si následující příklady:

• Pomocí webového rozhraní vytvoříte novou větev založenou na existující větvi. Pokud filtr vaší větve odpovídá názvu nové větve, okamžitě se aktivuje nové sestavení CI. To je nežádoucí, protože obsah nové větve je ve srovnání s existující větví stejný.
• Máte úložiště se dvěma složkami – aplikací a dokumenty. Nastavili jste filtr cesty pro CI tak, aby odpovídal "aplikaci". Jinými slovy, nechcete vytvářet nové sestavení, pokud byla do dokumentace vložena změna. Vytvoříte novou větev místně, provedete nějaké změny v dokumentaci a pak tuto větev nasdílíte na server. Použili jsme k aktivaci nového sestavení CI. To je nežádoucí, protože jste výslovně požádali, abyste změny ve složce docs nehledali. Vzhledem k tomu, jak jsme zpracovávali událost nové větve, se ale zdá, že došlo ke změně i ve složce aplikace.

Teď máme lepší způsob, jak zpracovat CI pro nové větve, abychom tyto problémy vyřešili. Když publikujete novou větev, explicitně vyhledáme nová potvrzení v této větvi a zkontrolujeme, jestli odpovídají filtrům cest.

Úlohy mají přístup k výstupním proměnným z předchozích fází.

Výstupní proměnné se teď dají používat napříč fázemi v kanálu založeném na YAML. To vám pomůže předávat užitečné informace, jako je rozhodnutí o přechodu nebo nechodě nebo ID vygenerovaného výstupu, z jedné fáze do druhé. K dispozici je také výsledek (stav) předchozí fáze a jejích úloh.

Výstupní proměnné se stále vytvářejí podle kroků v rámci úloh. Místo odkazování na dependencies.jobName.outputs['stepName.variableName'], fáze odkazují na stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Poznámka

Ve výchozím nastavení každá fáze v kanálu závisí na fázi, která je v souboru YAML těsně před ní. Každá fáze proto může používat výstupní proměnné z předchozí fáze. Graf závislostí můžete změnit, což také změní, které výstupní proměnné jsou k dispozici. Pokud například fáze 3 potřebuje proměnnou z fáze 1, bude muset deklarovat explicitní závislost na fázi 1.

Zákaz automatických upgradů agentů na úrovni fondu

V současné době se agenti kanálů v případě potřeby automaticky aktualizují na nejnovější verzi. K tomu obvykle dochází v případě, že existuje nová funkce nebo úloha, která ke správnému fungování vyžaduje novější verzi agenta. Touto aktualizací přidáváme možnost zakázat automatické upgrady na úrovni fondu. Pokud v tomto režimu není k fondu připojený žádný agent správné verze, kanály selžou s jasnou chybovou zprávou a nebudou žádat agenty o aktualizaci. Tato funkce je většinou zajímavá pro zákazníky s fondy v místním prostředí a velmi přísnými požadavky na řízení změn. Automatické aktualizace jsou ve výchozím nastavení povolené a nedoporučujeme, aby je většina zákazníků zakazovala.

Diagnostika agenta

Přidali jsme diagnostiku pro řadu běžných problémů souvisejících s agenty, jako jsou problémy se sítěmi a běžné příčiny selhání upgradu. Pokud chcete začít s diagnostikou, použijte run.sh --diagnostics nebo run.cmd --diagnostics ve Windows.

Zachycení služeb pro kanály YAML

Integrace služeb s kanály YAML je teď jednodušší. Pomocí událostí zachycení služby pro kanály YAML teď můžete řídit aktivity ve vlastních aplikacích nebo službách na základě průběhu spuštění kanálu. Můžete například vytvořit lístek helpdesku, když se vyžaduje schválení, zahájit pracovní postup monitorování po dokončení fáze nebo odeslat nabízené oznámení na mobilní zařízení vašeho týmu, když fáze selže.

Filtrování názvu kanálu a názvu fáze se podporuje pro všechny události. Události schválení je možné filtrovat také pro konkrétní prostředí. Podobně se události změny stavu dají filtrovat podle nového stavu spuštění kanálu nebo fáze.

Optimalizace integrace

Optimizely je výkonná platforma pro testování A/B a označování funkcí pro produktové týmy. Integrace Služby Azure Pipelines s platformou Optimizely experimentování umožňuje produktovým týmům rychleji testovat, učit se a nasazovat a současně využívat všechny výhody DevOps ze služby Azure Pipelines.

Rozšíření Optimizely pro Azure DevOps přidává do kanálů buildu a verze kroky pro experimentování a příznaky funkcí, takže můžete průběžně iterovat, zavádět funkce a vracet je zpět pomocí Azure Pipelines.

Další informace o rozšíření Optimizely Pro Azure DevOps najdete tady.

Přidání verze GitHubu jako zdroje artefaktů

Teď můžete své verze GitHubu propojit jako zdroj artefaktů v kanálech verzí Azure DevOps. To vám umožní využívat vydání GitHubu jako součást nasazení.

Když v definici kanálu verze kliknete na Přidat artefakt , najdete nový typ zdroje verze GitHubu . Můžete poskytnout připojení služby a úložiště GitHub pro využívání verze GitHubu. Můžete také zvolit výchozí verzi pro vydání GitHubu, která se má používat jako nejnovější verze konkrétní značky, nebo vybrat při vytváření verze. Jakmile je verze GitHub propojená, automaticky se stáhne a zpřístupní ve vašich úlohách vydání.

Integrace Terraformu s Azure Pipelines

Terraform je opensourcový nástroj pro bezpečný a efektivní vývoj, změnu a správu verzí infrastruktury. Terraform kodifikuje rozhraní API do deklarativních konfiguračních souborů, což vám umožní definovat a zřizovat infrastrukturu pomocí konfiguračního jazyka vysoké úrovně. Rozšíření Terraform můžete použít k vytváření prostředků napříč všemi hlavními poskytovateli infrastruktury: Azure, Amazon Web Services (AWS) a Google Cloud Platform (GCP).

Další informace o rozšíření Terraform najdete v této dokumentaci.

Integrace s Google Analytics

Architektura experimentů Google Analytics umožňuje testovat téměř jakoukoli změnu nebo variaci webu nebo aplikace a změřit její dopad na konkrétní cíl. Můžete mít například aktivity, které chcete, aby vaši uživatelé dokončili (např. provést nákup, zaregistrovat se k bulletinu) nebo metriky, které chcete zlepšit (např. výnosy, doba trvání relace, míra nedoručitelnosti). Tyto aktivity umožňují identifikovat změny, které stojí za to implementovat, na základě jejich přímého dopadu na výkon vaší funkce.

Rozšíření Experimenty Google Analytics pro Azure DevOps přidává kroky experimentování do kanálů buildu a verze, takže můžete nepřetržitě iterovat, učit se a nasazovat ve zrychleném tempu tím, že experimenty průběžně spravujete a současně získáváte všechny výhody DevOps, které přináší Azure Pipelines.

Rozšíření Experimenty Google Analytics si můžete stáhnout z Marketplace.

Aktualizace integrace ServiceNow se službou Azure Pipelines

Aplikace Azure Pipelines pro ServiceNow pomáhá integrovat Azure Pipelines a Správu změn ServiceNow. S touto aktualizací se můžete integrovat s newyorské verzi ServiceNow. Ověřování mezi těmito dvěma službami se teď dá provádět pomocí OAuth a základního ověřování. Kromě toho teď můžete nakonfigurovat upřesňující kritéria úspěchu, abyste mohli pomocí jakékoli vlastnosti změny rozhodnout o výsledku brány.

Create Azure Pipelines z VSCode

Do rozšíření Azure Pipelines jsme přidali novou funkci pro VSCode. Teď budete moct vytvořit Azure Pipelines přímo z VSCode, aniž byste opustili integrované vývojové prostředí.

Správa a řešení nesměšné chyby

Zavedli jsme přehlednou správu testů, která podporuje kompletní životní cyklus detekce, generování sestav a řešení. Abychom ho dále vylepšili, přidáváme správu a řešení chyb testů.

Při prošetřování nespolehlivého testu můžete vytvořit chybu pomocí akce Chyba , kterou pak můžete přiřadit vývojáři, aby mohli podrobněji prozkoumat původní příčinu tohoto nechutného testu. Zpráva o chybě obsahuje informace o kanálu, jako je chybová zpráva, trasování zásobníku a další informace související s testem.

Když se zpráva o chybě vyřeší nebo zavře, automaticky zrušíme označení testu jako neochvějné.

Nastavte úlohy VSTest tak, aby selhaly, pokud se nespustil minimální počet testů.

Úloha VSTest zjišťuje a spouští testy pomocí uživatelských vstupů (testovací soubory, kritéria filtru atd.) a adaptéru testu specifického pro používanou testovací architekturu. Změny uživatelských vstupů nebo adaptéru testů mohou vést k případům, kdy se testy nezjistí a spustí se pouze podmnožina očekávaných testů. To může vést k situacím, kdy kanály uspěje, protože testy se přeskočí, a ne proto, že kód je dostatečně kvalitní. Abychom této situaci předešli, přidali jsme do úlohy VSTest novou možnost, která umožňuje určit minimální počet testů, které je potřeba spustit, aby úloha prošla.

Možnost VSTest TestResultsDirectory je dostupná v uživatelském rozhraní úlohy.

Úloha VSTest ukládá výsledky testů a přidružené soubory do $(Agent.TempDirectory)\TestResults složky . Do uživatelského rozhraní úloh jsme přidali možnost, abyste mohli nakonfigurovat jinou složku pro ukládání výsledků testů. Teď je můžou použít všechny následné úkoly, které potřebují soubory v konkrétním umístění.

Podpora Markdownu v chybových zprávách automatizovaného testu

Přidali jsme podporu markdownu pro chybové zprávy pro automatizované testy. Teď můžete snadno formátovat chybové zprávy pro výsledky testovacího běhu i výsledku testu, abyste zlepšili čitelnost a usnadnili řešení potíží se selháním testu v Azure Pipelines. Podporovanou syntaxi markdownu najdete tady.

Použití dekorátorů kanálu k automatickému vkládání kroků do úlohy nasazení

Teď můžete do úloh nasazení přidat dekorátory kanálů . Do každého spuštění zachytávače životního cyklu každé úlohy nasazení můžete automaticky vkládaný libovolný vlastní krok (např. kontrola ohrožení zabezpečení). Vzhledem k tomu, že dekorátory kanálů je možné použít u všech kanálů v kolekci, je možné je využít jako součást vynucování postupů bezpečného nasazení.

Kromě toho je možné úlohy nasazení spouštět jako úlohu kontejneru společně se službami, pokud jsou definovány.

Test Plans

Stránka Nový testovací plán

Pro všechny kolekce Azure DevOps je k dispozici nová stránka Test Plans (Test Plans *). Nová stránka nabízí zjednodušená zobrazení, která vám pomůžou soustředit se na úkol, který máte – plánování testů, vytváření obsahu nebo provádění. Je také nepotřebné a konzistentní se zbytkem nabídky Azure DevOps.

Pomozte mi pochopit novou stránku

Nová stránka Test Plans má celkem 6 oddílů, z nichž první 4 jsou nové, zatímco oddíly Grafy & Rozšiřitelnost jsou stávající funkce.

1. Hlavička testovacího plánu: Slouží k vyhledání, přidání do oblíbených, úprav, zkopírování nebo klonování testovacího plánu.
2. Strom testovacích sad: Slouží k přidávání, správě, exportu nebo řazení testovacích sad. Využijte ho také k přiřazení konfigurací a testování přijetí uživatelem.
3. Karta Definovat: Na této kartě můžete kompletovat, přidávat a spravovat testovací případy v testovací sadě podle výběru.
4. Karta Spustit: Pomocí této karty přiřaďte a spusťte testy nebo vyhledejte výsledek testu, ke kterému chcete přejít k podrobnostem.
5. Karta Graf: Sledujte průběh a stav testů prostřednictvím grafů, které je také možné připnout na řídicí panely.
6. Rozšiřitelnost: Podporuje aktuální body rozšiřitelnosti v rámci produktu.

Pojďme se na tyto nové části podívat z širšího pohledu.

1. Hlavička testovacího plánu

Úlohy

Hlavička Testovací plán umožňuje provádět následující úlohy:

• Označení testovacího plánu jako oblíbeného
• Zrušení označení testovacího plánu s oblíbenými položkami
• Snadné procházení mezi oblíbenými testovacími plány
• Zobrazení cesty iterace testovacího plánu, která jasně indikuje, jestli je testovací plán Aktuální nebo Minulý
• Zobrazení rychlého souhrnu sestavy průběhu testů s odkazem pro přechod na sestavu
• Přechod zpět na stránku Test Plans Vše nebo moje

Možnosti místní nabídky

Místní nabídka v hlavičce Testovací plán nabízí následující možnosti:

• Kopírovat testovací plán: Jedná se o novou možnost, která umožňuje rychle zkopírovat aktuální testovací plán. Další podrobnosti najdete níže.
• Upravit testovací plán: Tato možnost umožňuje upravit formulář pracovní položky testovacího plánu pro správu polí pracovních položek.
• Nastavení testovacího plánu: Tato možnost umožňuje nakonfigurovat nastavení testovacího běhu (pro přidružení kanálů buildu nebo verze) a nastavení Výsledků testu.

Kopírování testovacího plánu (nová funkce)

Doporučujeme vytvořit nový testovací plán pro každý sprint nebo vydání. V takovém případě je obecně možné zkopírovat testovací plán pro předchozí cyklus a s několika změnami je zkopírovaný testovací plán připravený pro nový cyklus. Abychom tento proces usnadnili, povolili jsme na nové stránce funkci Kopírovat testovací plán. Jeho využitím můžete kopírovat nebo klonovat testovací plány. Jeho rozhraní REST API je popsané tady a rozhraní API umožňuje kopírovat/klonovat testovací plán i napříč projekty.
Další pokyny k používání Test Plans najdete tady.

2. Strom testovacích sad

Úlohy

Hlavička Testovací sada umožňuje provádět následující úlohy:

• Rozbalit/sbalit: Tyto možnosti panelu nástrojů umožňují rozbalit nebo sbalit strom hierarchie sady.
• Zobrazit testovací body z podřízených sad: Tato možnost panelu nástrojů je viditelná pouze v případě, že jste na kartě Provést. To vám umožní zobrazit všechny testovací body pro danou sadu a její podřízené položky v jednom zobrazení pro snadnější správu testovacích bodů, aniž byste museli přecházet do jednotlivých sad po jednom.
• Seřazení sad: Přetažením sad můžete změnit pořadí hierarchie sad nebo je přesunout z jedné hierarchie sady do jiné v rámci testovacího plánu.

Možnosti místní nabídky

Místní nabídka ve stromové struktuře testovacích sad nabízí následující možnosti:

• Create nových sad: Můžete vytvořit 3 různé typy sad následujícím způsobem:
  • K uspořádání testů použijte statickou sadu nebo sadu složek.
  • Sadu založenou na požadavcích můžete použít k přímému propojení s požadavky a uživatelskými příběhy, abyste je mohli snadno sledovat.
  • Pomocí dotazů můžete dynamicky uspořádat testovací případy, které splňují kritéria dotazu.
• Přiřadit konfigurace: Můžete přiřadit konfigurace pro sadu (například Chrome, Firefox, EdgeChromium) a ty pak budou použitelné pro všechny existující testovací případy nebo nové testovací případy, které do této sady přidáte později.
• Exportovat jako pdf/e-mail: Exportujte vlastnosti testovacího plánu, vlastnosti sady testů spolu s podrobnostmi o testovacích případech a testovacích bodech jako "e-mail" nebo "vytisknout do pdf".
• Otevřít pracovní položku sady testů: Tato možnost umožňuje upravit formulář pracovní položky sady testů pro správu polí pracovních položek.
• Přiřazení testerů ke spuštění všech testů: Tato možnost je velmi užitečná ve scénářích uživatelské akceptační testování (UAT), kdy stejný test musí spustit nebo spustit více testerů, kteří obvykle patří do různých oddělení.
• Přejmenovat nebo odstranit: Tyto možnosti umožňují spravovat název sady nebo odebrat sadu a její obsah z testovacího plánu.

3. Definovat kartu

Karta Definovat umožňuje kompletovat, přidávat a spravovat testovací případy pro sadu testů. Zatímco karta Spuštění slouží k přiřazování testovacích bodů a jejich provádění.

Karta Definovat a určité operace jsou dostupné jenom uživatelům s úrovní přístupu Basic + Test Plans nebo ekvivalentní. Všechno ostatní by měl provádět uživatel s úrovní přístupu Basic.

Úlohy

Karta Definovat umožňuje provádět následující úlohy:

• Přidat nový testovací případ pomocí formuláře pracovní položky: Tato možnost umožňuje vytvořit nový testovací případ pomocí formuláře pracovní položky. Vytvořený testovací případ se automaticky přidá do sady.
• Přidat nový testovací případ pomocí mřížky: Tato možnost umožňuje vytvořit jeden nebo více testovacích případů pomocí zobrazení mřížky testovacích případů. Vytvořené testovací případy se automaticky přidají do sady.
• Přidat existující testovací případy pomocí dotazu: Tato možnost umožňuje přidat existující testovací případy do sady zadáním dotazu.
• Pořadí testovacích případů přetažením: Pořadí testovacích případů můžete změnit přetažením nebo přetažením jednoho nebo více testovacích případů v rámci dané sady. Pořadí testovacích případů platí pouze pro ruční testovací případy, a ne pro automatizované testy.
• Přesunutí testovacích případů z jedné sady do druhé: Přetažením můžete testovací případy přesunout z jedné sady testů do druhé.
• Zobrazit mřížku: Režim mřížky můžete použít k zobrazení nebo úpravě testovacích případů spolu s testovacími kroky.
• Zobrazení na celou obrazovku: Pomocí této možnosti můžete zobrazit obsah celé karty Definovat v režimu celé obrazovky.
• Filtrování: Pomocí panelu filtru můžete filtrovat seznam testovacích případů pomocí polí "název testovacího případu", "přiřazeno" a "stav". Seznam můžete seřadit také kliknutím na záhlaví sloupců.
• Možnosti sloupců: Pomocí možnosti sloupců můžete spravovat seznam sloupců viditelných na kartě Definovat. Seznam sloupců, které jsou k dispozici pro výběr, jsou primárně pole z formuláře pracovní položky testovacího případu.

Možnosti místní nabídky

Místní nabídka v uzlu Testovací případ na kartě Definovat nabízí následující možnosti:

• Formulář pracovní položky otevřít nebo upravit testovací případ: Tato možnost umožňuje upravit testovací případ pomocí formuláře pracovní položky, ve kterém upravujete pole pracovní položky včetně testovacích kroků.
• Upravit testovací případy: Tato možnost umožňuje hromadně upravit pole pracovních položek testovacího případu. Tuto možnost ale nemůžete použít k hromadné úpravě testovacích kroků.
• Upravit testovací případy v mřížce: Tato možnost umožňuje hromadně upravit vybrané testovací případy včetně testovacích kroků pomocí zobrazení mřížky.
• Přiřadit konfigurace: Tato možnost umožňuje přepsat konfigurace na úrovni sady konfigurací na úrovni testovacího případu.
• Odebrat testovací případy: Tato možnost umožňuje odebrat testovací případy z dané sady. Nemění ale základní pracovní položku testovacího případu.
• Create kopie/klonování testovacích případů: Tato možnost umožňuje vytvořit kopii nebo klon vybraných testovacích případů. Další podrobnosti najdete níže.
• Zobrazit propojené položky: Tato možnost umožňuje zobrazit propojené položky pro daný testovací případ. Další podrobnosti najdete níže.

Testovací případy kopírování/klonování (nová funkce)

Ve scénářích, kdy chcete zkopírovat nebo naklonovat testovací případ, můžete použít možnost Kopírovat testovací případ. Můžete zadat cílový projekt, cílový testovací plán a cílovou testovací sadu, ve kterých chcete vytvořit testovací případ kopírování nebo klonování. Kromě toho můžete také určit, zda chcete zahrnout existující odkazy nebo přílohy pro tok do klonované kopie.

Zobrazení propojených položek (nová funkce)

Sledovatelnost artefaktů testů, požadavků a chyb je kritickou hodnotou produktu Test Plans. Pomocí možnosti Zobrazit propojené položky si můžete snadno prohlédnout všechny propojené požadavky, se kterými je tento testovací případ propojený, všechny testovací sady / testovací plány, ve kterých byl tento testovací případ použit, a všechny chyby, které byly podány při provádění testu.

4. Karta Spustit

Karta Definovat umožňuje kompletovat, přidávat a spravovat testovací případy pro sadu testů. Zatímco karta Spuštění slouží k přiřazování testovacích bodů a jejich provádění.

Co je testovací bod? Testovací případy samy o sobě nejsou spustitelné. Když do sady testů přidáte testovací případ, vygenerují se testovací body. Testovací bod je jedinečná kombinace testovacího případu, sady testů, konfigurace a testera. Příklad: Pokud máte testovací případ s názvem Funkce testovacího přihlášení a přidáte do něj 2 konfigurace jako Edge a Chrome, výsledkem jsou 2 testovací body. Nyní je možné tyto testovací body spustit. Při spuštění se vygenerují výsledky testu. Prostřednictvím zobrazení výsledků testu (historie provádění) můžete zobrazit všechna spuštění testovacího bodu. Nejnovější spuštění testovacího bodu je to, co vidíte na kartě Spuštění.
Testovací případy jsou proto opakovaně použitelné entity. Jejich zahrnutím do testovacího plánu nebo sady se vygenerují testovací body. Provedením testovacích bodů určíte kvalitu vyvíjeného produktu nebo služby.

Jednou z hlavních výhod nové stránky je pro uživatele, kteří hlavně provádí provádění/sledování testů (potřebují mít pouze základní úroveň přístupu), nejsou zahlceni složitostí správy sady (těmto uživatelům je skrytá karta definice).

Karta Definovat a určité operace jsou dostupné jenom uživatelům s úrovní přístupu Basic + Test Plans nebo ekvivalentní. Všechno ostatní, včetně karty Spustit, by měl uživatel s úrovní přístupu Basic provádět.

Úlohy

Karta Execute (Spustit) umožňuje provádět následující úlohy:

• Hromadné označení testovacích bodů: Tato možnost umožňuje rychle označit výsledek testovacích bodů – úspěšné, neúspěšné, blokované nebo nepoužitelné, aniž byste museli spouštět testovací případ prostřednictvím Test Runneru. Výsledek může být označen pro jeden nebo více testovacích bodů najednou.
• Spustit testovací body: Tato možnost umožňuje spouštět testovací případy tak, že jednotlivě projdete každý testovací krok a označíte je jako úspěšné nebo neúspěšné pomocí test runneru. V závislosti na aplikaci, kterou testujete, můžete web Runner použít pro testování "webové aplikace" nebo "desktopový runner" pro testování desktopových nebo webových aplikací. Můžete také volat "Spustit s možnostmi" a určit sestavení, se kterým chcete testování provést.
• Možnosti sloupců: Pomocí možnosti sloupců můžete spravovat seznam sloupců zobrazených na kartě Spustit. Seznam sloupců, které jsou k dispozici pro výběr, jsou přidružené k testovacím bodům, například Spustit podle, Přiřazený tester, Konfigurace atd.
• Zobrazení na celé obrazovce: Pomocí této možnosti můžete zobrazit obsah celé karty Execute (Spustit) v režimu celé obrazovky.
• Filtrování: Pomocí panelu filtru můžete filtrovat seznam testovacích bodů pomocí polí "název testovacího případu", "přiřazeno", "stav", "výsledek testu", "Tester" a "Konfigurace". Seznam můžete seřadit také kliknutím na záhlaví sloupců.

Možnosti místní nabídky

Místní nabídka v uzlu Testovací bod na kartě Execute (Spustit) nabízí následující možnosti:

• Označit výsledek testu: Stejně jako výše umožňuje rychle označit výsledek testovacích bodů – úspěšný, neúspěšný, blokovaný nebo nepoužitelné.
• Spustit testovací body: Stejně jako výše, umožňuje spouštět testovací případy prostřednictvím test runneru.
• Resetovat test na aktivní: Tato možnost umožňuje resetovat výsledek testu na aktivní, čímž se ignoruje poslední výsledek testovacího bodu.
• Formulář pracovní položky otevřít nebo upravit testovací případ: Tato možnost umožňuje upravit testovací případ pomocí formuláře pracovní položky, ve kterém upravujete pole pracovní položky včetně testovacích kroků.
• Přiřadit tester: Tato možnost umožňuje přiřadit testovací body testerům ke spuštění testu.
• Zobrazit výsledek testu: Tato možnost umožňuje zobrazit nejnovější podrobnosti o výsledku testu, včetně výsledků jednotlivých kroků testu, přidaných komentářů nebo chyb.
• Zobrazit historii provádění: Tato možnost umožňuje zobrazit celou historii provádění vybraného testovacího bodu. Otevře se nová stránka, kde můžete upravit filtry tak, aby zobrazovaly historii provádění nejen vybraného testovacího bodu, ale i celého testovacího případu.

Sestava průběhu Test Plans

Tato předefinované sestava vám pomůže sledovat provádění a stav jedné nebo více Test Plans v projektu. Pokud chcete začít sestavu používat, přejděte na Test Plans > Zprávu o průběhu*.

Tři části sestavy zahrnují následující:

1. Souhrn: Zobrazuje konsolidované zobrazení pro vybrané testovací plány.
2. Trend výsledku: Vykreslí denní snímek, který vám poskytne trendovou spojnici provádění a stavu. Může zobrazit data za 14 dnů (výchozí), 30 dnů nebo vlastní rozsah.
3. Podrobnosti: Tato část umožňuje přejít k podrobnostem podle jednotlivých testovacích plánů a poskytuje důležité analýzy pro jednotlivé sady testů.

Artifacts

Poznámka

Azure DevOps Server 2020 neimportuje informační kanály, které jsou během importu dat v koši. Pokud chcete importovat informační kanály, které jsou v koši, před zahájením importu dat je obnovte z koše.

Licenční výrazy a vložené licence

Při procházení balíčků v sadě Visual Studio teď můžete zobrazit podrobnosti o licencích pro balíčky NuGet uložené v Azure Artifacts. To platí pro licence, které jsou reprezentované pomocí licenčních výrazů nebo vložených licencí. Teď uvidíte odkaz na informace o licenci na stránce podrobností balíčku sady Visual Studio (červená šipka na obrázku níže).

Kliknutím na odkaz přejdete na webovou stránku, kde si můžete prohlédnout podrobnosti o licenci. Toto prostředí je stejné jak pro licenční výrazy, tak pro vložené licence, takže můžete zobrazit podrobnosti o licencích pro balíčky uložené v Azure Artifacts na jednom místě (pro balíčky, které určují informace o licenci a jsou podporovány sadou Visual Studio).

Úlohy zjednodušeného ověřování

Teď se můžete ověřovat u oblíbených správců balíčků ze služby Azure Pipelines pomocí úloh odlehčeného ověřování. Patří sem NuGet, npm, PIP, Twine a Maven. Dříve jste se mohli ověřit u těchto správců balíčků pomocí úloh, které poskytovaly velké množství funkcí, včetně možnosti publikovat a stahovat balíčky. To ale vyžaduje použití těchto úloh pro všechny aktivity, které komunikovaly se správci balíčků. Pokud byste měli vlastní skripty ke spouštění úloh, jako je publikování nebo stahování balíčků, nemohli byste je v kanálu použít. Teď můžete v YAML kanálu používat skripty vlastního návrhu a provádět ověřování pomocí těchto nových odlehčených úloh. Příklad použití npm:

Použití příkazů "ci" a "publish" na tomto obrázku je libovolné. Můžete použít všechny příkazy podporované v Azure Pipelines YAML. To vám umožní mít úplnou kontrolu nad vyvoláním příkazu a usnadňuje používání sdílených skriptů v konfiguraci kanálu. Další informace najdete v dokumentaci k úloze ověřování NuGet, npm, PIP, Twine a Maven .

Vylepšení doby načítání stránky informačního kanálu

S radostí oznamujeme, že jsme zkrátili dobu načítání stránky informačního kanálu. V průměru se časy načítání stránek informačního kanálu snížily o 10 %. U největších informačních kanálů došlo k největšímu zlepšení, když se doba načítání stránky 99. percentilu (doba načítání v nejvyšších 99 % všech informačních kanálů) snížila o 75 %.

Veřejné sdílení balíčků s veřejnými informačními kanály

Balíčky teď můžete vytvářet a ukládat ve veřejných informačních kanálech. Balíčky uložené ve veřejných informačních kanálech jsou dostupné všem uživatelům na internetu bez ověření bez ohledu na to, jestli jsou nebo nejsou ve vaší kolekci, nebo dokonce přihlášení ke kolekci Azure DevOps. Další informace o veřejných informačních kanálech najdete v naší dokumentaci k informačním kanálům nebo přejděte přímo k našemu kurzu pro veřejné sdílení balíčků.

Konfigurace upstreamů v různých kolekcích v rámci tenanta AAD

Teď můžete přidat informační kanál v jiné kolekci přidružené k vašemu tenantovi Azure Active Directory (AAD) jako nadřazený zdroj k vašemu informačnímu kanálu Artefakty. Váš informační kanál může vyhledávat a používat balíčky z informačních kanálů, které jsou nakonfigurované jako nadřazené zdroje, což umožňuje snadné sdílení balíčků napříč kolekcemi přidruženými k vašemu tenantovi AAD. Postup nastavení najdete v dokumentaci.

Použití zprostředkovatele přihlašovacích údajů v Pythonu k ověřování pip a twine s využitím informačních kanálů Azure Artifacts

Teď můžete nainstalovat a použít zprostředkovatele přihlašovacích údajů Pythonu (artifacts-keyring) k automatickému nastavení ověřování pro publikování nebo využívání balíčků Pythonu do nebo z informačního kanálu Azure Artifacts. U poskytovatele přihlašovacích údajů nemusíte nastavovat žádné konfigurační soubory (pip.ini/pip.conf/.pypirc). Při prvním volání pipu nebo twine budete jednoduše procházet tokem ověřování ve webovém prohlížeči. Další informace najdete v dokumentaci.

Informační kanály Azure Artifacts ve Správci balíčků sady Visual Studio

Ve Správci balíčků NuGet sady Visual Studio teď zobrazujeme ikony, popisy a autory balíčků pro balíčky obsluhované z informačních kanálů Azure Artifacts. V minulosti nebyla většina těchto metadat poskytována sadě VS.

Aktualizované prostředí připojení k informačnímu kanálu

Dialogové okno Připojit k informačnímu kanálu je vstupem k používání Azure Artifacts. Obsahuje informace o tom, jak nakonfigurovat klienty a úložiště pro nabízení a načítání balíčků z informačních kanálů v Azure DevOps. Aktualizovali jsme dialogové okno, aby přidalo podrobné informace o nastavení, a rozšířili jsme nástroje, pro které poskytujeme pokyny.

Veřejné informační kanály jsou teď obecně dostupné s podporou upstreamu.

Veřejná verze Preview veřejných informačních kanálů získala skvělé přijetí a zpětnou vazbu. V této verzi jsme rozšířili další funkce na obecnou dostupnost. Teď můžete veřejný informační kanál nastavit jako nadřazený zdroj z privátního informačního kanálu. Konfigurační soubory můžete udržovat jednoduché tak, že budete moct přecházet do privátních informačních kanálů i kanálů vymezených na projekt a z tohoto kanálu.

Create informačních kanálů vymezených na projekt z portálu

Když jsme vydali veřejné informační kanály, vydali jsme také informační kanály omezené na projekt. Dosud se informační kanály v rámci projektu daly vytvářet prostřednictvím rozhraní REST API nebo vytvořením veřejného kanálu a následným nastavením projektu na soukromý. Teď můžete informační kanály v rámci projektu vytvářet přímo na portálu z libovolného projektu, pokud máte požadovaná oprávnění. Ve výběru informačního kanálu se také můžete podívat, které informační kanály jsou projektem a které jsou vymezeny na kolekci.

Vylepšení výkonu npm

Provedli jsme změny v našem základním návrhu, abychom vylepšili způsob, jakým ukládáme a doručujeme balíčky npm v informačních kanálech Azure Artifacts. To nám pomohlo dosáhnout až 10násobného snížení latence u některých z nejvíce používaných rozhraní API pro npm.

Vylepšení přístupnosti

Nasadili jsme opravy, které řeší problémy s přístupností na stránce informačních kanálů. Mezi tyto opravy patří:

• prostředí informačního kanálu Create
• Prostředí globálního nastavení informačního kanálu
• Připojení k prostředí informačního kanálu

Wiki

Bohaté úpravy pro stránky wikiwebu kódu

Dříve jste byli při úpravách stránky wikiwebu kódu přesměrováni do centra Azure Repos pro úpravy. Centrum úložiště v současné době není optimalizované pro úpravy markdownu.

Teď můžete upravit stránku wikiwebu s kódem v editoru vedle sebe uvnitř wikiwebu. Díky tomu můžete pomocí bohatého panelu nástrojů markdownu vytvořit obsah a prostředí pro úpravy bude stejné jako na wikiwebu projektu. I tak můžete zvolit úpravy v repos výběrem možnosti Upravit v repos v místní nabídce.

Create a vložení pracovních položek ze stránky wikiwebu

Když jsme si vyslechli vaši zpětnou vazbu, slyšeli jsme, že používáte wiki k zachycení dokumentů debaty, dokumentů o plánování, nápadů na funkce, dokumentů specifikace a zápisů ze schůzky. Nyní můžete snadno vytvářet funkce a uživatelské scénáře přímo z plánovacího dokumentu, aniž byste opustili stránku wikiwebu.

Pokud chcete vytvořit pracovní položku, vyberte text na stránce wikiwebu, kam chcete pracovní položku vložit, a vyberte Nová pracovní položka. Ušetříte tím čas, protože nemusíte nejdřív vytvořit pracovní položku, přejít na úpravy a pak najít pracovní položku, abyste ji mohli vložit. Omezuje také přepínání kontextu, protože se nedostanete mimo obor wikiwebu.

Další informace o vytvoření a vložení pracovní položky z wikiwebu najdete v naší dokumentaci tady.

Komentáře na stránkách wikiwebu

Dříve jste neměli způsob, jak interagovat s ostatními uživateli wikiwebu uvnitř wikiwebu. Díky tomu byla spolupráce na obsahu a získávání odpovědí na otázky výzvou, protože konverzace musely probíhat prostřednictvím pošty nebo chatových kanálů. S komentáři teď můžete spolupracovat s ostatními přímo v rámci wikiwebu. Pomocí funkcí uživatelů v komentářích můžete @mention upoutat pozornost ostatních členů týmu. Tato funkce dostala prioritu na základě tohoto návrhu lístku. Další informace o komentářích najdete v naší dokumentaci tady.

Skrýt složky a soubory začínající na . ve stromu wikiwebu

Až dosud strom wikiwebu zobrazoval všechny složky a soubory začínající tečkou (.) ve stromu wikiwebu. Ve scénářích wikiwebu kódu to způsobilo, že se složky jako .vscode, které mají být skryté, zobrazily ve stromu wikiwebu. Všechny soubory a složky začínající tečkou teď zůstanou ve wiki stromě skryté, a tím se sníží zbytečné nepotřebné informace.

Tato funkce dostala prioritu na základě tohoto návrhu lístku.

Krátké a čitelné adresy URL stránek wikiwebu

Ke sdílení odkazů na stránku wikiwebu už nemusíte používat víceřádkovou adresu URL. K odebrání parametrů používáme ID stránek v adrese URL, takže je adresa URL kratší a čitelnější.

Nová struktura adres URL bude vypadat takto:

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

Toto je příklad nové adresy URL wiki stránky Vítá vás Azure DevOps :

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

Na základě tohoto lístku návrhu funkcí z Developer Community byla stanovena priorita.

Synchronní posouvání pro úpravy stránek wikiwebu

Úpravy stránek wikiwebu jsou teď jednodušší díky synchronnímu posouvání mezi podoknem úprav a podoknem náhledu. Posouvání na jedné straně automaticky posune druhou stranu a namapuje odpovídající oddíly. Synchronní posouvání můžete zakázat pomocí přepínacího tlačítka.

Poznámka

Stav synchronního přepínače posouvání se ukládá pro jednotlivé uživatele a účet.

Návštěvy stránek wikiwebu

Teď můžete získat přehled o návštěvách stránek wikiwebu. Rozhraní REST API umožňuje přístup k informacím o návštěvách stránky za posledních 30 dnů. Tato data můžete použít k vytváření sestav pro stránky wikiwebu. Kromě toho můžete tato data uložit ve zdroji dat a vytvořit řídicí panely, abyste získali konkrétní přehledy, jako je například n nejobrazovanějších stránek.

Na každé stránce se také zobrazí agregovaný počet návštěv stránek za posledních 30 dnů.

Poznámka

Návštěva stránky je definována jako zobrazení stránky daným uživatelem v 15minutovém intervalu.

Generování sestav

Sestavy selhání a doby trvání kanálu

Metriky a přehledy pomáhají průběžně vylepšovat propustnost a stabilitu kanálů. Přidali jsme dvě nové sestavy, které vám poskytnou přehledy o vašich kanálech.

1. Sestava selhání kanálu zobrazuje rychlost průchodu sestavení a trend selhání. Kromě toho se také zobrazí trend selhání úkolů, abyste mohli získat přehled o tom, která úloha v kanálu přispívá k maximálnímu počtu selhání.

2. Sestava doby trvání kanálu zobrazuje trend doby trvání kanálu. Také ukazuje, které úlohy v kanálu zabírají nejvíce času.

Vylepšení widgetu Výsledky dotazů

Widget výsledků dotazu je jedním z nejoblíbenějších widgetů, a to z dobrého důvodu. Widget zobrazí výsledky dotazu přímo na řídicím panelu a je užitečný v mnoha situacích.

V této aktualizaci jsme zahrnuli mnoho dlouho očekávaných vylepšení:

• Teď můžete vybrat tolik sloupců, kolik chcete ve widgetu zobrazit. Už žádné omezení 5 sloupců!
• Widget podporuje všechny velikosti, od 1x1 do 10x10.
• Když změníte velikost sloupce, šířka sloupce se uloží.
• Widget můžete rozbalit do zobrazení na celou obrazovku. Po rozbalení se zobrazí všechny sloupce vrácené dotazem.

Pokročilé filtrování widgetů pro potenciální zákazníky a dobu cyklu

Čas zájemců a cyklu používají týmy k tomu, aby zjistily, jak dlouho trvá, než práce projde jejich vývojovými kanály a nakonec přinese hodnotu svým zákazníkům.

Doteď widgety času pro zájemce a cyklus nepodporují pokročilá kritéria filtru pro kladení otázek, jako například: "Jak dlouho trvá mému týmu uzavřít položky s vyšší prioritou?"

S touto aktualizací lze na podobné otázky odpovědět filtrováním na plavecké drahě Board.

Zahrnuli jsme také filtry pracovních položek, abychom omezili počet pracovních položek zobrazených v grafu.

Burndown vloženého sprintu s využitím bodů scénáře

Burndown sprintu teď můžete burndown po příbězích. To řeší vaši zpětnou vazbu od Developer Community.

V centru Sprint vyberte kartu Analýza. Pak sestavu nakonfigurujte následujícím způsobem:

1. Výběr backlogu scénářů
2. Select to burndown on Sum of Story Points

Widget Sprint Burndown se vším, o co jste žádali

Nový widget Burndown sprintu podporuje vypalování podle bodů scénáře, počtu úkolů nebo součtu vlastních polí. Můžete dokonce vytvořit burndown sprintu pro funkce nebo náměty. Widget zobrazí průměrnou hodnotu burndownu, dokončeno % a zvětšení rozsahu. Tým můžete nakonfigurovat tak, abyste na stejném řídicím panelu mohli zobrazit burndowny sprintů pro více týmů. Se všemi tak skvělými informacemi, které můžete zobrazit, vám umožníme změnit velikost řídicího panelu až 10 × 10.

Pokud si to chcete vyzkoušet, můžete ho přidat z katalogu widgetů nebo tak, že upravíte konfiguraci existujícího widgetu Sprint Burndown a zaškrtnete políčko Vyzkoušet novou verzi.

Poznámka

Nový widget používá analýzu. Starší verze Sprint Burndown jsme ponechali pro případ, že nemáte přístup k Analýzám.

Miniatura burndownu vloženého sprintu

Sprint Burndown je zpátky! Před několika sprinty jsme odebrali kontextový burndown sprintu z hlaviček Sprint Burndown a Taskboard. Na základě vaší zpětné vazby jsme vylepšili a znovu zavedli miniaturu burndownu sprintu.

Kliknutím na miniaturu se okamžitě zobrazí větší verze grafu s možností zobrazit celou sestavu na kartě Analýza. Všechny změny provedené v celé sestavě se projeví v grafu zobrazeném v záhlaví. Teď ho tedy můžete nakonfigurovat na základě scénářů, bodů scénáře nebo počtu úkolů, nikoli jen zbývajícího množství práce.

Create řídicího panelu bez týmu

Teď můžete vytvořit řídicí panel, aniž byste ho přidružoval k týmu. Při vytváření řídicího panelu vyberte typ Řídicí panel projektu .

Řídicí panel projektu se podobá řídicímu panelu týmu s tím rozdílem, že není přidružený k týmu a můžete se rozhodnout, kdo ho může upravovat nebo spravovat. Stejně jako řídicí panel týmu je viditelný všem uživatelům v projektu.

Všechny widgety Azure DevOps, které vyžadují týmový kontext, byly aktualizovány tak, aby vám v jejich konfiguraci mohly vybrat tým. Tyto widgety můžete přidat na řídicí panely projektu a vybrat požadovaný tým.

Poznámka

U vlastních widgetů nebo widgetů třetích stran předá řídicí panel projektu těmto widgetům výchozí kontext týmu. Pokud máte vlastní widget, který závisí na kontextu týmu, měli byste aktualizovat konfiguraci, abyste mohli vybrat tým.

---

Zpětná vazba

Chceme znát váš názor. Můžete nahlásit problém nebo poskytnout nápad a sledovat ho prostřednictvím Developer Community a získat rady na Webu Stack Overflow.

---

Začátek stránky