Poznámky k vydání Azure DevOps Server 2020

Komunita vývojářů | Požadavky na systém | Licenční podmínky | DevOps Blog | Hodnoty hash SHA-1

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

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

Přímý upgrade na Azure DevOps Server je podporován z Azure DevOps Serveru 2020, Azure DevOps Serveru 2019 nebo Team Foundation Serveru (TFS) 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ěkolik kroků. Další informace najdete v tématu Instalace a konfigurace Azure DevOps v místním prostředí.

---

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

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

Azure DevOps Server 2020 zpracovává uchovávání sestavení odlišně na základě zásad uchovávání sestavení na úrovni sestavovacího kanálu. Některé konfigurace zásad vedou k odstranění spuštění pipeline po upgradu. Po upgradu se neodstraní spuštění kanálu, která byla ručně zachována nebo jsou zachovaná verzí.

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

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

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

• Rozšířili jsme seznam povolených znaků pro úlohy PowerShellu v rámci validace parametrů argumentů pro povolení argumentů úloh prostředí shellu.

Poznámka:

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

Instalace oprav

Důležité

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

File	SHA-256 hash
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 nastavená v kanálech, které používají ovlivněné úlohy.

• V klasickém prostředí:

  Definujte proměnnou na kartě proměnné v pipeline.

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Důležité

Vydali jsme aktualizace agenta Azure Pipelines s aktualizací Patch 4 vydané 12. září 2023. Pokud jste aktualizace agenta nenainstalovali, jak je popsáno v poznámkách k verzi pro opravu Patch 4, doporučujeme nainstalovat tyto aktualizace před instalací 5. Nová verze agenta po instalaci 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.

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

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

• CVE-2023-33136: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu serveru Azure DevOps
• CVE-2023-38155: Ohrožení zabezpečení spočívající ve zvýšení oprávnění serveru Azure DevOps a Team Foundation Serveru

Důležité

Před použitím opravy do produkčního 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í řady kroků.

Instalace oprav

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

Aktualizace agenta Azure Pipelines

1. Stáhnout agenta z: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. K nasazení agenta použijte kroky popsané v dokumentaci k místním agentům Windows .  

Poznámka:

Aby se zabránilo snížení agenta, musí být AZP_AGENT_DOWNGRADE_DISABLED nastaveno na hodnotu „true“. Ve Windows se dá v příkazovém řádku pro správu použít následující příkaz, po kterém následuje restartování. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurace TFX

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

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 nastavená v kanálech, které používají ovlivněné úlohy.

• V klasickém prostředí:

  Definujte proměnnou na kartě proměnné v pipeline.

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Datum vydání Azure DevOps Server 2020 Update 0.2 Patch 3: 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á způsobovala narušení odesílání balíčků při upgradu z verze 2018 nebo starší.

Datum vydání aktualizace Azure DevOps Serveru 2020 Update 0.2 Patch 2: 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á způsobovala narušení odesílání balíčků při upgradu z verze 2018 nebo starší.

Datum vydání 1 opravy Azure DevOps Server 2020 Update 0.2: 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í v nástrojích pro výběr identity dialogového okna zabezpečení.
• Opravte problém s filtrem "Požadováno členem skupiny" v nastavení webhooku.
• Opravte chybu sestavení Gated check-in, když nastavení Organizace pro kanál měla rozsah autorizace úloh nastavený na Omezení autorizace úloh na aktuální projekt pro kanály, které nejsou pro vydání.

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

Azure DevOps Server 2020.0.2 představuje opravy chyb. Azure DevOps Server 2020.0.2 můžete nainstalovat přímo nebo upgradovat z Azure DevOps Serveru 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 asi tři týdny od této verze. Tady najdete seznam aktuálně podporovaných verzí pro import.

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

• Nelze přeskočit frontu sestavení pomocí tlačítka „Spustit další“. Dříve bylo tlačítko 'Spustit další' povoleno pouze pro správce kolekce projektů.

• Po deaktivaci uživatelského účtu v Active Directory zrušte všechny osobní přístupové tokeny.

Datum vydání opravného balíčku 9 pro Azure DevOps Server 2020.0.1: 26. ledna 2022

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

• Při použití @mention ovládacího prvku v pracovní položce se neposílala e-mailová oznámení.
• Oprava chyby TF400813 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.
• Opravte problém se stránkou souhrnu přehledu projektu, která se nenačítá.
• Vylepšení synchronizace uživatelů služby Active Directory
• Vyřešili jsme chybu zabezpečení Elasticsearch odebráním třídy jndilookup z binárních souborů log4j.

Instalační kroky

1. Aktualizujte server pomocí Patche 9.
2. Zkontrolujte hodnotu registru na adrese HKLM:\Software\Elasticsearch\Version. Pokud tam hodnota registru není, přidejte řetězcovou hodnotu a nastavte verzi 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í, jako je: Nelze se připojit ke vzdálenému serveru. Nezavírejte okno, protože aktualizace provádí opakování, 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 9..
2. Zkontrolujte hodnotu registru na adrese HKLM:\Software\Elasticsearch\Version. Pokud tam hodnota registru není, přidejte řetězcovou hodnotu a nastavte verzi na 5.4.1 (Název = Verze, hodnota = 5.4.1).
3. Zkopírujte obsah složky s názvem zip umístěný na C:\Program Files\{TFS Version Folder}\Search\zip do složky vzdálených souborů Elasticsearch.
4. Spusťte Configure-TFSSearch.ps1 -Operation update na počítači serveru Elasticsearch.

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Datum vydání pro Patch 8 Azure DevOps Server 2020.0.1: 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 s zkrácením protokolů konzoly, pokud je na řádku více identických odkazů
• Problém s vyhodnocením pravidel NOTSAMEAS při definování více pravidel NOTSAMEAS pro pole

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

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

• Dříve mohl Azure DevOps Server vytvářet připojení pouze k GitHub Enterprise Serveru. Díky této opravě můžou správci projektů vytvářet připojení mezi Azure DevOps Serverem 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. Zpráva o provedení testu zobrazovala chybného uživatele ve výsledcích.
• Opravte problém se stránkou souhrnu přehledu projektu, která se nenačítá.
• Opravte problém s neodesílanými e-maily, abyste potvrdili upgrade produktu.

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

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

• Řešení problému se selháním při stahování a nahrávání artefaktů.
• Vyřešte problém s nekonzistentními daty výsledků testů.

Datum vydání 5 opravy Azure DevOps Serveru 2020.0.1: 10. srpna 2021

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

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

Datum vydání 4 opravy Azure DevOps Serveru 2020.0.1: 15. června 2021

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

• Opravte problém s importem dat. Import dat trval dlouhou dobu pro zákazníky, kteří mají spoustu zastaralých testovacích případů. Důvodem byly odkazy, které zvětšily velikost tbl_testCaseReferences tabulky. V této opravě jsme odebrali odkazy na zastaralé testovací případy, abychom urychlili proces importu dat.

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

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která odstraňuje následující opravy.

• Nekonzistentní data výsledků testů 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: Spuštění 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ď řekne, že byla nainstalována oprava, nebo že není nainstalovaná.

• 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 nainstalovaný ve výchozím nastavení do c:\Program Files\Azure DevOps Server 2020. Po instalaci Azure DevOps Serveru 2020.0.1 Patch 3 bude verze 18.170.31228.1.

Datum vydání Azure DevOps Server 2020.0.1 Patch 2: 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 budete na verzi 2020.0.1, nainstalujte Azure DevOps Server 2020.0.1 Patch 2.

Vydali jsme opravu pro Azure DevOps Server 2020.0.1, která odstraňuje následující opravy.

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

Pokud chcete implementovat opravy této záplaty, musíte postupovat takto pro obecnou instalaci záplat, instalace úloh AzureResourceGroupDeploymentV2 a AzureResourceManagerTemplateDeploymentV3.

Obecná instalace oprav

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

Ověření instalace

• Možnost 1: Spuštění 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ď řekne, že byla nainstalována oprava, nebo že není nainstalovaná.

• 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 nainstalovaný ve výchozím nastavení do c:\Program Files\Azure DevOps Server 2020. Po instalaci Azure DevOps Serveru 2020.0.1 Patch 2 bude verze 18.170.31123.3.

Instalace úlohy AzureResourceGroupDeploymentV2

Poznámka:

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

Install

1. Extrahujte balíček AzureResourceGroupDeploymentV2.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 (který je součástí stažení Node.js) vhodné pro váš operační systém.

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. Vytvořte osobní přístupový token 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. Na příkazovém řádku spusťte následující příkaz. Po zobrazení požadavku 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 extrahovaného souboru .zip z kroku 1.

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

Instalace úlohy AzureResourceManagerTemplateDeploymentV3

Poznámka:

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

Install

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

2. Stáhněte a nainstalujte Node.js 14.15.1 a npm (obsaženo ve stažení Node.js) dle potřeby vašeho zařízení.

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. Vytvořte osobní přístupový token 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. Na příkazovém řádku spusťte následující příkaz. Po zobrazení požadavku 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 extrahovaného souboru .zip z kroku 1.

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

Datum vydání 1 opravy Azure DevOps Serveru 2020.0.1: 9. února 2021

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

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

Datum vydání 3 opravy Azure DevOps Serveru 2020: 9. února 2021

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

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

Datum vydání Azure DevOps Serveru 2020.0.1: 19. ledna 2021

Azure DevOps Server 2020.0.1 představuje opravy chyb. Azure DevOps Server 2020.0.1 můžete nainstalovat přímo nebo upgradovat z existující instalace. Podporované verze upgradu jsou Azure DevOps Server 2020, Azure DevOps Server 2019 a Team Foundation Server 2012 nebo novější.

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

• Vyřešte problém s upgradem z Azure DevOps Serveru 2019, kdy po upgradu může přestat fungovat proxy Git.
• Oprava výjimky System.OutOfMemoryException pro kolekce jiné než ENU ve verzích před Team Foundation Server 2017 při upgradu na Azure DevOps Server 2020. Vyřeší problém nahlášený v tomto lístku zpětné vazby komunity vývojářů.
• Selhání údržby způsobené chybějícím Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Vyřeší problém nahlášený v tomto lístku zpětné vazby komunity vývojářů.
• Oprava chyby neplatného názvu sloupce v Analytics při upgradu na Azure DevOps Server 2020 Vyřeší problém nahlášený v tomto lístku zpětné vazby komunity vývojářů.
• 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í opravy 2 Azure DevOps Serveru 2020: 12. ledna 2021

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

• Podrobnosti o testovacím spuštění nezobrazují podrobnosti testovacího kroku pro testovací data migrovaná pomocí migrace OpsHubu.
• Výjimka při inicializaci Microsoft.TeamFoundation.TestManagement.Server.TCMLogger
• Neudržované buildy se okamžitě odstraní po migraci na Azure DevOps Server 2020.
• Oprava výjimky zprostředkovatele dat

Datum opravy 1 Azure DevOps Serveru 2020: 8. prosince 2020

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

• CVE-2020-17145: Ohrožení zabezpečení z hlediska falšování identity v Azure DevOps Serveru a Team Foundation Services

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

Azure DevOps Server 2020 představuje opravy chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2020 RC2 dříve vydaném.

Poznámka:

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

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

Pokud chcete spustit opravu, přejděte na Settings -> Apps & Features počítač nebo virtuální počítač Azure DevOps Server 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 Serveru 2020 RC2: 11. srpna 2020

Azure DevOps Server 2020 RC2 je kumulativní aktualizace oprav chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2020 RC1, které byly vydány dříve.

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

Znovu jsme vydali Azure DevOps Server 2020 RC1, abychom opravili tento lístek zpětné vazby komunity vývojářů.

Dříve po upgradu z Azure DevOps Serveru 2019 Update 1.1 na Azure DevOps Server 2020 RC1 jste nemohli zobrazit soubory v Repos, Pipelines a Wiki webového uživatelského rozhraní. V této oblasti stránky došlo k chybové zprávě s informací, ž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 vyřešili. Další informace najdete v blogovém příspěvku .

Datum vydání Azure DevOps Serveru 2020 RC1: 30. června 2020

