Zpráva k vydání verze pro Azure DevOpsServer 2020 Update 1

| Developer Community Požadavky na | systémLicenční podmínky | HashSHA-1blogu | DevOps

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

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

Přímý upgrade na Azure DevOps Server 2020 se podporuje od Azure DevOps Server 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud tfs nasadíte v TFS 2010 nebo starší verzi, 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 Server 2019 na Azure DevOps Server 2020

Azure DevOps Server 2020 zavádí nový model uchovávání 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ě v závislosti na zásadách uchovávání informací na úrovni kanálu. Některé konfigurace zásad vedou k odstranění spuštění kanálu po upgradu. Spuštění kanálu, která byla ručně zachována nebo která jsou zachována ve vydané verzi, se po upgradu neodstraní.

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

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 13: 12. března 2024

File	Hodnota hash SHA-256
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

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

• Vyřešili jsme problém, kdy po instalaci opravy Patch 12 přestal fungovat proxy server.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 12: 13. února 2024

File	Hodnota hash SHA-256
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

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

• Opravili jsme chybu, kdy se nesprávně vypočítalo místo na disku využité složkou mezipaměti proxy serveru a složka nebyla správně vyčištěna.
• CVE-2024-20667: Azure DevOps Server ohrožení zabezpečení z důvodu možnosti vzdáleného spuštění kódu.

datum vydání Azure DevOps Server 2020 Update 1.2 Patch 11: 12. prosince 2023

File	Hodnota hash SHA-256
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

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

• Opravili jsme chybu, která způsobovala, že ve fázích kanálů nefungovala dědičnost zabezpečení schválení před nasazením.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 10: 14. listopadu 2023

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

• Rozšířili jsme seznam povolených znaků úloh PowerShellu pro povolení ověření parametrů argumentů úloh prostředí.

Poznámka

Pokud chcete implementovat opravy této opravy, budete muset provést řadu kroků pro ruční aktualizaci úloh.

Instalace oprav

Důležité

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

File	Hodnota hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Požadavky na kanál

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

• V klasickém režimu:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 9: 10. října 2023

Důležité

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

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

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

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

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

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

Důležité

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

Poznámka

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

Instalace oprav

1. Stáhněte a nainstalujte Azure DevOps Server 2020 Update 1.2 patch 8.

Aktualizace agenta Azure Pipelines

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

Poznámka

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

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

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

Požadavky na kanál

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

• V klasickém režimu:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• CVE-2023-36869: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• Aktualizujte službu SSH tak, aby podporovala SHA2-256 a SHA2-512. Pokud máte konfigurační soubory SSH pevně zakódované tak, aby používaly RSA, měli byste aktualizovat na SHA2 nebo položku odebrat.
• Byl vyřešen problém, kdy v souborech Markdownu nefungují relativní odkazy.
• Opravili jsme chybu s navigací komentářů na stránce potvrzení.
• Opravili jsme chybu, kdy se identita vlastníka analýzy zobrazovala jako neaktivní identita.
• Opravili jsme chybu nekonečné smyčky u CronScheduleJobExtension.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 6: 13. června 2023

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

• CVE-2023-21565: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• CVE-2023-21569: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• Opravili jsme chybu, která narušovala nabízení balíčků při upgradu z verze 2018 nebo starší.
• Opravili jsme chybu, kdy odpojení nebo připojení kolekce selhalo a hlásilo následující chybu: "TF246018: Operace databáze překročila časový limit a byla zrušena.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 5: 14. února 2023

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

• CVE-2023-21553: Azure DevOps Server ohrožení zabezpečení z důvodu možnosti vzdáleného spuštění kódu
• Oprava problému s přístupností sad odložených odložených dat prostřednictvím webového uživatelského rozhraní
• Po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu Azure DevOps Server musí zákazníci restartovat službu tfsjobagent a Azure DevOps Server fond aplikací.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 4: 13. prosince 2022

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

• Opravili jsme zobrazení speciálních znaků v IdentityPickeru.

• Testovací data nebyla odstraněna, což způsobilo zvětšení databáze. Touto opravou jsme aktualizovali uchovávání sestavení, aby se zabránilo vytváření nových osamocených testovacích dat.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 3: 18. října 2022

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

• Řešení problému s nově přidanými identitami AD, které se nezobrazují ve výběrech identit v dialogovém okně zabezpečení
• Opravili jsme problém s filtrem Requested by Member of Group v nastavení webhooku.
• Oprava chyby sestavení Hlídaný vracení se změnami, když nastavení organizace pro kanál mělo nakonfigurovaný obor autorizace úloh jako Omezit rozsah autorizace úloh na aktuální projekt pro kanály, které nejsou vydané verze.
• Oprava načítání přístupového tokenu z Azure při navazování připojení služby za ověřeným proxy serverem

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 2: 9. srpna 2022

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

• Oprava chyby hodnoty identity při přiřazování pracovní položky k identitě, která se zobrazuje v různých doménách

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2 Patch 1: 12. července 2022

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

• V rozhraních API testovacích běhů byl vrácený token pro pokračování větší než zadaná hodnota maxLastUpdatedDate.

datum vydání aktualizace Azure DevOps Server 2020 Update 1.2: 17. května 2022

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

Poznámka

Nástroj pro migraci dat bude k dispozici pro Azure DevOps Server 2020 Update 1.2 přibližně tři týdny po tomto vydání. Náš seznam aktuálně podporovaných verzí pro import najdete tady.

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