Shrnutí novinek v Azure DevOps Serveru 2020

Azure DevOps Server 2020 představuje mnoho nových funkcí. Mezi nejdůležitější body 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í souhrnu v backlogu boards
• Přidejte filtr "Nadřazená pracovní položka" na panel úkolů a do backlogu sprintu
• Nové webové uživatelské rozhraní pro cílové stránky Azure Repos
• Správa zásad větví mezi repozitáři
• Stránka nového testovacího plánu
• Bohaté možnosti úprav pro stránky wiki s kódem
• Sestavy selhání potrubí a doby trvání

Můžete také přejít na jednotlivé části a zobrazit všechny nové funkce pro každou službu:

• Obecné
• Tabule
• Repos
• Pipelines
• Testovací plány
• Artefakty
• Wiki
• Podávání zpráv

---

General

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 vylepšit rozšíření a přidat další příkazy. S radostí oznamujeme, že rozšíření je obecně dostupné.

Další informace o Azure DevOps CLI najdete v dokumentaci.

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

Teď můžete k nasazení webových aplikací Azure pro Windows z Centra nasazení použít ověřování založené na profilu publikování. Pokud máte oprávnění k nasazení do webové aplikace Azure pro Windows pomocí jejího profilu publikování, budete moct nastavit pipeline pomocí tohoto profilu v pracovních postupech Deployment Center.

Boards

Přidat filtr pro nadřazenou pracovní položku na panel úloh a do backlogu sprintu

Do panelu Sprintu i backlogu sprintu jsme přidali nový filtr. To umožňuje filtrovat položky backlogu úrovně požadavků (první sloupec vlevo) podle jejich nadřazeného objektu. Na následujícím snímku obrazovky jsme například vyfiltrovali zobrazení tak, aby zobrazovalo pouze uživatelské příběhy, u kterých je nadřazeným prvkem „Moje velká funkce“.

Zlepšení prostředí pro zpracování chyb – požadovaná pole pro chybu nebo úlohu

Pokud jste pracovní položku přesunuli z panelu Kanbanu z jednoho sloupce do jiného, kde se pravidla polí aktivovala změnou stavu, zobrazí 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 možnosti, takže teď můžete kliknout na červenou chybovou zprávu a zobrazit podrobnosti o chybě, aniž byste museli otevřít samotnou pracovní položku.

Průběžné znovunačtení pracovních položek

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

Správa cest iterací a oblastí z příkazového řádku

Cesty k iteraci a oblasti teď můžete spravovat z příkazového řádku pomocí az boards iteration příkazů a az boards area příkazů. Můžete například nastavit a spravovat iterační a plošné cesty interaktivně z rozhraní příkazového řádku nebo automatizovat celé nastavení pomocí skriptu. Další podrobnosti o příkazech a syntaxi najdete v dokumentaci zde.

Sloupec nadřazeného objektu pracovní položky jako možnost sloupce

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

Změna procesu používaného projektem

Nástroje by se měly měnit stejně jako váš tým. Teď můžete své projekty přepnout z jakékoli předpolohované šablony procesu na jakýkoli jiný předefinovaný proces. Projekt můžete například změnit z Agilního na Scrum nebo Basic na Agilní. Úplnou podrobnou dokumentaci najdete tady.

Skrýt vlastní pole z 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 je užitečné pro sledování dalších polí při integraci s jinými systémy.

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

Nemůžete opravit, co nevidíte. Proto chcete pečlivě sledovat stav a kondici jejich pracovních procesů. Díky těmto sestavá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í vývojový diagram (CFD) a Rychlost vývoje. Sestavy můžete zobrazit na nové kartě analýzy.

Metriky, jako je burndown sprintu, tok práce a rychlost týmu, poskytují přehled o pokroku vašeho týmu a pomáhají zodpovědět otázky, jako jsou:

• Kolik práce zbývá v tomto sprintu? Jsme na dobré cestě k dokončení?
• Jaký krok procesu vývoje trvá nejdéle? Můžeme s tím něco udělat?
• Na základě předchozích iterací bychom měli naplánovat, kolik práce je třeba na další sprint.

Poznámka:

Dříve zobrazené grafy v záhlaví byly nahrazeny těmito vylepšenými výkazy.

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

• Burndown chart najdete v centru Sprints .

  

• Sestavy CFD a Velocity jsou přístupné ze záložky Analýzy v části Panely a nevyřízené úkoly kliknutím na příslušnou kartu.

  

Díky novým zprávám máte lepší kontrolu nad vaším týmem a více informací o něm. Tady je několik příkladů:

• Sestavy Sprint Burndown a Velocity lze 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. Takže pokud váš tým obvykle stráví první den plánováním sprintu, můžete upravit graf tak, aby to odrážel.
• Graf Burndown teď obsahuje vodoznak zobrazující víkendy.
• Sestava CFD vám umožňuje odstranit sloupce na tabuli, například vývoj, abyste se mohli lépe soustředit 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 nyní možné sledovat pro všechny úrovně backlogu. Například nyní můžete přidat jak funkce, tak epiky, zatímco dřívější graf podporoval pouze požadavky. Tady je příklad zprávy o rychlosti pro posledních 6 iterací zásobníku 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 panelu úloh. Teď můžete sloupce přidávat, odebírat, přejmenovávat a měnit jejich pořadí.

Pokud chcete nakonfigurovat sloupce na panelu Úloh, přejděte na Možnosti sloupců.

Tato funkce byla upřednostněna na základě návrhu komunity vývojářů.

Přepínač pro 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ý, všechny podřízené položky se zobrazí v dokončeném stavu. Když je přepínač vypnutý, všechny položky v dokončeném stavu budou skryty z backlogu.

Naposledy zobrazené značky při označování pracovní položky

Při označování pracovní položky se nyní možnost automatického dokončování zobrazí až pět vašich nejčastěji používaných značek. To vám usnadní přidání správných informací do pracovních položek.

Pravidla pro členství ve skupině, která jsou jen pro čtení a povinná

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

Přizpůsobení hodnot systémových rozevíracích seznamů

Nyní můžete upravit hodnoty pro libovolný rozevírací seznam systému (s výjimkou pole důvodu), jako je závažnost, aktivita, priorita atd. Vlastní nastavení rozevíracího seznamu jsou vymezená tak, abyste mohli spravovat různé hodnoty pro stejné pole pro každý typ pracovní položky.

Nový parametr adresy URL pracovní položky

Sdílejte odkazy na pracovní položky v kontextu panelu nebo backlogu pomocí našeho nového parametru URL pracovní položky. Nyní můžete otevřít dialogové okno pracovní položky na panelu, v backlogu nebo v prostředí sprintu tak, že k adrese URL připojíte parametr ?workitem=[ID].

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

Zmínit lidi, pracovní položky a pull requesty v textových polích

Když jsme naslouchali vaší zpětné vazbě, slyšeli jsme, že jste chtěli mít možnost zmínit lidi, pracovní položky a pull requesty v oblasti popisu pracovní položky (a v dalších polích HTML) a ne jenom v komentářích. Někdy spolupracujete s někým na pracovní položce nebo chcete v popisu pracovní položky zvýraznit žádost o přijetí změn, ale nemáte způsob, jak tyto informace přidat. Teď se můžete zmínit o lidech, pracovních položkách a pull requestech ve všech dlouhých textových polích pracovní položky.

Tady si můžete prohlédnout příklad.

• 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 generuje e-mailová oznámení stejně jako u komentářů.
• 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 PR, přidejte ! následované ID nebo názvem vašeho pull requestu.

Reakce na diskuzní komentáře

Jedním z našich hlavních cílů je zvýšit spolupráci na pracovních úkolech v týmech. Nedávno jsme provedli hlasování na Twitteru , abychom zjistili, jaké funkce spolupráce chcete v diskuzích o pracovní položce. Přidávání reakcí na komentáře vyhrálo hlasování, takže je přidáváme! Tady jsou výsledky hlasování na Twitteru.

Můžete přidat reakce na jakýkoli komentář a existují dva způsoby, jak přidat vaše reakce – ikonu smajlíka v pravém horním rohu libovolného komentáře, stejně jako v dolní části komentáře vedle existujících reakcí. Můžete přidat všech šest reakcí, pokud chcete, nebo jen jeden nebo dva. Pokud chcete reakci odebrat, klikněte na reakci v dolní části komentáře a odebere se. Níže vidíte zkušenosti s přidáním reakce a také to, jak reakce vypadají na komentáři.

Přichyťte sestavy Azure Boards na řídicí panel

V aktualizaci Sprint 155 jsme zahrnuli aktualizované verze sestav CFD a Velocity. Tyto sestavy jsou k dispozici na kartě Analýza panelů a backlogů. Teď můžete sestavy připnout přímo na řídicí panel. Pokud chcete připnout sestavy, najeďte myší na sestavu, vyberte menu s třemi tečkami "..." a kopírujte na dashboard.

Sledujte postup nadřazených položek pomocí funkce souhrnu v backlogu Boards.

Souhrnné sloupce zobrazují indikátory průběhu a/nebo součty číselných polí nebo následnických položek v hierarchii. Položky potomků odpovídají všem podřízeným položkám v hierarchii. Jeden nebo více souhrnných sloupců lze přidat do backlogu produktu nebo portfolia.

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áslednických položek, které byly uzavřeny. Podřízené položky pro náměty zahrnují všechny podřízené funkce a podřízené nebo podřízené pracovní položky. Podřízené položky pro funkce zahrnují všechny podřízené uživatelské scénáře a podřízené pracovní položky.

Aktivní aktualizace panelu úloh

Vaše tabule úkolů se teď automaticky aktualizuje, když dojde ke změnám. Když ostatní členové týmu přesunou nebo změní pořadí karet na panelu úkolů, vaše panel se automaticky aktualizuje o tyto změny. Abyste viděli nejnovější změny, nemusíte už stisknout klávesu F5.

Podpora vlastních polí ve sběrných sloupcích

Souhrn je teď možné provést u libovolného pole, včetně vlastních polí. Při přidávání sloupce Souhrn můžete stále vybrat sloupec Souhrn ze rychlého seznamu, nicméně pokud chcete provést souhrn pro číselná pole, která nejsou součástí výchozí šablony procesu, můžete nakonfigurovat vlastní sloupec následujícím způsobem:

1. V backlogu klikněte na „Možnosti sloupce“. Potom na panelu klikněte na Přidat Rollup sloupec a nakonfigurujte vlastní Rollup.

   

2. Vyberte mezi indikátorem průběhu a celkovým 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 Pro součet budete muset vybrat pole, které chcete sumarizovat.
5. Tlačítko OK vás vrátí zpět na panel možností sloupců, kde můžete změnit pořadí nového vlastního sloupce.

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

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 konkrétní pole pro vývojáře. Další podrobnosti najdete v této dokumentaci.

Vlastní nastavení upozornění pro pracovní položky

Udržování aktuálních pracovních položek relevantních pro vás nebo váš tým je neuvěřitelně důležité. Pomáhá týmům spolupracovat a sledovat projekty a zajistit, aby se zapojily všechny správné strany. Různé zúčastněné strany však mají různé úrovně investic do různých úsilí a věříme, že by se mělo promítnout do vaší schopnosti sledovat stav pracovní položky.

Pokud byste 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 a všech změnách provedených v pracovní položce. Po zvážení vaší zpětné vazby děláme proces sledování pracovních položek 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 na 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í. Nejdřív se můžete úplně odhlásit. Za druhé můžete mít plný odběr, přičemž získáte oznámení o všech změnách pracovních úkolů. 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 se rozptylovat každou jednotlivou 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 důležité úkoly.

Propojit pracovní položky k nasazením

S radostí vydáváme kontrolu nasazení ve formuláři pro pracovní položky. Tento ovládací prvek propojuje pracovní úlohy s vydáním a umožňuje snadno sledovat, kde byla pracovní úloha nasazena. Další informace najdete v této dokumentaci.

Import pracovních položek ze souboru CSV

Doteď 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 této dokumentaci.

Přidání nadřazeného pole ke kartám pracovních položek

Nadřazený kontext je nyní dostupný na tabuli Kanban jako nové pole na kartách pracovních položek. Teď můžete přidat pole Nadřazený do karet a obejít potřebu použití alternativních řešení, jako jsou značky a předpony.

Přidání rodičovského pole k backlogu a dotazům

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

Repos

Metriky pokrytí kódu a politika větve pro pull requesty

Můžete nyní vidět metriky pokrytí kódu pro změny v zobrazení pull requestu (PR). 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 pull requestu. Můžete zobrazit detaily pokrytí pro každý řádek kódu, který se změnil v zobrazení změn souborů.

Vlastníci úložiště teď navíc můžou nastavit zásady pokrytí kódu a zabránit sloučení velkých a neotestovaných změn do větve. Požadované prahové hodnoty pokrytí mohou být definovány v azurepipelines-coverage.yml souboru nastavení, který je umístěn v kořenovém adresáři úložiště. Zásady pokrytí mohou být stanoveny pomocí existující funkce konfigurace zásad větve pro další služby v Azure Repos.

Filtrování komentářových oznámení ze žádostí o přijetí změn

Komentáře v pull requests mohou často generovat velký šum kvůli oznámením. Přidali jsme vlastní předplatné, které vám umožňuje filtrovat, ke kterým oznámením komentářů se přihlásíte k odběru podle stáří komentářů, komentátora, odstraněného komentáře, zmíněných uživatelů, autora pull requestu, 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 do nastavení uživatele.

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

Nyní můžete vytvářet webhooky pro komentáře v pull requestech na základě repozitáře a cílové větve.

Zásady pro blokování souborů s konkrétními vzory

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

Řešení pracovních položek pomocí zápisů s využitím klíčových slov

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

Granularita pro automatické revize

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

Použijte ověřování založené na účtu služby k připojení k AKS

Dříve jsme při konfiguraci služby Azure Pipelines z centra nasazení AKS použili připojení Azure Resource Manageru. Toto připojení mělo přístup k celému clusteru, namísto pouhého přístupu k oboru názvů, pro který byl pipeline nakonfigurovaný. V rámci této aktualizace budou naše pipeliney používat ověřování na základě služebního účtu pro připojení ke clusteru, což zajistí přístup pouze k namespace přidruženému k pipeline.

Zobrazení náhledu souborů Markdown v pull requestu vedle sebe

Teď si můžete pomocí nového tlačítka Náhled prohlédnout, jak bude soubor Markdown vypadat. Kromě toho můžete zobrazit úplný obsah souboru v porovnání vedle sebe kliknutím na tlačítko Zobrazit.

Vypršení platnosti zásad pro manuální buildy

Zásady prosazují standardy kvality kódu a řízení změn vašeho týmu. Dříve jste mohli nastavit zásady vypršení platnosti sestavení pro automatizované buildy. Nyní můžete nastavit zásady pro vypršení platnosti i u ručních sestavení.

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

Správci teď můžou nastavit zásadu push, aby se zabránilo vložení změn do úložiště, u kterého e-mail autora commitu neodpovídá zadanému vzoru.

Tato funkce byla upřednostněna na základě návrhu komunity vývojářů , aby poskytovala podobné prostředí. Budeme i nadále udržovat hlášenku otevřenou a vyzvat uživatele, aby nám řekli, jaké další typy push politik by rádi viděli.

Označit soubory v pull requestu jako zkontrolované

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

Soubor můžete označit jako zkontrolovaný pomocí rozevírací nabídky vedle názvu souboru nebo najetím myší a kliknutím na název souboru.

Poznámka:

Tato funkce je určená pouze ke sledování vašeho pokroku při přezkoumání pull requestu. Nepředstavuje hlasování o pull requestech, a tyto značky budou viditelné pouze pro revidenta.

Tato funkce byla upřednostněna na základě návrhu komunity vývojářů.

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

Teď si můžete vyzkoušet naše nové moderní, rychlé a mobilní cílové stránky v Azure Repos. Tyto stránky jsou k dispozici jako cílové stránky Nových repozitářů. Cílové stránky zahrnují všechny stránky kromě podrobností o pull requestu, podrobností o commitu a porovnání větví.

web

Mobilní zařízení

Správa zásad větvení napříč ú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ž možnost nastavit zásady na úrovni projektu existuje v rozhraní REST API, nebylo pro ni žádné uživatelské rozhraní. Správci teď můžou nastavit zásady pro určitou větev nebo výchozí větev ve všech úložištích v projektu. Například správce může požadovat minimálně dva kontrolory pro všechny pull requesty do hlavní větve každého úložiště v rámci jejich projektu. Funkci Přidat ochranu větví najdete v Nastavení projektu Repos.

Nové konverzní stránky na webové platformě

Aktualizovali jsme uživatelské prostředí cílových stránek Repos, aby bylo moderní, rychlé a mobilní. Tady jsou dva příklady stránek, které byly aktualizovány, budeme v budoucích aktualizacích i nadále aktualizovat další stránky.

Webové prostředí:

Mobilní prostředí:

Podpora jazyka Kotlin

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

Vlastní odběr oznámení pro konceptní pull requesty

Pokud chcete snížit počet e-mailových oznámení z žá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 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á schopnost reagovat na žádosti o přijetí změn

Pokud máte k revizi mnoho žádostí o přijetí změn, může být pochopení, kde byste měli nejprve provést nějakou akci, obtížné. Pokud chcete zlepšit akceschopnost žádosti o přijetí změn, nyní můžete na stránce se seznamem žádostí o přijetí změn vytvořit několik vlastních dotazů s několika novými filtrovacími možnostmi, například podle stavu konceptu. Tyto dotazy vytvoří samostatné a sbalitelné oddíly na stránce pull requestu, které doplní stávající oddíly "Vytvořeno mnou" a "Přiřazeno mně". Můžete také odmítnout kontrolu žádosti o sloučení, ke které jste byli přidáni v nabídce Hlasování nebo v kontextové nabídce na stránce se seznamem žádostí o sloučení. Ve vlastních oddílech se teď zobrazí samostatné karty pro pull requesty, u kterých jste provedli revizi nebo odmítli provedení revize. Tyto vlastní dotazy budou fungovat napříč úložišti na kartě Moje pull requesty na domovské stránce sbírky. Pokud se chcete vrátit k pull requestu, můžete jej označit příznakem, a ten se poté objeví v horní části vašeho seznamu. Nakonec budou žádosti o přijetí změn, které jsou nastavené na automatické dokončení, označeny štítkem s nápisem "Automatické dokončení" v seznamu.

Pipelines

Kanály s více fázemi

Pracujeme na aktualizovaném uživatelském prostředí pro správu kanálů. Díky těmto aktualizacím je zkušenost s pipelines moderní a konzistentní se směrem Azure DevOps. Kromě toho tyto aktualizace spojují klasické kanály buildů a kanály YAML s více fázemi do jediného prostředí. Je přívětivý pro mobilní zařízení a přináší různá vylepšení způsobu správy kanálů. Můžete přejít k podrobnostem a zobrazit podrobnosti kanálu, podrobnosti o spuštění, analýzu kanálů, podrobnosti úlohy, protokoly a další.

Nové prostředí zahrnuje následující možnosti:

• zobrazení a správa více fází
• schválení spuštění kanálu
• Posuňte se úplně zpět v protokolech, zatímco pipeline stále probíhá.
• stav kanálu pro každou větev

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

S radostí poskytujeme funkce CD pro Azure Pipelines YAML. Nyní nabízíme jednotné prostředí YAML, abyste mohli nakonfigurovat jednotlivé potoky tak, aby prováděly CI, CD nebo obojí. Funkce YAML CD přináší několik nových pokročilých funkcí, které jsou k dispozici pro všechny kolekce pomocí kanálů YAML s více fázemi. Mezi nejdůležitější body 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 aplikací pro spolupráci
• Aktualizace uživatelského rozhraní pro připojení služeb
• Prostředky v kanálech YAML

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

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

Aktualizovali jsme uživatelské prostředí pro správu proměnných pipeline v editoru YAML. Už nemusíte přejít do klasického editoru, abyste mohli přidávat nebo aktualizovat proměnné v kanálech YAML.

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

Zpracování čekajících schválení bylo zjednodušeno. Dříve bylo možné schválit vydání ze stránky podrobností vydání. Nyní můžete schvalovat vydané verze přímo z centra Release Hub.

Vylepšení při seznamování s řetězci

Častým požadavkem v průvodci pro začátečníky byla možnost přejmenovat vygenerovaný soubor. V současné době je uložen jako azure-pipelines.yml v kořenovém adresáři vašeho repozitáře. Před uložením kanálu teď můžete tento soubor aktualizovat na jiný název nebo umístění.

Nakonec budeme mít větší kontrolu při odevzdávání azure-pipelines.yml souboru do jiné větve, protože se můžete rozhodnout přeskočit vytvoření pull requestu z této větve.

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

Přidali jsme náhled, ale nespouštíme režim pro kanály YAML. Teď můžete vyzkoušet YAML pipelinu, aniž byste ji museli commitovat do úložiště či spouštět. S ohledem na existující potrubí a volitelný nový YAML obsah vám toto nové API vrátí úplné YAML potrubí. V budoucích aktualizacích se toto rozhraní API použije 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 můžete pomocí editoru uživatelského rozhraní určit naplánovanou aktivační událost pro kanály YAML. V této verzi můžete naplánovat sestavení pomocí syntaxe cron v souboru YAML a využít následující výhody:

1. Konfigurace jako kód: Plány můžete sledovat ve spojení s vaším pipeline jako součást kódu.
2. Při definování plánů máte více výrazové schopnosti než to, co jste byli schopni s uživatelským rozhraním. Například je jednodušší zadat jeden plán, který se spustí každou hodinu.
3. Oborový standard: Mnoho vývojářů a správců už zná syntaxi cron.

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 vám poskytne náhled nadcházejících několika naplánovaných spuštění kanálu, které vám pomůžou diagnostikovat chyby s plány cron.

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

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

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

Nové uživatelské prostředí bude při této aktualizaci ve výchozím nastavení zapnuté . Stále budete mít možnost odhlásit se z verze Preview.

Poznámka:

Plánujeme zavést sdílení připojení služeb mezi projekty jako novou funkci. Další podrobnosti o prostředí sdílení a rolích zabezpečení najdete tady.

Přeskočení fází v pipelině YAML

Když spustíte ruční spuštění, můžete někdy chtít přeskočit několik fází kanálu. Pokud například nechcete nasazovat 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ď to můžete udělat pomocí kanálů YAML.

Aktualizovaný panel kanálu spuštění zobrazí seznam fází ze souboru YAML a máte možnost přeskočit jednu nebo více těchto fází. Při vynechání fází musíte postupovat opatrně. Pokud například první fáze vytvoří určité artefakty potřebné pro následující fáze, neměli byste přeskočit první fázi. Panel spuštění zobrazí obecné upozornění vždy, když přeskočíte fáze, které mají podřízené závislosti. Zbývá vám zjistit, jestli jsou tyto závislosti skutečnými závislostmi artefaktů, nebo jestli jsou právě přítomné pro sekvencování nasazení.

Přeskočení fáze je ekvivalentní opětovnému vyřazování závislostí mezi fázemi. Jakékoli přímé následné závislosti přeskočené fáze jsou závislé na nadřazené fázi přeskočené fáze. Pokud se spuštění nezdaří a pokud se pokusíte znovu spustit neúspěšnou fázi, bude mít tento pokus stejné chování při přeskočení. Pokud chcete změnit, které fáze mají být přeskočeny, musíte spustit nový běh.

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

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 obsahuje různé důležité funkce pro podporu kanálů YAML CD s více fázemi, jako jsou schválení, autorizace a sdílení napříč projekty.

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

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

Přidali jsme možnost ručního výběru verzí prostředků kanálu v dialogu pro vytvoření spuštění. Pokud používáte pipeline jako prostředek v jiném pipeline, můžete při vytváření běhu vybrat verzi tohoto pipeline.

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

Skupina proměnných pro CI/CD pipeline a příkazy pro správu proměnných