• Azure DevOps Server 2020.1.2 zakáže nový model uchovávání informací (zavedený v Azure DevOps Server 2020), aby se zabránilo ztrátě spuštění kanálu (buildů). To znamená, že systém:

  • Vytvoření zapůjčení pro nejnovější 3 buildy vygenerované při spuštění Serveru 2020
  • V případě kanálů YAML a klasických kanálů bez zásad uchovávání informací pro jednotlivé kanály se buildy zachovají podle nastavení maximálního uchovávání na úrovni kolekce.
  • V případě klasických kanálů s vlastními zásadami uchovávání informací pro jednotlivé kanály se buildy zachovají podle zásad uchovávání informací pro konkrétní kanály.
  • Buildy s zapůjčením se nezapočítávají do nastavení Minimum k zachování

• Odkazy komentářů ke sadě změn a sadě odložených změn se nepřesměrovávaly správně. Při přidání komentářů k souborům v sadách změn nebo sadách odložených změn se výběr těchto komentářů nepřesměrovává na správné místo v zobrazení souborů.

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

• Odvolání všech osobních přístupových tokenů po zakázání účtu služby Active Directory uživatele

Azure DevOps Server 2020.1.1 Patch 4 Datum vydání: 26. ledna 2022

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

• Email oznámení nebyla odeslána při použití @mention ovládacího prvku v pracovní položce.
• Upřednostňovaná e-mailová adresa se v profilu uživatele neaktualizovala. Výsledkem je odeslání e-mailů na předchozí e-mailovou adresu.
• Záhlaví se na stránce Souhrn projektu nezobrazuje. Záhlaví se zobrazovalo několik milisekund a pak zmizelo.
• Vylepšení synchronizace uživatelů služby Active Directory.
• Byla vyřešena chyba zabezpečení Elasticsearch odebráním třídy jndilookup z binárních souborů log4j.

Kroky instalace

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

Poznámka

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

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

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

datum vydání patche 3 Azure DevOps Server 2020.1.2020: 15. prosince 2021

Oprava 3 pro Azure DevOps Server 2020.1.1 obsahuje opravy pro následující:

• Oprava makra pracovní položky pro dotazy s textem "Obsahuje slova". Dříve dotazy vracely nesprávné výsledky pro hodnoty, které obsahovaly zalomení řádku.
• Zvyšte limity pro délku znaků verze balíčku Maven.
• 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 vyhodnocením pravidel NOTSAMEAS, když bylo pro pole definováno více pravidel NOTSAMEAS

Azure DevOps Server 2020.1.1 Patch 2 Datum vydání: 26. října 2021

Oprava 2 pro Azure DevOps Server 2020.1.1 obsahuje opravy pro následující:

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

Azure DevOps Server 2020.1.1 Patch 1 Datum vydání: 14. září 2021

Oprava 1 pro Azure DevOps Server 2020.1.1 obsahuje opravy pro následující:

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

Azure DevOps Server 2020 Update 1.1 Datum vydání: 17. srpna 2021

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

Poznámka

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

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

Azure Boards

• Hypertextový odkaz Zobrazit pracovní položku v e-mailech s oznámeními nepoužívá veřejnou adresu URL.

Azure Repos

• Opravili jsme zaškrtávací políčka dědičnosti omezených typů sloučení, která umožňovala po nastavení zásad křížové reposity upravit omezení typů sloučení.

Azure Pipelines

• Při změně nastavení aktualizace agenta se nastavení nešířilo do jiných aplikačních vrstev v prostředí.

Obecné

• Opravili jsme pravopis v průvodci konfigurací serveru.
• Větší velikost balíčku rozšíření a umožňuje změnit velikost v registru.

Azure Test Plans

• Po návratu z historie na stránku souhrnu nejde přejít zpět na výsledky testů.

---

Azure DevOps Server 2020.1 Patch 2 Datum vydání: 10. srpna 2021

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

• Opravte chybu uživatelského rozhraní definice sestavení.
• Změnila historii procházení tak, aby se místo kořenového úložiště zobrazovaly soubory.

Azure DevOps Server 2020.1 Patch 1 Datum vydání: 15. června 2021

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

• Zabezpečené soubory cookie používané v autorizačních tocích, které uplatňují SameSite=None.

• Vyřešte problém se sadou Sdk pro oznámení. Dříve se oznámení odběrů pomocí filtru Cesta k oblasti neanalybovala správně.

Azure DevOps Server 2020.1 RTW Datum vydání: 25. května 2021

Shrnutí novinek v Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW je sada oprav chyb. Obsahuje všechny funkce dříve vydané verze Azure DevOps Server 2020.1 RC2. Azure DevOps Server 2020.1 RTW je sada oprav chyb. Můžete přímo nainstalovat Azure DevOps Server 2020.1 nebo upgradovat z Azure DevOps Server 2020, 2019 nebo Team Foundation Server 2015 nebo novější.

Poznámka

Nástroj pro migraci dat bude pro aktualizaci Azure DevOps Server 2020 Update 1 k dispozici asi tři týdny po této verzi. Náš seznam aktuálně podporovaných verzí pro import najdete tady.

Azure DevOps Server 2020.1 RC2 Datum vydání: 13. dubna 2021

Shrnutí novinek v Azure DevOps Server 2020.1 RC2

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

Azure DevOps Server 2020.1 RC1 Datum vydání: 23. března 2021

Shrnutí novinek v Azure DevOps Server 2020.1 RC1

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

• Pravidla omezení přechodu stavu v panelech
• Účastníci teď můžou přesouvat pracovní položky napříč sloupci.
• Zlepšení zabezpečení verzí omezením rozsahu přístupových tokenů
• Vylepšené prostředí pro žádosti o přijetí změn
• Triggery s více úložišti v kanálech

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

• Boards
• Repos
• Pipelines
• Artifacts

---

Boards

Pravidla omezení přechodu stavu

Pokračujeme v uzavření rozdílu parity funkcí mezi hostovaným XML a zděděným modelem procesu. Toto nové pravidlo typu pracovní položky umožňuje omezit přesun pracovních položek z jednoho stavu do jiného. Můžete například omezit, aby chyby přechástaly z Nového na Vyřešené. Místo toho musí přejít z nabídky Nový –> Aktivní –> Vyřešeno.

Můžete také vytvořit pravidlo, které omezí přechody stavů členstvím ve skupině. Například jenom uživatelé ve skupině Schvalovatelé můžou přesouvat uživatelské scénáře ze položky Nový –> Schváleno.

Kopírovat pracovní položku pro kopírování podřízených položek

Jednou z nejžádaných funkcí pro Azure Boards je možnost zkopírovat pracovní položku, která kopíruje také podřízené pracovní položky. Do dialogového okna kopírování pracovní položky jsme přidali novou možnost Zahrnout podřízené pracovní položky. Pokud je tato možnost vybraná, zkopíruje pracovní položku a zkopíruje všechny podřízené pracovní položky (až 100).

Vylepšená pravidla pro aktivovaná a vyřešená pole

Až dosud byla pravidla pro Aktivovaný uživatel, Datum aktivace, Vyřešeno a Datum vyřešení záhadou. Jsou nastaveny pouze pro typy systémových pracovních položek a jsou specifické pro hodnoty stavu "Aktivní" a "Vyřešeno". Změnili jsme logiku tak, aby tato pravidla už nebyla určena pro konkrétní stav. Místo toho se aktivují podle kategorie (kategorie stavu), ve které se stav nachází. Řekněme například, že máte vlastní stav "Potřebuje testování" v kategorii Vyřešeno. Když se pracovní položka změní z "Aktivní" na "Vyžaduje testování", aktivují se pravidla Vyřešeno podle a Datum vyřešení .

To umožňuje zákazníkům vytvářet vlastní hodnoty stavu a stále generovat pole Aktivovaný, Datum aktivace, Vyřešeno a Datum vyřešení , aniž by museli používat vlastní pravidla.

Účastníci můžou přesouvat pracovní položky napříč sloupci

Zúčastněné strany vždy mohly změnit stav pracovních položek. Když ale přejdou na panel Kanbanu, nemůžou přesunout pracovní položky z jednoho sloupce do druhého. Místo toho by účastníci museli jednu po druhé otevřít každou pracovní položku a aktualizovat hodnotu stavu. Toto je pro zákazníky už dlouhou dobu problematickou věcí a s radostí oznamujeme, že teď můžete přesouvat pracovní položky napříč sloupci.

Typy systémových pracovních položek v backlogech a panelech

Teď můžete přidat typ systémové pracovní položky do zvolené úrovně backlogu. V minulosti byly tyto typy pracovních položek dostupné pouze z dotazů.

Proces	Typ pracovní položky
Agilita	Problém
Scrum	Překážka
CMMI	Žádost o změnu
	Problém
	Opakování
	Riziko

Přidání typu systémové pracovní položky na úroveň backlogu je jednoduché. Stačí přejít do vlastního procesu a kliknout na kartu Úrovně backlogu. Vyberte požadovanou úroveň backlogu (příklad: Backlog požadavků) a zvolte možnost úprav. Pak přidejte typ pracovní položky.

Azure Boards zvýšení limitu úložiště aplikace GitHub

Limit úložiště pro aplikaci Azure Boards na marketplace GitHubu se zvýšil ze 100 na 250.

Přizpůsobení stavu pracovní položky při sloučení žádosti o přijetí změn

Ne všechny pracovní postupy jsou stejné. Někteří zákazníci chtějí po dokončení žádosti o přijetí změn zavřít související pracovní položky. Jiní chtějí nastavit pracovní položky do jiného stavu, který se má před uzavřením ověřit. Měli bychom povolit obojí.

Máme novou funkci, která umožňuje nastavit pracovní položky do požadovaného stavu při sloučení a dokončení žádosti o přijetí změn. Provedeme to tak, že projdeme popis žádosti o přijetí změn a vyhledáme hodnotu stavu následovanou #mention pracovních položek. V tomto příkladu nastavíme dva uživatelské scénáře na Vyřešeno a zavřeme dvě úlohy.

Propojení pracovní položky se sestaveními v jiném projektu

Teď můžete snadno sledovat závislosti sestavení napříč projektem jenom tak, že pracovní položku propojíte s sestavením, Nalezeno v sestavení nebo Integrované v sestavení.

Úprava popisu (textu nápovědy) v systémových polích

Popis vlastních polí jste mohli vždy upravit. U systémových polí, jako je priorita, závažnost a aktivita, se ale popis nedá upravovat. Jednalo se o mezeru mezi funkcemi hostovaného xml a zděděného kódu, která některým zákazníkům bránila v migraci na model zděděné. Teď můžete upravit popis systémových polí. Upravená hodnota ovlivní pouze toto pole v procesu a pro daný typ pracovní položky. Díky tomu můžete mít různé popisy stejného pole pro různé typy pracovních položek.

Přizpůsobení stavu pracovní položky při sloučení žádosti o přijetí změn

Žádosti o přijetí změn často odkazují na více pracovních položek. Při vytváření nebo aktualizaci žádosti o přijetí změn můžete chtít některé z nich zavřít, vyřešit některé z nich a nechat zbytek otevřený. K tomu teď můžete použít komentáře, jako jsou ty, které jsou znázorněné na obrázku níže. Další podrobnosti najdete v dokumentaci.