Přenos kanálů založených na YAML z jednoho projektu do druhé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í příkazů pro správu skupin proměnných a proměnných teď můžete skriptovat nastavování a správu proměnných v konfiguračním rozhraní a skupin proměnných, které se pak dají verzovat, což vám umožní jednoduše přenášet nastavení konfiguračního rozhraní z jednoho projektu do druhého.

Spuštění kanálu pro větev žádosti o přijetí změn

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

Přeskočit první 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 vést k chybnému spuštění z různých důvodů – infrastruktura není připravená nebo potřebuje vytvořit 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 podporují pouze nastavení a správu koncového bodu 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 tím, že poskytne konfiguraci prostřednictvím souboru a poskytuje 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říkazu .

Ú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 pro odkazy 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í, kterou teď můžete nastavit.

• timeoutInMinutes – jak dlouho se má úloha spustit před automatickým zrušením
• cancelTimeoutInMinutes – kolik času je třeba před ukončením úloh spustit vždy i v případě, že byly zrušeny úkoly.
• condition – podmíněně spustit úlohu
• proměnné – Pevně zakódované hodnoty je možné přidat přímo, můžete odkazovat na skupiny proměnných, na skupinu proměnných podpořenou trezorem klíčů Azure nebo na sadu proměnných definovaných v souboru.
• continueOnError – pokud by budoucí úlohy měly běžet i v případě selhání této úlohy nasazení; výchozí hodnota false

Další podrobnosti o úlohách nasazení a úplné syntaxi pro zadání úlohy nasazení najdete v tématu Úloha nasazení.

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

Do podrobností o potrubích CD YAML jsme přidali podporu, kde se potrubí CI označují jako zdroje potrubí. V zobrazení spuštění kanálu CI se teď zobrazí nová karta Přidružené kanály, kde najdete všechna spuštění kanálu, která kanál spotřebovávají, a artefakty.

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

Nedávno jsme zavedli nový typ prostředku označovaný jako balíčky , které přidávají 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é spouštěče můžete také povolit při vydání nové verze balíčku. Podpora je dnes k dispozici pouze pro využívání balíčků z GitHubu, ale v budoucnu plánujeme rozšířit podporu 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:

V současné době balíčky GitHubu podporují pouze ověřování na základě PAT, což znamená, že připojení služby GitHub v prostředku balíčku by mělo být typu PAT. Po zrušení tohoto omezení poskytneme podporu pro jiné typy ověřování.

Ve výchozím nastavení se balíčky ve vašich úlohách nestáhnou automaticky, 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

Odkaz na cluster Azure Kubernetes Service 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 odpovídající cluster. To platí pro prostředí mapovaná 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ší zjišťování a řízení zabezpečení. Často můžete chtít nakonfigurovat vlastní e-mailová oznámení pro všechny kanály verze, které jsou reprezentovány všemi kanály v rámci složky. Dříve jste museli nakonfigurovat více předplatných nebo jste v předplatných měli složité dotazy, abyste získali prioritní e-maily. V této aktualizaci teď můžete přidat klauzuli složky vydané verze do dokončeného nasazení a čekajících událostí schválení a zjednodušit odběry.

Propojení pracovních položek s kanály YAML s více fázemi

V současné době můžete pracovní položky automaticky propojit s klasickými buildy. U kanálů YAML to ale nebylo možné. V této aktualizaci jsme tuto mezeru vyřešili. Když kanál úspěšně spustíte 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 tomto kódu). Když pracovní položku otevřete, uvidíte spuštění, ve kterých byl vytvořen kód pro danou pracovní položku. Ke konfiguraci použijte panel nastavení kanálu.

Zrušení fáze ve vícefázovém běhu YAML pipeline.

Při spuštění potrubí YAML s více fázemi teď můžete zrušit provádění fáze během jejího průběhu. Je to užitečné, pokud víte, že fáze selže, nebo pokud máte další úkol, který chcete zahájit.

Opakovat neúspěšné fáze

Jednou z nejžádanějších funkcí v kanálech s více fázemi je možnost opakovat neúspěšnou fázi bez nutnosti začínat od začátku. V této aktualizaci přidáváme velkou část této funkce.

Teď můžete zkusit znovu fázi kanálu, když se spuštění nezdaří. Všechny úlohy, které selhaly při prvním pokusu, a úlohy, které závisejí na těchto neúspěšných úlohách, se znovu pokusí.

To vám může pomoct ušetřit čas několika způsoby. Pokud například spouštíte více úloh ve fázi, 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 na jiných projdou, můžete ušetřit čas tím, že znovu nespustíte úlohy, které již prošly. Dalším případem může být selhání fáze nasazení kvůli nestabilnímu síťovému připojení. Zopakování této fáze vám pomůže šetřit čas, protože nebudete muset provádět další sestavení.

Tato funkce obsahuje několik známých mezer. Například nemůžete opakovat fázi, kterou explicitně zrušíte. Pracujeme na uzavření těchto mezer v budoucích aktualizacích.

Schválení ve vícefázových potrubích YAML

Vaše YAML CD pipelines mohou obsahovat manuální schválení. Vlastníci infrastruktury můžou chránit svá prostředí a požádat o ruční schválení před etapou v jakémkoli potrubí, který do nich nasadí. Díky úplnému oddělení rolí mezi vlastníky infrastruktury (prostředí) a aplikací (pipeline) zajistíte ruční schválení pro nasazení v konkrétní pipeline a centrální řízení při aplikaci stejných kontrol ve všech nasazeních do prostředí.

Kanál, který se nasazuje do vývojového prostředí, se zastaví ke schválení na začátku fáze.

Zvýšení časového limitu a frekvence pro brány

Dříve činil časový limit brány ve vydávacích kanálech tři dny. V této aktualizaci byl časový limit zvýšen na 15 dnů, aby bylo možné používat brány s delší dobou trvání. Také jsme zvýšili frekvenci brány na 30 minut.

Nová šablona pro sestavení obrazu pro Dockerfile

Dříve při vytváření nového kanálu pro soubor Dockerfile šablona doporučovala odeslání image do služby Azure Container Registry a nasazení do služby Azure Kubernetes Service. Přidali jsme novou šablonu, která vám umožní vytvořit image pomocí agenta, aniž by bylo nutné ji poslat do registru kontejneru.

Nová úloha pro konfiguraci 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, která podporuje hromadnou konfiguraci těchto nastavení pomocí syntaxe JSON ve webové aplikaci nebo libovolném z jejích slotů nasazení. Tuto úlohu můžete použít spolu 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 funkci Prohození s náhledem

Azure App Service teď podporuje prohození s verzí Preview v slotech nasazení. To je dobrý způsob, jak ověřit aplikaci s produkční konfigurací předtím, než se aplikace skutečně prohodí z přípravného slotu do produkčního slotu. Tím by se také zajistilo, že cílový/produkční slot neprostoje.

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

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

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

Dříve byly filtry regulárních výrazů pro artefakty služby 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 YAML pipelinech

Umožnili jsme konfigurovat schválení pro připojení služeb a fondy agentů. Při schvalování sledujeme oddělení rolí mezi vlastníky infrastruktury a vývojáři. Konfigurací schvalování vašich prostředků, jako jsou prostředí, připojení služeb a fondy agentů, bude zajištěno, že všechna spuštění kanálů, která používají prostředky, budou nejprve vyžadovat schválení.

Zkušenost je podobná konfiguraci schválení pro prostředí. Když schválení čeká na prostředek odkazovaný ve fázi, spuštění kanálu počká, dokud se kanál neschváří ručně.

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ď přináší podporu pro testy struktury kontejnerů. 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é se dají 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 dalším postupu či jeho zastavení. Testovací data jsou k dispozici při běhu kanálu s chybovou zprávou, která vám pomůže lépe odstraňovat problémy.

Zadejte podrobnosti konfiguračního souboru a obrázku.

Testovací data a souhrn

Dekorátoři kanálů pro vydávací kanály

Dekorátory potrubí umožňují přidat kroky na začátek a konec každého úkolu. To se liší od přidání kroků do jedné definice, protože se vztahuje na všechny kanály v kolekci.

Podporovali jsme dekorátory pro sestavení a kanály YAML, které zákazníci používají k centrálnímu řízení kroků ve svých úlohách. Nyní rozšiřujeme podporu také na vydávací kanály. Můžete vytvořit rozšíření pro přidání kroků, které cílí na nový bod integrace, a tyto kroky budou přidány do všech úloh agenta v nasazovacích kanálech.

Nasazení Azure Resource Manageru (ARM) na úrovni skupin předplatných a správy

Dříve jsme podporovali nasazení pouze na úrovni skupiny prostředků. V této aktualizaci jsme přidali podporu pro nasazení šablon ARM na úrovni předplatného i skupiny pro správu. Toto vám pomůže při nasazení sady prostředků společně, přičemž je umístíte do různých skupin prostředků nebo různých 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í.

Funkce pro průběžné dodávání ve vícefázových kanálech YAML

Teď můžete využívat artefakty publikované vaším CI pipeline a povolit triggery pro dokončení pipeline. V YAML kanálech s více fázemi zavádíme 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 zdroj pipeline.

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í úlohy stáhnout artefakty publikované prostředkem vašeho pipeline - download.

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

Další podrobnosti najdete zde v dokumentaci ke stahování artefaktů.

Koordinovat strategii kanárového nasazení v prostředí Kubernetes

Jednou z klíčových výhod průběžného doručování aktualizací aplikací je schopnost rychle odesílat aktualizace do produkčního prostředí pro konkrétní mikroslužby. Díky tomu můžete rychle reagovat na změny obchodních požadavků. Prostředí bylo zavedeno jako prvotřídní koncept, který umožňuje orchestraci strategií nasazení a usnadňuje vydání bez výpadků. Dříve jsme podporovali strategii runOnce , která postupně provedla kroky. Díky podpoře kanárské strategie ve vícefázových kanálech teď můžete snížit riziko tím, že pomalu zavádíte změnu na malou podmnožinu. Jakmile budete mít větší jistotu v nové verzi, můžete ji začít zavádět na více serverů ve vaší infrastruktuře a směrovat do ní 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 Kubernetes nejprve nasadí změny na 10 % podů, následně na 20 %, přičemž během postRouteTraffic monitoruje stav. Pokud vše půjde dobře, bude povýšeno na 100%.

Hledáme časnou zpětnou vazbu ohledně podpory prostředků virtuálních počítačů v prostředích a provádění strategie postupného nasazení napříč několika počítači. Kontaktujte nás , abychom se zaregistrovali.

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

V pipelinech YAML používáme konfiguraci schválení řízenou vlastníkem prostředku. Vlastníci prostředků konfigurují schválení prostředku a všechny kanály, které používají pozastavení prostředku ke schválení před zahájením fáze, kdy prostředek spotřebovávají. Vlastníci aplikací založených na SOX obvykle brání tomu, aby si žadatel nasazení schválil své vlastní nasazení.

Teď můžete použít pokročilé možnosti schválení ke konfiguraci zásad schválení, jako například žadatel nemá schvalovat, vyžadovat schválení od podmnožiny uživatelů a nastavit časový limit pro schválení.

ACR jako zdroj pro pipeline první třídy

Pokud potřebujete použít image kontejneru publikovanou v ACR (Azure Container Registry) jako součást kanálu a aktivovat kanál při každém publikování 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 

Kromě toho je možné získat přístup k meta-datům obrázků ACR pomocí předdefinovaných proměnných. Následující seznam obsahuje proměnné ACR, které jsou k dispozici pro určení prostředku kontejneru ACR ve vašem pipeline.

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í pro vyhodnocování zásad kontroly artefaktů v kanálech

Vylepšili jsme vyhodnocovací kontrolu artefaktu, abychom usnadnili přidávání zásad ze seznamu předem definovaných 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í

Teď můžete definovat výstupní proměnné v hookech životního cyklu úlohy 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.