Nadřazené pole na panelu úkolů

Kvůli oblíbené žádosti teď můžete přidat pole Nadřazené na podřízenou i nadřazenou kartu na panelu úkolů.

Odebrání pravidla Přiřazeno u typu pracovní položky chyby

Existuje několik skrytých systémových pravidel napříč všemi různými typy pracovních položek v agilních, scrumových a CMMI. Tato pravidla existují už více než deset let a obecně fungovala bez jakýchkoliv stížností. Existuje však několik pravidel, která jsou uvítaná. Zvlášť jedno pravidlo způsobilo velkou bolest novým i stávajícím zákazníkům a rozhodli jsme se, že je čas ho odstranit. Toto pravidlo existuje pro typ pracovní položky Chyba v procesu agilního procesu.

"Nastavit přiřazenou hodnotu na Vytvořeno, když se stav změní na Vyřešeno"

K tomuto pravidlu jsme dostali spoustu vašich připomínek. V reakci na to jsme pokračovali a odebrali toto pravidlo z typu pracovní položky Chyba v agilním procesu. Tato změna ovlivní každý projekt používající zděděný agilní nebo přizpůsobený zděděný agilní proces. Pro zákazníky, kteří mají toto aktuální pravidlo rádi a jsou na něm závislí, podívejte se prosím na náš blogový příspěvek s kroky, které můžete provést k opětovnému přidání pravidla pomocí vlastních pravidel.

Odebrané položky na stránce Pracovní položky

Stránka Pracovní položky je skvělým místem, kde můžete rychle najít položky, které jste vytvořili nebo které jsou vám přiřazené, mimo jiné. Poskytuje několik přizpůsobených pivotů a filtrů. Jednou z nejčastějších stížností u kontingenčního panelu "Přiřazeno ke mně" je, že zobrazuje odebrané pracovní položky (to znamená pracovní položky ve stavu Odebrané). A souhlasíme! Odebrané položky jsou práce, která už nemá žádnou hodnotu, a proto byla odebrána z backlogu, takže zahrnutí do tohoto zobrazení není užitečné.

Teď můžete skrýt všechny odebrané položky z kontingenčního pole Přiřazeno mně na stránce Pracovní položky.

Repos

Výchozí předvolba názvu větve

Azure Repos teď nabízí přizpůsobitelný výchozí název větve pro Git. V nastavení úložiště můžete zvolit libovolný název právní větve, který se má použít při inicializaci úložiště. Azure Repos vždy podporoval změnu výchozího názvu větve pro existující úložiště. Další podrobnosti najdete v tématu Správa větví .

 

Poznámka: Pokud tuto funkci nepovolíte, vaše úložiště se inicializují s výchozím názvem Azure Repos. Právě teď je to výchozí master. Abychom dodržel závazek Microsoftu a požadavky zákazníků na inkluzivní jazyk, připojíme se k partnerům v oboru a změníme toto výchozí nastavení na main. K této změně dojde později v létě. Pokud chcete dál používat předlohu, měli byste tuto funkci zapnout a nastavit ji na hlavní.

Nastavení na úrovni organizace pro výchozí větev

Teď je k dispozici nastavení na úrovni kolekce pro upřednostňovaný počáteční název větve pro nová úložiště. Pokud projekt nezvolil počáteční název větve, použije se toto nastavení na úrovni organizace. Pokud jste v nastavení organizace nebo v nastavení projektu nezadali počáteční název větve, budou nová úložiště používat výchozí definovanou službu Azure DevOps.

Přidání nového rozsahu ověřování pro přispívání komentářů k žádosti o přijetí změn

Tato verze přidává nový obor OAuth pro čtení a zápis komentářů žádostí o přijetí změn. Pokud máte robota nebo automatizaci, která potřebuje jenom pracovat s komentáři, můžete mu dát PAT jenom s tímto oborem. Tento proces snižuje poloměr výbuchu, pokud má automatizace chybu nebo pokud došlo k ohrožení tokenu.

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

Nové prostředí žádostí o přijetí změn bylo vylepšeno o následující:

• Zviditelnění volitelných kontrol

Zákazníci používají volitelné kontroly, aby upoutli pozornost vývojáře na potenciální problémy. V předchozím prostředí to bývalo zřejmé, když tyto kontroly selžou. To ale není případ prostředí preview. Velké zelené zaškrtnutí požadovaných kontrol maskuje chyby v volitelných kontrolách. Uživatelé můžou zjistit, že volitelné kontroly selhaly, pouze otevřením kontrolního panelu. Vývojáři to často nedělají, když nic nenasvědčuje problému. V tomto nasazení jsme stav volitelných kontrol zviditelnili v souhrnu.

• Kliknutí se stisknutou klávesou Ctrl na položky nabídky

Nabídky karet v žádosti o přijetí změn nepodporují kliknutí se stisknutou klávesou Ctrl. Uživatelé často při kontrole žádosti o přijetí změn otevírají nové karty prohlížeče. To jsme opravili.

• Umístění poznámky [+]

Stromový seznam souborů v žádosti o přijetí změn zobrazuje poznámku [+], která autorům a recenzentům pomáhá identifikovat nové soubory. Vzhledem k tomu, že poznámka byla za třemi tečky, nebyla u delších názvů souborů často viditelná.

• Rozevírací seznam aktualizací žádosti o přijetí změn – informace o opětovném načasování

Rozevírací seznam pro výběr aktualizace a porovnání souborů v žádosti o přijetí změn ztratil důležitý prvek v prostředí preview. Při provedení této aktualizace se nezobrazuje. To jsme opravili.

• **Vylepšené rozložení filtru komentářů **

Při filtrování komentářů na souhrnné stránce žádosti o přijetí změn byl rozevírací seznam vpravo, ale text byl zarovnaný doleva. To jsme opravili.

• Navigace na nadřazená potvrzení

Na stránce Potvrzení můžete porovnat změny provedené v určitém potvrzení s nadřazeným potvrzením. Můžete ale chtít přejít na nadřazené potvrzení a dále pochopit, jak se toto potvrzení liší od jeho vlastní nadřazené položky. To je často potřeba, když chcete porozumět všem změnám ve vydané verzi. Přidali jsme do potvrzení kartu rodiče, která vám to pomůže.

• Více místa pro složky a soubory s dlouhými názvy na kartě Soubory žádosti o přijetí změn

Složky a soubory s dlouhými názvy byly oříznuty kvůli nedostatku vodorovných mezer ve stromu souborů. Další místo ve stromu jsme obnovili úpravou odsazení stromu tak, aby odpovídalo kořenovému uzlu, a skrytím tlačítka se třemi tečky na stránce s výjimkou při najetí myší.

Obrázek nové stromové struktury souborů:

Obrázek stromu souborů při najetí myší na adresář:

• Zachovat pozici posouvání při změně velikosti podokna rozdílů na kartě Soubory žádostí o přijetí změn

Při změně velikosti podokna rozdílů vedle sebe na kartě souborů žádostí o přijetí změn by došlo ke ztrátě umístění posouvání uživatele. Tento problém byl opraven. umístění posouvání uživatele se teď zachová při změně velikosti rozdílového podokna.

• Vyhledání potvrzení na mobilním zařízení

Při prohlížení stránky Potvrzení na mobilním zařízení chybí vyhledávací pole v novém prostředí. V důsledku toho je pro vás těžké najít potvrzení podle jeho hodnoty hash a otevřít ho. To je teď opravené.

• Vylepšené využití místa pro nové soubory žádostí o přijetí změn v mobilním zobrazení

Tuto stránku jsme aktualizovali tak, aby lépe využívala místo, aby uživatelé viděli větší část souboru v mobilních zobrazeních a nemuseli 40 % obrazovky zabírat záhlaví.

• Vylepšené obrázky v zobrazení souhrnu žádostí o přijetí změn

Obrázky upravené v žádosti o přijetí změn se v zobrazení souhrnu žádosti o přijetí změn nezobrazovaly, ale správně se zobrazily v zobrazení souborů žádostí o přijetí změn. Tento problém je vyřešený.

• Vylepšené prostředí větve při vytváření nové žádosti o přijetí změn

Před touto aktualizací nebylo toto prostředí ideální, protože by porovnávalo změny s výchozí větví úložiště místo s větví compare.

Pipelines

Další platforma agenta: ARM64

Do seznamu podporovaných platforem pro agenta Azure Pipelines jsme přidali Linux/ARM64. I když byly změny kódu minimální, bylo nejprve potřeba dokončit spoustu práce na pozadí a s radostí oznamujeme vydání tohoto kódu.

Podpora filtru značek pro prostředky kanálu

Teď jsme do kanálů YAML přidali značky. Značky můžete použít k nastavení spuštění kanálu CI nebo k automatické aktivaci.

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

Výše uvedený fragment kódu ukazuje, že značky je možné použít k určení výchozí verze kanálu CI (kontinuální integrace), který se má spustit, když spuštění kanálu CD (průběžné nasazování) není aktivováno jiným zdrojem nebo prostředkem nebo naplánovaným triggerem spuštění.

Pokud máte například naplánovanou aktivační událost nastavenou pro kanál CD, kterou chcete spustit jenom v případě, že má ci značku produkčního prostředí, značky v části aktivačních událostí zajistí, že se kanál CD aktivuje jenom v případě, že událost dokončení CI splní podmínku označení.

Řízení, které úlohy jsou povolené v kanálech

Úlohy z Marketplace teď můžete zakázat. Někteří z vás můžou povolit rozšíření Marketplace, ale ne úlohy Pipelines, které s sebou přinášejí. Pro ještě větší kontrolu vám také umožňujeme nezávisle zakázat všechny úkoly v balení (s výjimkou rezervace, což je speciální akce). Když jsou obě tato nastavení povolená, jediné úlohy, které se můžou spouštět v kanálu, budou ty, které se nahrají pomocí tfx. Začněte tím, že navštívíte https://dev.azure.com/<your_org>/_settings/pipelinessettings část s názvem Omezení úkolů a vyhledáte ji.

Zásady výhradního zámku nasazení

Díky této aktualizaci můžete zajistit, že se do prostředí nasadí jenom jedno spuštění najednou. Když v prostředí zvolíte kontrolu Výhradní zámek, bude pokračovat pouze jedno spuštění. Další spuštění, která chtějí nasadit do daného prostředí, se pozastaví. Po dokončení spuštění s výhradním zámkem bude pokračovat nejnovější spuštění. Všechna průběžná spuštění budou zrušena.

Filtry fází pro triggery prostředků kanálu

Přidali jsme podporu pro fáze jako filtr prostředků kanálu v YAML. S tímto filtrem nemusíte čekat na dokončení celého kanálu CI, aby se aktivovalo kanál CD. Kanál CD teď můžete aktivovat po dokončení konkrétní fáze v kanálu CI.

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

Po úspěšném dokončení fází uvedených ve filtru triggeru ve vašem kanálu CI se automaticky aktivuje nové spuštění pro váš kanál CD.