• Pro strategii runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Pro kanárovou strategii: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Pro strategii postupného zavádění : $[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 tom, jak nastavit výstupní proměnnou s více úlohami

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

V klasických pipelinech vydání je obvyklé spoléhat se na naplánovaná nasazení pro pravidelné aktualizace. Pokud ale máte kritickou opravu, můžete se rozhodnout spustit ruční nasazení mimo pásmo. Pokud tak učiníte, starší verze zůstanou nadále naplánovány. To představovalo výzvu, protože ruční nasazení se vrátí zpět, když se nasazení obnoví podle plánu. Mnoho z vás tento problém nahlásilo a opravili jsme ho. S opravou se všechna starší naplánovaná nasazení do prostředí zruší, když ručně spustíte nasazení. To platí jenom v případě, že je vybraná možnost nasazení nejnovější verze a zrušení ostatních.

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 před jejich používáním autorizované. Dříve při použití neautorizovaných zdrojů v potrubí YAML došlo k chybě autorizace zdrojů. Museli jste autorizovat prostředky ze souhrnné stránky neúspěšného spuštění. Kromě toho potrubí selhalo, když používalo proměnnou, která odkazuje na neoprávněný prostředek.

Teď usnadňujeme správu autorizací prostředků. Místo selhání spuštění bude spuštění čekat na oprávnění k prostředkům na začátku fáze, která prostředek spotřebovávají. Vlastník prostředku může zobrazit pipeline a autorizovat prostředek ze stránky Zabezpečení.

Vyhodnocení kontroly artefaktu

Teď můžete definovat sadu zásad a přidat vyhodnocení zásad jako kontrolní bod v prostředí pro artefakty kontejnerových obrázků. 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í na základě dostupných metadat nasazené image. Kontrola proběhne, když je zásada úspěšná a označí fázi jako neúspěšnou, pokud se kontrola nezdaří.

Aktualizace úlohy nasazení šablony ARM

Dříve jsme nefiltrovali připojení služby v úloze nasazení šablony ARM. To může způsobit selhání nasazení, pokud vyberete připojení služby s nižším rozsahem k provádění nasazení šablon ARM do širšího rozsahu. Teď jsme přidali filtrování připojení služeb, abychom odstranili připojení služeb s nižším rozsahem na základě zvoleného oboru nasazení.

ReviewApp v prostředí

ReviewApp nasadí každou žádost o přijetí změn z vašeho úložiště Git do dynamického prostředku výpočetního prostředí. Recenzenti mohou vidět, jak tyto změny vypadají a jak fungují s dalšími závislými službami, než se sloučí do hlavní větve a nasadí do produkčního prostředí. Díky tomu budete moci snadno vytvářet a spravovat prostředky aplikace pro kontrolu a využívat výhod 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 pro použití aplikace 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

Shromáždit automatická a uživatelsky zadaná metadat z potrubí

Teď můžete povolit automatickou a uživatelem určenou kolekci metadat z úloh kanálu. Pomocí metadat můžete vynutit zásady artefaktů v prostředí prostřednictvím kontroly vyhodnocení artefaktů.

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

Jednou z nejžádanějších funkcí v prostředích byla nasazení virtuálních počítačů. V této aktualizaci povolujeme zdroj Virtual Machine v prostředích. Teď můžete orchestrovat nasazení napříč několika počítači a provádět kumulativní aktualizace pomocí kanálů YAML. Agenta můžete také nainstalovat na každý z vašich cílových serverů přímo a řídit postupné nasazení na tyto servery. Kromě toho můžete na cílových počítačích použít úplný katalog úloh.

Postupné nasazení nahrazuje instance předchozí verze aplikace instancemi nové verze aplikace v sadě počítačů (rolling set) v každé iteraci.

Například postupné nasazení aktualizuje až pět cílů v každé iteraci. maxParallel určí počet cílů, které je možné nasadit paralelně. Výběr bere v úvahu počet cílů, které musí být kdykoli dostupné, s výjimkou cílů, do kterých se právě nasazuje. Slouží také k určení podmínek úspěchu a selhání během nasazování.

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:

Při této aktualizaci se všechny dostupné artefakty z aktuálního potrubí a z přidružených zdrojů potrubí stáhnou pouze v deploy háku životního cyklu. Můžete se ale rozhodnout stáhnout zadáním úlohy pro stažení artefaktu z pipeline. Tato funkce obsahuje několik známých mezer. Když například zopakujete fázi, automaticky se nasazení znovu spustí na všech virtuálních počítačích, nejen na neúspěšných cílech. Pracujeme na uzavření těchto mezer v budoucích aktualizacích.

Další kontrola nad nasazeními

Azure Pipelines už nějakou dobu podporuje nasazení řízená ručním schvalováním. Díky nejnovějším vylepšením teď máte další kontrolu nad nasazeními. Kromě schválení mohou nyní vlastníci prostředků přidávat automatizované ověřování zásad zabezpečení a kvality pomocí checks. Tyto kontroly je možné použít k aktivaci operací a pak počkat, až se dokončí. Pomocí dalších kontrol teď můžete definovat kritéria stavu na základě více zdrojů a zajistit, že všechna nasazení cílící na vaše prostředky jsou bezpečná bez ohledu na kanál YAML provádějící nasazení. Vyhodnocení každé kontroly 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 provedení ověření na základě textu odpovědi nebo zpětného volání z externí služby
• Vyvolání funkce Azure a provedení ověření na základě odpovědi nebo zpětného volání z funkce
• Dotazování pravidel služby Azure Monitor pro aktivní výstrahy
• Ujistěte se, že potrubí rozšiřuje jednu či 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 kanály s více fázemi, které používají prostředek, automaticky čekají na schválení na začátku fáze. Schválitelé musí dokončit schválení, než může potrubí pokračovat.

S touto aktualizací se schvalovatelům odešle e-mailové oznámení o čekajících schválení. Uživatelé a vlastníci týmu se můžou odhlásit nebo nakonfigurovat vlastní odběry pomocí nastavení oznámení.

Konfigurace strategií nasazení z webu 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. Použitím těchto hotových strategií můžete aktualizace nasadit bezpečně 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ří, skupinu nasazení, kanál buildu, který publikuje balíček, který se má nasadit, a strategii nasazení podle vašeho výběru. Pokračováním nakonfigurujete plně funkční pipeline, která nasadí vybraný balíček na tento virtuální počítač.

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

Parametry běhu

Parametry modulu runtime umožňují mít větší kontrolu nad hodnotami, které se dají předat do kanálu. Na rozdíl od proměnných mají parametry za běhu datové typy a nestávají se automaticky proměnnými prostředí. S parametry modulu runtime můžete:

• Zadání různých hodnot skriptům a úlohám za běhu
• Řízení typů parametrů, povolených rozsahů a výchozích hodnot
• Dynamický výběr úloh a etap pomocí výrazu z šablony

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

Použijte klíčové slovo extends v pipelines

V současné době je možné pipeliny zohlednit do šablon, podporují opakované použití a snižují opakující se kód. 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 zásobníků. Kořenový soubor YAML teď může používat klíčové slovo extends k označení, že hlavní struktura pipeline je v jiném souboru. To vám dává kontrolu nad tím, jaké segmenty je možné rozšířit nebo změnit a jaké segmenty jsou pevné. Také jsme vylepšili parametry zpracování dat tak, aby pomocí datových typů jasně určily rozhraní, která můžete poskytnout.

Tento příklad ukazuje, jak můžete poskytnout jednoduché hooky pro tvůrce pracovního toku, které může použít. Šablona vždy spustí sestavení, volitelně spustí další kroky zadané v rámci pipeline, a poté volitelně spustí 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 }}

Kontrola nad proměnnými, které se mohou přepisovat při čekání ve frontě

Dříve můžete pomocí uživatelského rozhraní nebo rozhraní REST API aktualizovat hodnoty jakékoli proměnné před spuštěním nového spuštění. 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, toto nastavení se použilo 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. Tím získáte kontrolu nad tím, které proměnné se dají změnit při spuštění nového spuštění. V budoucnu nemůžete změnit proměnnou, která není označena autorem jako _settable at queue time_.

Poznámka:

Toto nastavení je ve výchozím nastavení vypnuté v existujících kolekcích, 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é vám poskytují pohodlný způsob, jak získat klíčové bity dat do různých částí vašeho kanálu. 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, vymezeny na konkrétní úlohu nasazení a jsou jen pro čtení.

• Environment.Id – ID prostředí.
• Environment.Name – Název prostředí, na nějž 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 více úložišť

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

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

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

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

Třetí krok zobrazí ve zdrojovém adresáři dva adresáře, MyCode a Tools .

Úložiště Git v Azure Repos se podporují. Další informace viz Víceúložišťové checkout.

Získání podrobností o více úložištích během běhu programu

Když je pipeline spuštěná, Azure Pipelines přidá informace o úložišti, větvi a commitu, které aktivovalo spuštění. Teď, když kanály YAML podporují rezervaci více úložišť, můžete také chtít znát úložiště, větev a potvrzení, které byly rezervovány pro jiná úložiště. Tato data jsou k dispozici prostřednictvím výrazu runtime, který teď můžete mapovat na proměnnou. Napří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 referencování úložišť mezi kolekcemi Azure Repos

Když jste dříve odkazovali na úložiště v kanálu YAML, museli být všechna úložiště Azure Repos ve stejné kolekci jako kanál. Teď můžete odkazovat na úložiště v jiných kolekcích pomocí připojení služby. Napří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. cs-CZ: Obě úložiště self a otherrepo budou nakonec stažena.

Důležité

MyServiceConnection musí být připojení ke službě Azure Repos / Team Foundation Server, viz následující obrázek.

Metadata zdrojů pipeline jako předdefinované proměnné

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

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

kustomize a kompose jako simulační možnosti v úloze KubernetesManifest

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

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 pro přihlašovací údaje správce clusteru v úloze HelmDeploy

Dříve úloha HelmDeploy použila pro nasazení přihlašovací údaje uživatele clusteru. Výsledkem byly interaktivní výzvy k přihlášení a neúspěšná pipeline pro cluster s povoleným RBAC, který je založen 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žívat přihlašovací údaje správce clusteru.

Vstup argumentů v úloze Docker Compose

V úloze Docker Compose bylo zavedeno nové pole, které umožňuje přidat argumenty, jako je --no-cache. Argument bude předán úkolem při provádění příkazů, jako je kompilace.

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

Provedli jsme několikvylepšeních Teď můžete mít lepší kontrolu nad vytvořením vydané verze pomocí pole vzoru značky zadáním regulárního výrazu značky a verze se vytvoří pouze v případech, kdy se aktivační potvrzení označí 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 konfigurace protokolu změn teď můžete určit verzi, se kterou se má aktuální verze porovnávat. Porovnáním s verzí může být poslední úplná verze (vyloučí se předběžné verze), poslední verze, která není konceptem, nebo jakákoli předchozí verze odpovídající zadané značce vydané verze. Kromě toho úloha poskytuje pole typu protokolu změn pro formátování protokolu změn. Na základě výběru protokolu změn se zobrazí buď seznam potvrzení, nebo seznam problémů nebo žádostí o přijetí změn zařazených do kategorií na základě popisků.

Úloha instalačního programu Open Policy Agenta

Open Policy Agent je modul zásad pro široké použití, který umožňuje jednotné vynucování zásad s ohledem na kontext. Přidali jsme instalační úlohu agenta Open Policy. Je obzvlášť užitečná pro vynucování zásad v rámci procesu u poskytovatelů infrastrukturního kódu.

Například agent Open Policy Agent může vyhodnotit soubory zásad Rego a plány Terraformu v rámci procesního toku.

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

Podpora pro skripty PowerShellu v úlohách Azure CLI

Dříve můžete jako součást úlohy Azure CLI spustit dávkové skripty a skripty Bash. V této aktualizaci jsme do úlohy přidali podporu powershellových a základních skriptů PowerShellu.

Kanárská nasazení založená na Service Mesh Interface v úloze KubernetesManifest

Dříve, když byla v úloze KubernetesManifest zadána kanárová strategie, úloha by vytvořila základní a kanárské úlohy, jejichž repliky se rovnaly procentu replik použitých pro stabilní úlohy. To nebylo úplně stejné jako rozdělení provozu až do požadovaného procenta na úrovni požadavku. Abychom to vyřešili, přidali jsme podporu pro kanárná nasazení založená na rozhraní Service Mesh do úlohy KubernetesManifest.

Abstrakce rozhraní Service Mesh umožňuje konfiguraci plug-and-play s poskytovateli služeb, jako jsou Linkerd a Istio. Úloha KubernetesManifest nyní usnadňuje práci s mapováním SMI objektů TrafficSplit ke stabilním, základním a kanárským službám v průběhu strategie nasazení. Požadované procentní rozdělení provozu mezi stabilní, referenční a kanárkové nasazení je přesnější, protože procentní rozdělení provozu je řízeno na úrovni síťové služby podle požadavků.

Následuje ukázka postupného průběžného nasazování kanárských verzí založeného na SMI.

- 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 lze použít v sestavovacím nebo vydávacím kanálu ke kopírování souborů do objektů blob úložiště Microsoft nebo virtuálních počítačů (VM). Úloha používá Nástroj příkazového řádku AzCopy, který umožňuje rychlé kopírování dat z a do účtů úložiště Azure. V této aktualizaci jsme přidali podporu pro AzCopy V10, což je nejnovější verze Nástroje AzCopy.

Příkaz azcopy copy podporuje pouze argumenty přidružené k němu. Vzhledem ke změně syntaxe nástroje AzCopy nejsou některé z existujících funkcí v AzCopy v 10 dostupné. Patří mezi ně:

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

Další možnosti podporované v této verzi úlohy jsou:

• Zástupné znaky 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í úrovně podrobností protokolu pro soubor protokolu předáním parametru

Vylepšené zabezpečení kanálů na základě omezení 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 volání zpět do Azure DevOps. Pomocí přístupového tokenu například získáme zdrojový kód, nahrajeme protokoly, výsledky testů, artefakty nebo provedeme volání REST do Azure DevOps. Pro každou úlohu se vygeneruje nový přístupový token a po dokončení úlohy vyprší jeho platnost. V této aktualizaci jsme přidali následující vylepšení.

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

  Doposud byl výchozí rozsah všech pipeline sbírka týmových projektů. Rozsah můžete změnit tak, aby byl týmový projekt v klasických kanálech buildu. Neměli jste ale tento ovládací prvek pro klasické verze nebo kanály YAML. V této aktualizaci zavádíme nastavení sbírky, které vynutí každou úlohu získat token s oborem projektu, bez ohledu na to, co je nakonfigurováno v pipeline. Přidali jsme také nastavení na úrovni projektu. Teď bude mít každý nový projekt a kolekci, které vytvoříte, toto nastavení automaticky zapnuté.

  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í potrubí, můžete účtu Služby sestavení projektu explicitně udělit přístup k požadovanému prostředku. Důrazně doporučujeme zapnout tato nastavení zabezpečení.

• Omezit přístup k rozsahu repozitářů služby buildu

  Azure Pipelines teď může omezit rozsah přístupového tokenu na základě vylepšení zabezpečení kanálu tak, že omezí přístup k úložišti jen na úložiště požadovaná pro kanál založený na YAML. To znamená, že pokud by došlo k úniku přístupového tokenu kanálů, bylo by možné zobrazit 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ě celou kolekci.

  Tato funkce bude ve výchozím nastavení zapnutá pro nové projekty a kolekce. U existujících kolekcí je nutné povolit tuto funkci v Nastavení kolekcí>Kanály>Nastavení. Při použití této funkce musí být všechna úložiště potřebná pro build (včetně těch, které klonujete pomocí skriptu) zahrnuta do prostředků úložiště pipeline.

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

  Ve výchozím nastavení udělujeme přístupovým tokenům řadu oprávnění, jedním z těchto oprávnění je Queue builds. V této aktualizaci 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í ke službám

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 centralizované místo pro všechna připojení služeb.

Cílení kroků a izolace příkazů

Azure Pipelines podporuje spouštění úloh v kontejnerech nebo v 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 mohou být zaměřeny také na jiné kontejnery, takže pipeline může spouštět každý krok v účelově vytvořeném specializovaném kontejneru.

Kontejnery můžou fungovat jako hranice izolace, což brání kódu v provádění neočekávaných změn na hostitelském počítači. Způsob, jakým kroky komunikují se službami a přistupují k službám z agenta, není ovlivněn izolací kroků v kontejneru. Proto také zavádíme režim omezení příkazů, který lze použít s cílovými kroky. Zapnutím tohoto nastavení omezíte služby, o které může krok požádat agent. Už nebude moct připojit protokoly, nahrát artefakty a některé další operace.

Zde je komplexní příklad, který znázorňuje kroky spuštění na hostiteli, v kontejneru úloh a v další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 zdokumentované jako neměnné, ale v praxi by je mohly přepsat úkoly a podřízené úkoly by převzaly novou hodnotu. Díky této aktualizaci zvýšíme zabezpečení týkající se proměnných v rámci potrubí, aby systémové proměnné a proměnné času fronty byly pouze 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žby spravovat pouze prostřednictvím předem definovaný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áře, uživatele, tvůrce a správce. Tyto role můžete nastavit prostřednictvím stránky připojení služeb ve vašem projektu a zdědí je jednotlivá připojení. U každého připojení služby máte možnost zapnout nebo vypnout možnost dědičnosti a upravit role v rámci připojení služby.

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

Sdílení propojení služeb napříč projekty

Povolili jsme podporu sdílení připojení služeb mezi projekty. Teď můžete bezpečně a bezpečně sdílet svá připojení ke službám s vašimi projekty.

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

Sledovatelnost potrubí a zdrojů ACR

Zajišťujeme úplnou sledovatelnost E2E, pokud jsou v pipeline používány pipeliny a prostředky kontejnerů ACR. Pro každý prostředek spotřebovaný prostřednictvím vašeho YAML pipeline můžete trasovat commity, pracovní položky a artefakty.

V zobrazení souhrnu běhu pipeline můžete vidět:

• Verze prostředku, která aktivovala spuštění. Nyní lze spustit váš pipeline po dokončení jiného běhu v Azure nebo když je image kontejneru nahrána do Azure Container Registry.

  

• Commity, které potrubí využívá. Můžete také zjistit podrobný rozklad commitů podle jednotlivých prostředků využívaných pipeline.

  

• 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 rozsáhlých testovacích příloh

Úloha publikování výsledků testů ve službě Azure Pipelines umožňuje publikovat výsledky testů při provádění testů, aby poskytovaly komplexní prostředí pro vytváření sestav a analýzy testů. Do této chvíle byl limit 100 MB pro přílohy testů pro testovací běh i výsledky testů. Tím se 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, která vám umožní získat 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ů testů, která vrací chybu 403 nebo 407. Pokud používáte nasazené sestavení nebo agenty pro vydávání verzí umístěné za firewallem, který filtruje odchozí požadavky, budete muset provést určité změny konfigurace, aby bylo možné tuto funkcionalitu používat. ​

Pokud chcete tento problém vyřešit, doporučujeme aktualizovat pravidla firewallu pro odchozí požadavky na https://*.vstmrblob.vsassets.io. Informace o řešení potíží najdete v této dokumentaci. ​

Poznámka:

To se vyžaduje 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 poolu pro každou úlohu

Když jste dříve použili matici pro 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.

CI spouštěče pro nové větve

Jedná se o dlouhodobý požadavek neaktivovat sestavení CI při vytvoření nové větve; pokud tato větev neobsahuje žádné změny. Zvažte následující příklady:

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

Teď máme lepší způsob zpracování CI pro nové větve, abychom tyto problémy vyřešili. Při publikování nové větve 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ď můžou používat napříč fázemi v kanálu založeném na YAML. To vám pomůže předat užitečné informace, jako je go/no-go rozhodovací kritérium nebo ID vygenerovaného výstupu, z jedné etapy do další. K dispozici je také výsledek (stav) předchozí fáze a jeho úlohy.

Výstupní proměnné jsou nadále vytvářeny kroky uvnitř úloh. Namí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 pipeline závisí na předchozí fázi v souboru YAML. 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í dostupné výstupní proměnné. Pokud například fáze 3 potřebuje proměnnou z fáze 1, bude nutné deklarovat explicitní závislost na fázi 1.

Zakázat automatické upgrady agentů na úrovni fondu

V současné době se agenti pipeline automaticky aktualizují na nejnovější verzi, když je to potřeba. K tomu obvykle dochází v případě, že existuje nová funkce nebo úloha, která vyžaduje, aby správně fungovala novější verze agenta. V této aktualizaci přidáváme možnost zakázat automatické upgrady na úrovni fondu. Pokud v tomto režimu není žádný agent správné verze připojený k fondu, kanály selžou s jasnou chybovou zprávou místo vyžádání agentů k aktualizaci. Tato funkce je většinou zajímavá pro zákazníky s fondy samostatně hostovanými a velmi přísné požadavky na kontrolu změn. Automatické aktualizace jsou ve výchozím nastavení povolené a nedoporučujeme, aby je většina zákazníků zakázala.

Diagnostika agentů

Přidali jsme diagnostiku pro řadu běžných problémů souvisejících s agenty, jako je mnoho problémů se sítí 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.

Volané služby pro kanály YAML

Integrace služeb s kanály YAML je jednodušší. Pomocí událostí volání 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ž je požadováno 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 je podporováno pro všechny události. Události schválení je možné filtrovat také pro konkrétní prostředí. Podobně je možné události změny stavu filtrovat podle nového stavu spuštění kanálu nebo fáze.

Integrace Optimizely

Optimalizace je výkonná platforma pro testování A/B a označení funkcí pro produktové týmy. Integrace Služby Azure Pipelines s platformou Optimalizované experimentování umožňuje produktovým týmům testovat, učit se a nasazovat s akcelerovaným tempem a zároveň získávat všechny výhody DevOps z Azure Pipelines.

Rozšíření Optimizely pro Azure DevOps přidává kroky pro experimentování a uvedení příznaků funkcí do kanálů sestavení a verzí, 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í Azure DevOps Optimizely najdete tady.

Přidejte verzi na GitHubu jako zdroj artefaktu

Teď můžete své verze GitHubu propojit jako zdroj artefaktů v kanálech verze Azure DevOps. To vám umožní využívat verzi 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í ke službě a úložiště GitHub, abyste mohli využívat verzi GitHubu. Můžete také zvolit výchozí verzi verze GitHubu, která se má využívat jako nejnovější, konkrétní verze značky nebo vybrat při vytváření verze. Jakmile je verze GitHub propojená, automaticky se stáhne a zpřístupní v úlohách vydání.

Integrace Terraformu se službou Azure Pipelines

Terraform je opensourcový nástroj pro vývoj, změnu a správu verzí infrastruktury bezpečně a efektivně. Terraform rozlišuje rozhraní API do deklarativních konfiguračních souborů, které umožňují definovat a zřizovat infrastrukturu pomocí základního konfiguračního jazyka. Pomocí rozšíření Terraform můžete vytvářet prostředky 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 se službou Google Analytics

Architektura experimentů Google Analytics umožňuje testovat téměř jakoukoli změnu nebo variantu webu nebo aplikace a měř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říklad výnosy, doba trvání relace, míra nedoručitelnosti). Tyto aktivity umožňují identifikovat změny, které stojí za implementaci na základě přímého dopadu na výkon vaší funkce.

Rozšíření experimentů Google Analytics pro Azure DevOps přidává kroky experimentování do kanálů sestavení a verzí, takže můžete průběžně iterovat, učit se a nasazovat rychleji tím, že experimenty průběžně spravujete a současně získáváte všechny výhody DevOps z Azure Pipelines.

Rozšíření pro experimenty Google Analytics si můžete stáhnout z Tržiště.

Aktualizovaná integrace ServiceNow se službou Azure Pipelines

Aplikace Azure Pipelines pro ServiceNow pomáhá integrovat Službu Azure Pipelines a správu změn ServiceNow. S touto aktualizací se můžete integrovat s newyorské verze ServiceNow. Ověřování mezi těmito dvěma službami je teď možné provést pomocí OAuth a základního ověřování. Kromě toho nyní můžete nakonfigurovat pokročilá kritéria úspěchu, abyste mohli použít jakoukoli vlastnost změny k rozhodnutí výsledku brány.

Vytvoření Azure Pipelines z VSCode