Triggery založené na obecném webhooku pro kanály YAML

Dnes máme různé prostředky (například kanály, kontejnery, sestavení a balíčky), jejichž prostřednictvím můžete využívat artefakty a povolit automatizované triggery. Dosud však nebylo možné automatizovat proces nasazení na základě jiných externích událostí nebo služeb. V této verzi zavádíme podporu triggerů webhooků v kanálech YAML, která umožňuje integraci automatizace kanálů s jakoukoli externí službou. Můžete se přihlásit k odběru externích událostí prostřednictvím jejich webhooků (GitHub, GitHub Enterprise, Nexus, Aritfactory atd.) a aktivovat kanály.

Tady je postup konfigurace triggerů webhooku:

1. Nastavte webhook v externí službě. Při vytváření webhooku musíte zadat následující informace:

   • Adresa URL požadavku –https://dev.azure.com/< ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
   • Tajný kód – tato možnost je volitelná. Pokud potřebujete zabezpečit datovou část JSON, zadejte hodnotu Tajný kód .

2. Vytvořte nové připojení služby příchozího webhooku. Jedná se o nově zavedený typ připojení služby, který vám umožní definovat tři důležité informace:

   • Název webhooku: Název webhooku by se měl shodovat s webhookem vytvořeným ve vaší externí službě.
   • Hlavička HTTP – název hlavičky HTTP v požadavku, která obsahuje hodnotu hash datové části pro ověření požadavku. Například v případě GitHubu bude hlavička požadavku "X-Hub-Signature".
   • Tajný klíč – tajný klíč se používá k analýze hodnoty hash datové části používané k ověření příchozího požadavku (to je volitelné). Pokud jste při vytváření webhooku použili tajný kód, budete muset zadat stejný tajný klíč.

   

3. V kanálech YAML se zavádí nový typ prostředku s názvem webhooks . Pokud se chcete přihlásit k odběru události webhooku, musíte ve svém kanálu definovat prostředek webhooku a nasměrovat ho na připojení příchozí služby webhooku. Můžete také definovat další filtry pro prostředek webhooku na základě dat datové části JSON a dále přizpůsobit aktivační události pro každý kanál a data datové části můžete využívat ve formě proměnných ve vašich úlohách.

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

4. Pokaždé, když připojení služby Příchozí webhook obdrží událost webhooku, pro všechny kanály přihlášené k odběru události webhooku se aktivuje nové spuštění.

Problémy s triggery prostředků YAML – podpora a sledovatelnost

Může být matoucí, když se triggery kanálu nespustí podle očekávání. Abychom tomu lépe porozuměli, přidali jsme na stránku definice kanálu novou položku nabídky s názvem "Problémy s aktivačními událostmi", kde se zobrazí informace o tom, proč se triggery nespouštějí.

Triggery prostředků se můžou podařit spustit ze dvou důvodů.

1. Pokud je zdroj zadaného připojení služby neplatný nebo pokud trigger obsahuje chyby syntaxe, aktivační událost se vůbec nenakonfiguruje. Tyto chyby se zobrazují jako chyby.

2. Pokud se podmínky triggeru neshodují, aktivační událost se nespustí. Kdykoli k tomu dojde, zobrazí se upozornění, abyste pochopili, proč podmínky nebyly splněny.

   

Triggery s více úložišti

V jednom souboru YAML můžete zadat několik úložišť a způsobit aktivaci kanálu aktualizací libovolného úložiště. Tato funkce je užitečná například v následujících scénářích:

• Používáte nástroj nebo knihovnu z jiného úložiště. Testy pro vaši aplikaci chcete spouštět při každé aktualizaci nástroje nebo knihovny.
• Soubor YAML uchováváte v samostatném úložišti, než je kód aplikace. Kanál chcete aktivovat pokaždé, když se aktualizace odešle do úložiště aplikace.

S touto aktualizací budou triggery s více úložišti fungovat jenom pro úložiště Git v Azure Repos. Nefungují pro prostředky úložiště GitHub nebo BitBucket.

Tady je příklad, který ukazuje, jak definovat více prostředků úložiště v kanálu a jak nakonfigurovat triggery pro všechny z nich.

trigger:
- main

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

Kanál v tomto příkladu se aktivuje, pokud dojde k nějakým aktualizacím pro:

• main větev v úložišti self obsahujícím soubor YAML
• main nebo release větve v tools úložišti

Další informace najdete v tématu Více úložišť v kanálu.

Vylepšené nahrávání protokolů agentů

Když agent přestane komunikovat se serverem Azure Pipelines, úloha, která byla spuštěná, se zruší. Pokud jste se náhodou dívali na protokoly konzoly streamování, možná jste získali nějaké informace o tom, co agent dělal, než přestal reagovat. Pokud jste to ale neudělali nebo jste stránku aktualizovali, tyto protokoly konzoly zmizely. Pokud v této verzi agent přestane reagovat dříve, než odešle úplné protokoly, jako další nejlepší věc budeme uchovávat protokoly konzoly. Protokoly konzoly jsou omezené na 1 000 znaků na řádek a někdy můžou být neúplné, ale jsou mnohem užitečnější než nic neukazovat. Prozkoumání těchto protokolů vám může pomoct s řešením potíží s vlastními kanály a určitě pomůže našim technikům podpory, když vám pomůžou s řešením potíží.

Volitelné připojení svazků kontejnerů jen pro čtení

Když spustíte úlohu kontejneru v Azure Pipelines, několik svazků obsahujících pracovní prostor, úlohy a další materiály se namapují jako svazky. Tyto svazky mají ve výchozím nastavení přístup pro čtení i zápis. Kvůli zvýšenému zabezpečení můžete svazky připojit jen pro čtení změnou specifikace kontejneru v YAML. Každý klíč v části mountReadOnly se dá nastavit na true pro jen pro čtení (výchozí hodnota je false).

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

Jemně odstupňovaná kontrola nad spuštěním/zastavením kontejneru

Obecně doporučujeme povolit službě Azure Pipelines správu životního cyklu vašich úloh a kontejnerů služeb. V některých neobvyklých scénářích je ale možná budete chtít spustit a zastavit sami. V této verzi jsme tuto funkci zabudovali do úlohy Dockeru.

Tady je příklad kanálu využívajícího novou funkci:

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

Zahrneme také seznam kontejnerů v proměnné Agent.ContainerMappingkanálu . Můžete ho použít například v případě, že chcete zkontrolovat seznam kontejnerů ve skriptu. Obsahuje řetězcový objekt JSON, který mapuje název prostředku (tvůrce z výše uvedeného příkladu) na ID kontejneru spravovaného agentem.

Rozbalení sad úkolů pro každý krok

Když agent spustí úlohu, nejprve stáhne všechny sady úloh vyžadované kroky úlohy. Za normálních okolností se kvůli výkonu rozbalí úkoly jednou pro každou úlohu, a to i v případě, že se úloha používá ve více krocích. Pokud máte obavy z toho, že nedůvěryhodný kód změní rozbalený obsah, můžete trochu zaměnit výkon tím, že necháte agenta rozbalit úlohu při každém použití. Pokud chcete tento režim povolit, předejte --alwaysextracttask ho při konfiguraci agenta.

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

Na základě naší iniciativy na vylepšení nastavení zabezpečení pro Azure Pipelines teď podporujeme omezení rozsahu přístupových tokenů pro vydané verze.

Každá úloha, která se spustí ve vydaných verzích, získá přístupový token. Přístupový token používají úlohy a vaše skripty k zpětnému volání do Azure DevOps. Přístupový token používáme například k získání zdrojového kódu, stahování artefaktů, nahrávání protokolů, výsledků testů nebo k volání REST do Azure DevOps. Pro každou úlohu se vygeneruje nový přístupový token, který po dokončení úlohy vyprší.

V této aktualizaci stavíme na vylepšení zabezpečení kanálu tím, že omezíme rozsah přístupových tokenů a rozšíříme ho i na klasické verze.

Tato funkce bude u nových projektů a kolekcí ve výchozím nastavení zapnutá. U existujících kolekcí ho musíte povolit v Nastavení kolekce Nastavení > Kanály > Nastavení. > Omezte rozsah autorizace úloh na aktuální projekt pro kanály verze. Další informace najdete tady.

Vylepšení rozhraní API YAML ve verzi Preview

Teď můžete zobrazit náhled úplného YAML kanálu bez jeho spuštění. Kromě toho jsme vytvořili novou vyhrazenou adresu URL pro funkci Preview. Teď můžete post načíst https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview finalizované tělo YAML. Toto nové rozhraní API přijímá stejné parametry jako řazení spuštění do fronty, ale už nevyžaduje oprávnění Sestavení fronty.

Další spuštění této úlohy

Už jste někdy měli opravenou chybu, kterou jste potřebovali nasadit v této minutě, ale museli jste čekat za úlohami CI a PR? V této verzi vám teď umožňujeme narazit na prioritu úlohy zařazené do fronty. Uživatelům s oprávněním Spravovat ve fondu ( obvykle správcům fondu) se na stránce podrobností úlohy zobrazí nové tlačítko Spustit další. Kliknutím na tlačítko nastavíte úlohu tak, aby se spustila co nejdříve. (Samozřejmě stále budete potřebovat dostupný paralelismus a vhodného agenta.)

Výrazy šablon povolené v bloku YAML resources

Dříve nebyly v resources části souboru YAML služby Azure Pipelines povoleny výrazy kompilace (${{ }}). V této verzi jsme toto omezení pro kontejnery zrušili. To vám umožní použít obsah parametrů modulu runtime uvnitř vašich prostředků, například k výběru kontejneru v době fronty. Tuto podporu plánujeme časem rozšířit i na další zdroje.

Kontrola nad automatizovanými aktualizacemi úloh z Marketplace

Při psaní kanálu YAML obvykle zadáte pouze číslo hlavní verze zahrnutých úloh. Díky tomu budou vaše kanály automaticky přijímat nejnovější přidané funkce a opravy chyb. V některých případech může být potřeba vrátit se k předchozí verzi úkolu a touto aktualizací jsme přidali možnost, abyste to udělali. Teď můžete v kanálech YAML zadat úplnou verzi úlohy major.minor.patch.

Nedoporučujeme to dělat pravidelně a používat ho jenom jako dočasné alternativní řešení, když zjistíte, že novější úloha přeruší vaše kanály. Tím se také nenainstaluje starší verze úlohy z Marketplace. V kolekci už musí existovat, jinak kanál selže.

Příklad:

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

Podpora Node 10 v agentech a úlohách

Vzhledem k tomu, že uzel Node 6 se už nepodporuje, migrujeme úkoly tak, aby fungovaly s Uzlem 10. V rámci této aktualizace jsme migrovali téměř 50 % úkolů v balení do uzlu 10. Agent teď může spouštět úlohy Node 6 i Node 10. V budoucí aktualizaci úplně odebereme Uzel 6 z agenta. V rámci přípravy na odebrání uzlu 6 z agenta vás žádáme, abyste brzy aktualizovali svá interní rozšíření a vlastní úlohy tak, aby používaly také Node 10. Pokud chcete pro svůj úkol použít Uzel 10, aktualizujte task.jsonv části executionz na NodeNode10.