Do rozšíření Azure Pipelines pro VSCode jsme přidali novou funkci. Teď budete moct vytvářet Azure Pipelines přímo z VSCode bez opuštění integrovaného vývojového prostředí (IDE).

Správa a řešení nejednoznačných chyb

Zavedli jsme správu nestabilních testů pro podporu kompletního životního cyklu s detekcí, hlášením a řešením. Abychom ho dále vylepšili, přidáváme chytnou správu testovacích chyb a jejich řešení.

Při zkoumání nestabilního testu můžete vytvořit hlášení chyby pomocí akce Chyba, které může být přiřazeno vývojáři k určení příčiny nestabilního testu. Zpráva o chybě obsahuje informace o pipelineu, jako je chybová zpráva, stack trace a další informace související s testem.

Když je zpráva o chybě vyřešena nebo uzavřena, test bude automaticky označen jako spolehlivý.

Nastavte úlohy VSTest tak, aby selhaly, pokud není spuštěn minimální počet testů.

Úloha VSTest zjišťuje a spouští testy pomocí uživatelských vstupů (testovacích souborů, kritérií filtru atd.) a také testovacího adaptéru specifického pro používanou testovací architekturu. Změny uživatelských vstupů nebo adaptéru testu můžou 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 proběhnou úspěšně, protože testy se přeskočí místo toho, že kód má dostatečně vysokou kvalitu. Abychom se této situaci vyhnuli, přidali jsme do úlohy VSTest novou možnost, která umožňuje určit minimální počet testů, které musí být spuštěny, aby úloha prošla.

Dostupnost možnosti VSTest TestResultsDirectory v uživatelském rozhraní úloh

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

Podpora Markdownu v chybových zprávách automatizovaných testů

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

Použijte dekorátory kanálů ke automatickému vložení kroků do úlohy nasazení

Teď můžete do úloh nasazení přidat dekorátory kanálu . Každý vlastní krok (např. skener zranitelností) můžete automaticky vložit do každého háčku životního cyklu při každé úloze nasazení. Vzhledem k tomu, že dekorátory kanálu je možné použít pro všechny kanály v kolekci, můžete ho využít jako součást vynucování postupů bezpečného nasazení.

Kromě toho je možné úlohy nasazení spustit jako úlohu kontejneru společně se sidovými službami, pokud jsou definovány.

Test Plans

Nová stránka pro testovací plán

Nová stránka testovacích plánů (testovací plány *) je dostupná pro všechny kolekce Azure DevOps. Nová stránka poskytuje zjednodušená zobrazení, která vám pomůžou soustředit se na úkol – plánování testů, vytváření 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 Testovací plány obsahuje celkem 6 oddílů, z nichž první 4 jsou nové, zatímco oddíly Grafy a rozšiřitelnost jsou stávající funkce.

1. Hlavička testovacího plánu: Použijte ji k vyhledání, oblíbení, úpravě, kopírování nebo klonování testovacího plánu.
2. Strom testovacích sad: Slouží k přidání, správě, exportu nebo uspořádání testovacích sad. Využijte ho také k přiřazení konfigurací a provádění testování přijetí uživateli.
3. Definujte záložku: Seskupujte, přidávejte a spravujte testovací případy ve vybrané testovací sadě prostřednictvím této záložky.
4. Karta Spuštění: Přiřaďte a spusťte testy prostřednictvím této karty nebo vyhledejte výsledek testu, který můžete podrobně prozkoumat.
5. Karta grafu: Sledujte provádění a stav testu pomocí grafů, které lze také připnout na řídicí panely.
6. Rozšiřitelnost: Podporuje aktuální body rozšiřitelnosti v rámci produktu.

Pojďme si udělat obecný přehled těchto nových částí.

1. Hlavička testovacího plánu

Úkoly

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í oblíbeného testovacího plánu
• Snadné procházení oblíbených testovacích plánů
• Prohlédněte si cestu iterace testovacího plánu, která jasně označuje, jestli je testovací plán aktuální nebo minulý.
• Zobrazení rychlého souhrnu sestavy průběhu testu s odkazem na přechod na sestavu
• Přechod zpět na stránku Všechny/Moje testovací plány

Možnosti kontextové nabídky

Nabídka místní nabídky v hlavičce Testovacího plánu poskytuje 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í položky.
• Nastavení testovacího plánu: Tato možnost umožňuje nakonfigurovat nastavení testovacího spuštění (pro přidružení kanálů sestavení nebo verze) a nastavení výsledků testu.

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

Doporučujeme vytvořit nový testovací plán na sprint nebo verzi. Při tom je obecně možné zkopírovat testovací plán pro předchozí cyklus a s několika změnami zkopírovaný testovací plán je připravený pro nový cyklus. Abychom tento proces usnadnili, povolili jsme na nové stránce funkci Kopírovat testovací plán. Využijte ho ke kopírování nebo klonování testovacích plánů. Jeho backing REST API je zde popsaný a rozhraní API umožňuje kopírovat nebo klonovat testovací plán i napříč projekty.
Další pokyny k využití testovacích plánů najdete tady.

2. Struktura testovacích sad

Úkoly

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

• Rozbalení/sbalení: Tato možnost panelu nástrojů umožňuje 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ě Spustit. Díky tomu můžete zobrazit všechny testovací body pro danou sadu a její podřízené položky v jednom zobrazení, abyste si usnadnili správu testovacích bodů, aniž byste museli procházet jednotlivé sady po jednom.
• Uspořádání sad: Přesouváním sad můžete měnit hierarchii nebo je přesunout z jedné hierarchie sad do druhé v rámci testovacího plánu.

Možnosti kontextové nabídky

Kontextová nabídka na stromu testovacích sad nabízí následující možnosti:

• Vytvořte nové sady: 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í požadavků a uživatelských scénářů pro zajištění bezproblémové sledovatelnosti.
  • Pomocí dotazu můžete dynamicky uspořádat testovací případy, které splňují kritéria dotazu.
• Přiřaďte 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é přidáte později do této sady.
• Exportovat jako pdf/e-mail: Export vlastností testovacího plánu, vlastností testovací sady spolu s podrobnostmi testovacích případů a testovacích bodů jako "e-mail" nebo "print to 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í položky.
• Přiřaďte testery ke spuštění všech testů: Tato možnost je velmi užitečná pro scénáře testování přijetí uživatelů (UAT), kde stejný test musí spouštět nebo spouštět více testerů, obecně patřících různým oddělením.
• 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. Karta Definovat

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

Karta Definice a určité operace jsou k dispozici pouze uživatelům s úrovní přístupu Basic + Test Plans nebo ekvivalentní. Všechno ostatní by měl uplatnit uživatel se základní úrovní přístupu.

Úkoly

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.
• Seřazení testovacích případů přetažením: Pořadí testovacích případů můžete změnit přetažením jednoho nebo více testovacích případů v dané sadě. Pořadí testovacích případů se vztahuje pouze na ruční testovací případy a ne na 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í/úpravám testovacích případů spolu s testovacími kroky.
• Zobrazení na celé obrazovce: 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 "state". Seznam můžete také seřadit kliknutím na záhlaví sloupců.
• Možnosti sloupce: Seznam sloupců viditelných na kartě Definovat můžete spravovat pomocí možnosti sloupce. 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 kontextové nabídky

Místní nabídka na uzlu testovacího případu na kartě Definice nabízí následující možnosti:

• Otevřít/upravit formulář pracovní položky testovacího případu: Tato možnost vám umožní upravit testovací případ pomocí formuláře pracovní položky, kde můžete měnit pole pracovní položky, včetně kroků testovacích.
• Upravit testovací případy: Tato možnost umožňuje hromadně upravit pole pracovní položky testovacího případu. Tuto možnost však 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řazení konfigurací: Tato možnost umožňuje přepsat konfigurace na úrovni sady pomocí konfigurací na úrovni testovacího případu.
• Odebrat testovací případy: Tato možnost umožňuje odebrat testovací případy z dané sady. Nezmění ale základní pracovní položku testovacího případu.
• Vytvoření kopie/klonování testovacích případů: Tato možnost umožňuje vytvořit kopii/klon vybraných testovacích případů. Další informace naleznete níže.
• Zobrazit propojené položky: Tato možnost umožňuje podívat se na propojené položky pro daný testovací případ. Další informace naleznete níže.

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

Ve scénářích, ve kterých chcete kopírovat nebo klonovat 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 sadu testů, ve které chcete vytvořit testovací případ kopírování/klonování. Kromě toho můžete také určit, jestli chcete zahrnout existující odkazy nebo přílohy, které se mají naklonovat do klonované kopie.

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

Sledovatelnost mezi testovacími artefakty, požadavky a chybami je klíčovým přínosem produktu Test Plans. Pomocí možnosti Zobrazit propojené položky se můžete snadno podívat na všechny propojené požadavky, se kterými je tento testovací případ propojený, všechny testovací sady nebo testovací plány, ve kterých byl tento testovací případ použit, a všechny chyby, které byly uloženy jako součást provádění testů.

4. Karta Spustit

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

Co je testovací bod? Samotné testovací případy 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 jako "Funkce přihlášení k testu" a přidáte do něj 2 konfigurace jako Edge a Chrome, výsledkem bude 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 záložce Spuštění.
Testovací případy jsou proto opakovaně použitelné entity. Zahrnutím těchto bodů 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, že uživatelé, kteří se zaměřují na provádění a sledování testů (stačí pouze úroveň základního přístupu), nejsou zahlceni složitostí správy sady (karta definice je pro tyto uživatele skrytá).

Karta Definice a určité operace jsou k dispozici pouze uživatelům s úrovní přístupu Basic + Test Plans nebo ekvivalentní. Všechno ostatní, včetně karty Spustit, může uživatel se 'základní úrovní přístupu' využívat.

Úkoly

Karta 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ých, neúspěšných, blokovaných nebo nepoužitých, aniž byste museli testový případ spouštět prostřednictvím spouštěče testů. 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 prostřednictvím postupného procházení jednotlivých testovacích kroků a označit je jako úspěšné nebo neúspěšné pomocí nástroje pro spouštění testů. V závislosti na aplikaci, kterou testujete, můžete použít Web Runner k testování "webové aplikace" nebo "desktop runner" pro testování desktopových a/nebo webových aplikací. Můžete také vyvolat příkaz Spustit s možnostmi a určit sestavení, pro které chcete provést testování.
• Možnosti sloupce: Seznam sloupců viditelných na kartě Spustit můžete spravovat pomocí možnosti sloupce. Seznam sloupců dostupných pro výběr je přidružen k testovacím bodům, jako je Spuštěno kým, Přiřazený tester, Konfigurace atd.
• Zobrazení na celé obrazovce: Pomocí této možnosti můžete zobrazit obsah celé karty Execute 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 také seřadit kliknutím na záhlaví sloupců.

Možnosti kontextové nabídky

Místní nabídka na uzlu Testovací bod na kartě Spustit poskytuje 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 spustit testovací případy pomocí nástroje pro správu testů.
• Resetování testu na aktivní: Tato možnost umožňuje resetovat výsledek testu na aktivní, čímž ignoruje poslední výsledek testovacího bodu.
• Otevřít/upravit formulář pracovní položky testovacího případu: Tato možnost vám umožní upravit testovací případ pomocí formuláře pracovní položky, kde můžete měnit pole pracovní položky, včetně kroků testovacích.
• Přiřadit tester: Tato možnost umožňuje přiřadit testovací body testerům pro spouštění testů.
• Zobrazit výsledek testu: Tato možnost umožňuje zobrazit nejnovější podrobnosti výsledků testu včetně výsledku každého kroku testu, komentářů přidaných nebo chyb.
• Zobrazit historii spuštění: Tato možnost umožňuje zobrazit celou historii spuštění pro vybraný testovací bod. 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 pro celý testovací případ.

Sestava průběhu testovacích plánů

Tento předem připravený report vám pomůže sledovat provedení a stav jednoho nebo více testovacích plánů v projektu. Pokud chcete začít sestavu používat, přejděte na sestavu Průběhu testovacích plánů > *.

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