Vylepšení převodu YAML v klasickém návrháři sestavení

V této verzi zavádíme novou funkci exportu do YAML pro kanály sestavení návrháře. Uložte definici kanálu a pak v ... nabídce vyhledejte "Exportovat do YAML".

Nová funkce exportu nahrazuje funkci Zobrazit jako YAML, která se dříve nacházela v klasickém návrháři sestavení. Tato funkce byla neúplná, protože mohla pouze zkontrolovat, co webové uživatelské rozhraní vědělo o sestavení, což někdy vedlo k vygenerování nesprávného YAML. Nová funkce exportu přesně bere v úvahu, jak se kanál zpracuje, a vygeneruje YAML s úplnou věrností kanálu návrháře.

Nový převod webové platformy – nastavení úložiště

Převedli jsme dvě stránky nastavení úložiště na jedno prostředí, které bylo upgradováno na novou webovou platformu. Díky tomuto upgradu je prostředí nejen rychlejší a modernější, ale tyto stránky také poskytují jeden vstupní bod pro všechny zásady od úrovně projektu až po větev.

Díky tomuto novému prostředí se navigace u projektů s velkým počtem úložišť zjednodušila díky rychlejšímu načítání a přidanému vyhledávacímu filtru. Na kartě Zásady můžete také zobrazit zásady na úrovni projektu a seznam zásad křížového úložiště.

Pokud kliknete na úložiště, můžete zobrazit zásady a oprávnění nastavená na úrovni úložiště. Na kartě Zásady můžete zobrazit seznam všech větví, ve které jsou zásady nastavené. Teď klikněte na větev, abyste zobrazili zásady, aniž byste opustili stránku nastavení úložiště.

Když se zásady zdědí z vyššího oboru, než se kterým pracujete, ukážeme vám, odkud se zásady zdědily vedle jednotlivých zásad. Kliknutím na název oboru můžete také přejít na stránku, kde byla nastavena zásada vyšší úrovně.

Samotná stránka zásad byla také upgradována na novou webovou platformu se sbalitelnými oddíly. Abychom zlepšili možnosti hledání konkrétní zásady ověření sestavení, kontroly stavu nebo automatického revidování, přidali jsme filtry vyhledávání pro jednotlivé oddíly.

Integrace správy změn ServiceNow s kanály YAML

Aplikace Azure Pipelines pro ServiceNow pomáhá integrovat Azure Pipelines a Správu změn ServiceNow. Touto aktualizací se vydáme na cestu k tomu, aby služba Azure Pipelines věděla o procesu správy změn spravovaném v ServiceNow dále ke kanálům YAML.

Když u prostředku nakonfigurujete kontrolu Správy změn ServiceNow, můžete se teď pozastavit, aby se změna schválila před nasazením sestavení do daného prostředku. Můžete automaticky vytvořit novou změnu pro fázi nebo počkat na existující žádost o změnu.

Můžete také přidat UpdateServiceNowChangeRequest úlohu do úlohy serveru a aktualizovat žádost o změnu o stav nasazení, poznámky atd.

Artifacts

Možnost vytvářet informační kanály v rámci organizace z uživatelského rozhraní

Zákazníkům vracíme možnost vytvářet a spravovat informační kanály v rozsahu kolekce prostřednictvím webového uživatelského rozhraní pro místní i hostované služby.

Informační kanály s oborem organizace teď můžete vytvářet prostřednictvím uživatelského rozhraní tak, že přejdete do části Artefakty –> Vytvořit informační kanál a zvolíte typ informačního kanálu v rámci oboru.

I když doporučujeme používat kanály vymezené projektem v souladu se zbytkem nabídek Azure DevOps, můžete znovu vytvářet, spravovat a používat informační kanály s oborem kolekce prostřednictvím uživatelského rozhraní a různých rozhraní REST API. Další informace najdete v naší dokumentaci k informačním kanálům.

Rozhraní REST API pro aktualizaci verze balíčku je teď k dispozici pro balíčky Mavenu

K aktualizaci verzí balíčků Mavenu teď můžete použít rozhraní REST API Aktualizace balíčku Azure Artifacts. Dříve jste mohli použít rozhraní REST API k aktualizaci verzí balíčků pro balíčky NuGet, Maven, npm a Universal Packages, ale ne pro balíčky Maven.

Pokud chcete aktualizovat balíčky Mavenu, použijte příkaz HTTP PATCH následujícím způsobem.

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

Můžete nastavit následující:

Parametry identifikátoru URI

Název	V	Povinné	Typ	Popis
artifactId	program	TRUE	řetězec	ID artefaktu balíčku
Krmivo	program	TRUE	řetězec	Název nebo ID informačního kanálu
groupId	program	TRUE	řetězec	ID skupiny balíčku
– kolekce	program	TRUE	řetězec	Název kolekce Azure DevOps
verze	program	TRUE	řetězec	Verze balíčku
projekt	program		řetězec	ID projektu nebo název projektu
verze-api	query	TRUE	řetězec	Verze rozhraní API, která se má použít. Aby se tato verze rozhraní API používala, měla by být nastavená na 5.1-preview.1.

Text požadavku

Název	Typ	Popis
zobrazení	JsonPatchOperation	Zobrazení, do kterého se přidá verze balíčku

Další informace najdete v dokumentaci k rozhraní REST API při jeho aktualizaci.

Zpětná vazba

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

---

Začátek stránky