1. Shrnutí: zobrazuje konsolidované zobrazení pro vybrané testovací plány.
2. Trend výsledku: vykreslí denní snímek, který vám poskytne trendovou čáru provádění a stavu. Může zobrazit data po dobu 14 dnů (výchozí), 30 dnů nebo vlastního rozsahu.
3. Podrobnosti: Tato část umožňuje procházet podrobnosti podle jednotlivých testovacích plánů a poskytuje důležité analýzy pro každou sadu 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 zdroje, které jsou v koši, je potřeba je nejprve obnovit z koše, než zahájíte import dat.

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

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

Kliknutím na odkaz přejdete na webovou stránku, kde můžete zobrazit podrobnosti o licenci. Toto prostředí je stejné pro výrazy licencí i 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).

Zjednodušené ověřovací úlohy

Nyní se můžete autentizovat pomocí oblíbených správců balíčků z Azure Pipelines pomocí jednoduchých autentizačních úloh. To zahrnuje 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 však vyžaduje použití těchto úloh pro všechny aktivity, které komunikovaly se správci balíčků. Pokud jste měli vlastní skripty, které se mají spouštět pro provádění úloh, jako je publikování nebo stahování balíčků, nebudete je moct použít ve svém kanálu. Teď můžete v YAML kanálu použít skripty vlastního návrhu a provádět ověřování pomocí těchto nových jednoduchých úloh. Příklad použití npm:

Použití příkazu ci a publish na tomto obrázku je libovolné. Můžete použít jakékoli příkazy podporované nástrojem Azure Pipelines YAML. Díky tomu můžete mít úplnou kontrolu nad vyvoláním příkazů a snadno používat sdílené skripty 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 kanálu

S radostí oznamujeme, že jsme vylepšili dobu načítání stránky informačního kanálu. V průměru se doba načítání stránek informačního kanálu snížila o 10 %. Největší informační kanály zaznamenaly největší zlepšení 99. doby načítání stránky informačního kanálu percentilu (doba načítání v nejvyšších 99 % všech informačních kanálů) se snížila o 75 %.

Sdílejte své balíčky veřejně s veřejnými feedy

Balíčky teď můžete vytvářet a ukládat do veřejných informačních kanálů. Balíčky uložené ve veřejných informačních kanálech jsou dostupné všem uživatelům na internetu bez ověřování, ať už jsou ve vaší kolekci, nebo dokonce přihlášeni k kolekci Azure DevOps. Přečtěte si další informace o veřejných informačních kanálech v dokumentaci k informačním kanálům nebo přejděte přímo do našeho kurzu pro veřejné sdílení balíčků.

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

Nyní můžete přidat informační kanál v jiné kolekci přidružené k vašemu tenantovi Azure Active Directory (AAD) jako vstupní zdroj do informačního kanálu Artifacts. Váš informační kanál může najít 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ů mezi kolekcemi přidruženými k vašemu tenantovi AAD. Podívejte se, jak to nastavit v dokumentaci.

Použijte poskytovatele přihlašovacích údajů Python k autentizaci nástrojů pip a twine s informačními kanály Azure Artifacts.

Teď můžete nainstalovat a používat 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 zprostředkovatele přihlašovacích údajů nemusíte nastavovat žádné konfigurační soubory (pip.ini/pip.conf/.pypirc), budete jednoduše procházet ověřovacím tokem ve webovém prohlížeči při prvním volání pip nebo twine. Další informace najdete v dokumentaci.

Zdroje Azure Artifacts v rámci správce balíčků ve Visual Studio

Teď zobrazujeme ikony balíčků, popisy a autory ve Správci balíčků NuGet sady Visual Studio pro balíčky obsluhované z informačních kanálů Azure Artifacts. Většina těchto metadat nebyla dříve poskytována službě VS.

Aktualizovaný zážitek připojení k informačnímu kanálu

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

Veřejné informační kanály jsou nyní obecně k dispozici s podporou upstream procesů.

Veřejná ukázka veřejných informačních kanálů obdržela skvělou zpětnou vazbu a velkou míru přijetí. V této verzi jsme rozšířili další funkce na obecnou dostupnost. Nyní můžete nastavit veřejný informační kanál jako nadřazený zdroj pro soukromý kanál. Konfigurační soubory můžete snadno udržovat tím, že budete moci odesílat data jak do soukromých kanálů, tak z projektově zaměřených kanálů.

Vytvořte projektově zaměřené kanály z portálu

Když jsme vydali veřejné informační kanály, vydali jsme také projektově vymezené informační kanály. Až dosud bylo možné projektově vymezené kanály vytvořit prostřednictvím REST API nebo vytvořením veřejného kanálu a poté změnit projekt na soukromý. Teď můžete informační kanály s oborem projektu vytvářet přímo na portálu z libovolného projektu, pokud máte požadovaná oprávnění. Můžete také zjistit, které informační kanály jsou projektové a které jsou v nástroji pro výběr informačního kanálu vymezené kolekcí.

Vylepšení výkonu npm

Provedli jsme změny základního návrhu, abychom zlepšili způsob ukládání a doručování balíčků 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 nejužívaných rozhraní API pro npm.

Vylepšení přístupnosti

Zavedli jsme opravy pro řešení problémů s přístupností na naší stránce zdrojů. Mezi opravy patří:

• Vytvoření zážitku z informačního kanálu
• Globální prostředí nastavení informačního kanálu
• Připojení k prostředí informačního kanálu

Wiki

Bohaté možnosti úprav pro stránky wiki s kódem

Při úpravách stránky wikiwebu s kódem jste byli dříve přesměrováni do centra Azure Repos pro úpravy. V současné době není centrum úložiště optimalizované pro úpravy Markdownu.

Teď můžete upravit stránku wikiwebu kódu v editoru vedle sebe uvnitř wikiwebu. Díky tomu můžete pomocí panelu nástrojů Markdown vytvořit obsah tak, aby byl prostředí pro úpravy stejné jako na wikiwebu projektu. V repoziích se stále můžete rozhodnout, že v místní nabídce vyberete možnost Upravit v repos .

Vytvoření a vložení pracovních položek ze stránky wiki

Jak jsme si poslechli vaši zpětnou vazbu, slyšeli jsme, že používáte wikiweb k zachycení dokumentů debaty, plánování dokumentů, nápadů na funkce, specifikace dokumentů, minut schůzky. Teď 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. To vám ušetří čas, protože nemusíte nejdřív vytvářet pracovní položku, přejděte na úpravy a vyhledejte pracovní položku, kterou chcete vložit. Omezuje také kontextový přepínač, protože nevycházíte z oboru wikiwebu.

Další informace o vytváření a vkládání pracovních položek z wikiwebu najdete v naší dokumentaci.

Komentáře na stránkách wiki

Dříve jste neměli způsob, jak interagovat s ostatními uživateli wikiwebu uvnitř wikiwebu. Když bylo nutné spolupracovat na obsahu a zodpovídat otázky, bylo to náročné, protože diskuse musely probíhat prostřednictvím e-mailu nebo chatovacích kanálů. Díky komentářům teď můžete spolupracovat s ostatními přímo na wikiwebu. Pomocí funkcí uživatelů v komentářích můžete @mention upoutat pozornost ostatních členů týmu. Tato funkce byla upřednostněna na základě tohoto návrhového lístku. Další informace o komentářích najdete v naší dokumentaci zde.

Skrytí složek a souborů začínajících na "" ve wiki stromu

Dosud se ve stromu wiki zobrazily všechny složky a soubory začínající tečkou (.). Ve scénářích wiki to způsobilo, že se ve stromu wiki zobrazují složky jako .vscode, které by měly být skryté. Teď všechny soubory a složky začínající tečkou zůstanou ve stromu wiki skryté, takže se sníží nepotřebné prvky.

Tato funkce byla upřednostněna na základě tohoto návrhového lístku.

Krátké a čitelné adresy URL wikistránek

Už nemusíte používat víceřádkovou adresu URL ke sdílení odkazů na stránku wikiwebu. 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 pro úvodní stránku wikiwebu Azure DevOps :

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

Toto bylo upřednostněno na základě tohoto ticketu s návrhem funkce z komunity vývojářů.

Synchronní posun při úpravách 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ě se automaticky posune na 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 posuvníku se uloží na 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ě stránky za posledních 30 dnů. Tyto údaje můžete použít k vytváření reportů pro vaše wiki stránky. Kromě toho můžete tato data ukládat do zdroje dat a vytvářet řídicí panely, abyste získali konkrétní přehledy, jako například nejnavštěvovanější stránky (top-n).

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.

Reportování

Sestavy selhání procesu a zprávy o době trvání

Metriky a přehledy pomáhají průběžně zlepš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í pipeline zobrazuje míru úspěšnosti sestavení a trend selhání. Kromě toho také ukáže trend selhávání úloh, aby poskytl přehled o tom, která úloha v pipelinu přispívá k maximálnímu počtu selhání.

2. Sestava doby trvání kanálu zobrazuje trend času potřebných ke spuštění kanálu. Ukazuje také, které úlohy v procesu zabírají nejvíce času.

Vylepšení widgetu Výsledky dotazu

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

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

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

Pokročilé filtrování widgetů pro dobu realizace a čas cyklu

Vedoucí a cyklický čas používají týmy k tomu, aby viděly, jak dlouho trvá, než práce prochází jejich vývojovými kanály, a nakonec zákazníkům přináší hodnotu.

Doteď widgety pro dobu předstihu a cyklu nepodporují upřesňující kritéria filtru, která by položila otázky, například: "Jak dlouho trvá, než má můj tým zavřít položky s vyšší prioritou?".

U těchto aktualizačních otázek je možné odpovědět filtrováním plavecké dráhy na palubě.

Přidali jsme také filtry pracovních položek, aby se omezily pracovní položky, které se zobrazují v grafu.

Burndown pro sprint s využitím bodů pracnosti

Váš sprint burndown nyní může snižovat podle uživatelských příběhů. Tímto řešíme vaši zpětnou vazbu z komunity vývojářů.

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

1. Výběr backlogu scénářů
2. Výběr pro vypálení u součtu bodů obsahu

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

Nový widget Sprint Burndown 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 zobrazuje průměrný průběh úkolů, % dokončení a nárůst rozsahu. Můžete nakonfigurovat tým a zobrazit burndowny sprintů pro více týmů na stejném řídicím panelu. Díky všem těmto skvělým informacím vám umožňujeme změnit jejich zobrazení až na 10x10 na řídicím panelu.

Pokud ho chcete vyzkoušet, můžete ho přidat z katalogu widgetů nebo úpravou konfigurace existujícího widgetu Sprint Burndown a zaškrtnutím políčka Vyzkoušet novou verzi .

Poznámka:

Nový widget používá Analýzu. Starší verzi Sprint Burndownu jsme zachovali v případě, že nemáte přístup k analýzám.

Vložená miniatura grafu úbytku sprintu

Sprint Burndown je zpátky! Před několika sprinty jsme odstranili kontextový sprintový burndown ze záhlaví grafu Sprint Burndown a Taskboard. Na základě vaší zpětné vazby jsme vylepšili a znovu zavedli miniaturu sprint burndown diagramu.

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 úplné sestavě se projeví v grafu zobrazeném v záhlaví. Teď ho můžete nakonfigurovat tak, aby se burndown provedl na základě uživatelských příběhů, story pointů nebo podle počtu úkolů, a ne jen na základě zbývající práce.

Vytvoření řídicího panelu bez týmu

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

Řídicí panel projektu je podobný řídicímu panelu týmu, s výjimkou toho, že není přidružený k týmu a můžete rozhodnout, kdo může řídicí panel upravovat nebo spravovat. Stejně jako týmový řídicí panel je viditelný všem uživatelům v projektu.

Všechny widgety Azure DevOps, které vyžadují aktualizaci kontextu týmu, vám umožní vybrat tým v jejich konfiguraci. Tyto widgety můžete přidat do řídicích panelů projektu a vybrat konkrétní tým, který chcete.

Poznámka:

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

---

Zpětná vazba

Rádi bychom vás slyšeli! Můžete nahlásit problém nebo poskytnout nápad a sledovat ho prostřednictvím komunity vývojářů a získat rady o Stack Overflow.

---

Začátek stránky