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

| Licenční podmínky licenčních podmínek | pro požadavky na | systém vývojářů DevOps Blog | 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 2020 se podporuje z Azure DevOps Serveru 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud je vaše nasazení TFS na TFS 2010 nebo starší, musíte před upgradem na Azure DevOps Server 2019 provést ně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 spuštění kanálu (sestavení), který funguje na základě nastavení na úrovni projektu.

Azure DevOps Server 2020 zpracovává uchovávání sestavení odlišně na základě zásad uchovávání na úrovni kanálu. Některé konfigurace zásad vedou k odstranění spuštění kanálu 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í 1.2 opravy 14 Pro Azure DevOps Server 2020: 12. listopadu 2024

Soubor	Hodnota hash SHA-256
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Vydali jsme opravu 14 pro Azure DevOps Server 2020 Update 1.2, která zahrnuje upgrade na ohroženou závislost.

Datum vydání 1.2 opravy 13 Azure DevOps Serveru 2020: 12. března 2024

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

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

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

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

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

Vydali jsme opravu 12 pro 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 používané složkou mezipaměti proxy serveru a složka nebyla správně vyčištěna.
• CVE-2024-20667: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu v Azure DevOps Serveru

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

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

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

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

Datum vydání 1.2 opravy 10 Azure DevOps Serveru 2020: 14. listopadu 2023

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

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

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 8 vydané 12. září 2023. Pokud jste nenainstalovali aktualizace agenta, jak je popsáno v poznámkách k verzi pro Opravu 8, doporučujeme nainstalovat tyto aktualizace před instalací opravy 10. Nová verze agenta po instalaci 8 bude 3.225.0.

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

Soubor	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 prostředí:

  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 aktualizací Patch 8 vydané 12. září 2023. Pokud jste aktualizace agenta nenainstalovali, jak je popsáno v poznámkách k verzi pro opravu Patch 8, doporučujeme nainstalovat tyto aktualizace před instalací 9. Nová verze agenta po instalaci 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íka analýzy na počítačích s upgradem oprav zobrazovala jako neaktivní identita.

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

Vydali jsme opravu pro Azure DevOps Server 2020 Update 1.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 1.2 8.

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 downgradu agenta, musí být AZP_AGENT_DOWNGRADE_DISABLED nastavená 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 k nahrání úkolů do kolekce projektů 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 prostředí:

  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í 7 opravy Azure DevOps Server 2020 Update 1.2: 8. srpna 2023

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

• CVE-2023-36869: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• Aktualizujte službu SSH tak, aby podporovala SHA2-256 a SHA2-512. Pokud máte pevně zakódované konfigurační soubory SSH pro použití RSA, měli byste položku aktualizovat na SHA2 nebo ji odebrat.
• Vyřešili jsme problém s nefunkčními relativními odkazy v souborech Markdownu.
• Opravili jsme chybu s navigačními komentáři na stránce potvrzení.
• Opravili jsme chybu, kdy se identita vlastníka analýzy zobrazovala jako neaktivní identita.
• Oprava chyby 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: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• CVE-2023-21569: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• Opravili jsme chybu, která způsobovala narušení odesílání balíčků při upgradu z verze 2018 nebo starší.
• Opravili jsme chybu, která způsobovala, že odpojení nebo připojení kolekce selhalo s oznámením následující chyby: "TF246018: Operace databáze překročila limit časového limitu 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: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu serveru Azure DevOps
• Oprava potíží s přístupností sad odložených adres prostřednictvím webového uživatelského rozhraní
• Zákazníci musí po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu serveru Azure DevOps restartovat službu tfsjobagent a fond aplikací Azure DevOps Serveru.

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í:

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

• Testovací data se neodstranila a databáze se zvětšovala. S touto opravou jsme aktualizovali uchovávání sestavení, abychom zabránili vytváření nových osamocených testovacích dat.

Datum vydání 3 opravy Azure DevOps Server 2020 Update 1.2: 18. října 2022

Vydali jsme opravu pro Azure DevOps Server 2020 Update 1.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žadovaného člena skupiny v nastavení webového háku.
• Opravachybych
• Oprava načítání přístupového tokenu z Azure při vytváření 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 1.2 Patch 1 Pro Azure DevOps Server 2020: 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ž hodnota maxLastUpdatedDate, která byla zadána.

Datum vydání Azure DevOps Serveru 2020 Update 1.2: 17. května 2022

Azure DevOps Server 2020 Update 1.2 představuje opravy chyb. Azure DevOps Server 2020 Update 1.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 Update 1.2 asi tři týdny od této verze. 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 Serveru 2020), aby se zabránilo ztrátě spuštění kanálu (buildů). To znamená, že systém bude:

  • Vytvoření zapůjčení pro nejnovější 3 vygenerované buildy při spuštění Serveru 2020
  • U kanálů YAML a klasických kanálů bez zásad uchovávání jednotlivých kanálů se buildy zachovají podle nastavení maximálního uchovávání na úrovni kolekce.
  • U 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ál.
  • Sestavení s zapůjčením se nezapočítávají do minimálního nastavení.

• Odkazy na sady změn a komentáře sady odložených změn se nepřesměrovaly správně. Když byly komentáře přidány do souborů v sadách změn nebo sadách odložených změn, výběr těchto komentářů se nepřesměroval na správné místo v zobrazení souborů.

• Frontu sestavení nelze přeskočit pomocí tlačítka Spustit další. Dříve se pro správce kolekcí projektů povolilo tlačítko Spustit další.

• Po zakázání účtu služby Active Directory uživatele zrušte všechny tokeny patu.

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

Vydali jsme opravu pro Azure DevOps Server 2020.1.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í.
• 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í nebylo zobrazeno na stránce Souhrn projektu. Záhlaví se zobrazilo na několik milisekund a pak zmizelo.
• 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. Upgradujte server pomocí opravy 4.
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 4.
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ý ve C:\Program Files\{TFS Version Folder}\Search\zip vzdálené složce Elasticsearch.
4. Spusťte Configure-TFSSearch.ps1 -Operation update na počítači serveru Elasticsearch.

Hash SHA-256: 451F0BB73132EFCD2B3D292F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Datum vydání 3 opravy Azure DevOps Serveru 2020.1.1: 15. prosince 2021

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

• Opravte makro pracovní položky pro dotazy s textem Obsahuje slova. Dříve dotazy vracely nesprávné výsledky pro hodnoty, které obsahovaly konec řádku.
• Zvyšte limity pro délku znaku 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 při definování více pravidel NOTSAMEAS pro pole

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

Oprava 2 pro Azure DevOps Server 2020.1.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. Sestava spuštění testu zobrazovala nesprávné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í 1 opravy Azure DevOps Serveru 2020.1.1: 14. září 2021

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

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

Datum vydání azure DevOps Serveru 2020 Update 1.1: 17. srpna 2021

Azure DevOps Server 2020 Update 1.1 představuje opravy chyb. Azure DevOps Server 2020 Update 1.1 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 Update 1.1 asi tři týdny od této verze. 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, že se po nastavení zásad křížové repozity zobrazovala omezená dědičnost typů sloučení s omezenými typy sloučení.

Azure Pipelines

• Při změně nastavení aktualizace agenta se nastavení nešíření na jiné aplikační vrstvy v prostředí.

OBECNÉ

• Opravili jsme pravopis v průvodci konfigurací serveru.
• Zvýšená 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ů.

---

Datum vydání 2 opravy Azure DevOps Serveru 2020.1: 10. srpna 2021

Vydali jsme opravu pro Azure DevOps Server 2020.1, která řeší následující opravy.

• Oprava chyby uživatelského rozhraní definice sestavení
• Změna historie procházení tak, aby zobrazovala soubory místo kořenového úložiště.

Datum vydání 1 opravy Azure DevOps Serveru 2020.1: 15. června 2021

Vydali jsme opravu pro Azure DevOps Server 2020.1, která řeší následující opravy.

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

• Řešení potíží se sadou Notifications SDK Odběry oznámení, které používaly filtr Cesta k oblasti, se dříve neanalyšovaly správně.

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

Shrnutí novinek v Azure DevOps Serveru 2020.1 RTW

Azure DevOps Server 2020.1 RTW představuje opravy chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2020.1 RC2 dříve vydaném. Azure DevOps Server 2020.1 RTW představuje opravy chyb. Azure DevOps Server 2020.1 můžete nainstalovat přímo nebo upgradovat z Azure DevOps Serveru 2020, 2019 nebo Team Foundation Serveru 2015 nebo novějšího.

Poznámka:

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

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

Shrnutí novinek v Azure DevOps Serveru 2020.1 RC2

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

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

Shrnutí novinek v Azure DevOps Serveru 2020.1 RC1

Azure DevOps Server 2020.1 RC1 představuje 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 panelu.
• Vylepšené zabezpečení verzí na základě omezení rozsahu přístupových tokenů
• Vylepšené prostředí žádostí o přijetí změn
• Triggery s více úložišti v kanálech

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

• Panely
• Repos
• Pipelines
• Artefakty

---

Boards

Pravidla omezení přechodu stavu

Dál zavíráme paritu funkcí mezi hostovaným XML a zděděným procesem modelu. 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áděly z nabídky Nové na Vyřešeno. Místo toho musí přejít z nového –> aktivní –> vyřešeno

Můžete také vytvořit pravidlo, které omezí přechody stavu podle členství ve skupině. Například pouze uživatelé ve skupině Schvalovatelé můžou přesouvat uživatelské scénáře z nového –> schváleného.

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

Jednou z nejžádaných funkcí pro Azure Boards je možnost kopírovat pracovní položku, která také kopíruje podřízené pracovní položky. Do dialogového okna kopírovat pracovní položku 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ž doteď jsou pravidla pro aktivované uživatelem, aktivovaným datem, vyřešeným datem a vyřešeným datem záhadou. Jsou nastaveny pouze pro typy systémových pracovních položek a jsou specifické pro hodnotu stavu "Aktivní" a "Vyřešeno". Logiku jsme změnili tak, aby tato pravidla již 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 "Potřebuje testování", aktivují se pravidla Vyřešeno podle a Vyřešené datum .

Zákazníci tak můžou vytvářet vlastní hodnoty stavu a stále generovat pole Aktivované podle, Datum aktivace, Vyřešeno a Vyřešené datum , aniž by museli používat vlastní pravidla.

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

Účastníci byli vždy schopni 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 otevírat jednotlivé pracovní položky, po jednom a aktualizovat hodnotu stavu. To je pro zákazníky už dlouho bolest a s radostí oznamujeme, že teď můžete přesouvat pracovní položky napříč sloupci panelu.

Typ systémových pracovních položek pro backlogy a panely

Teď můžete přidat typ systémové pracovní položky na vybranou úroveň backlogu. V minulosti byly tyto typy pracovních položek k dispozici pouze z dotazů.

Zpracovat	Typ pracovní položky
Agilita	Problém
Scrum	Překážka
CMMI	Žádost o změnu
	Problém
	Přehled
	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 upravit. Pak přidejte typ pracovní položky.

Zvýšení limitu úložiště aplikací GitHubu v Azure Boards

Limit úložiště pro aplikaci Azure Boards na marketplace GitHubu se zvýšil z 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. Ostatní chtějí nastavit pracovní položky do jiného stavu, aby se před zavřením ověřily. 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 zkontrolujeme popis žádosti o přijetí změn a vyhledáme hodnotu stavu následovanou #mention pracovních položek. V tomto příkladu nastavujeme dva uživatelské scénáře na Vyřešeno a zavíráme dva úkoly.

Propojení pracovních položek k sestavením v jiném projektu

Teď můžete snadno sledovat závislosti sestavení napříč projektem pouhým propojením pracovní položky s sestavením, nalezeným v sestavení nebo integrovaným sestavením.

Úprava popisů (textů nápovědy) u systémových polí

Vždy jste mohli upravit popis vlastních polí. U systémových polí, jako je priorita, závažnost a aktivita, ale popis nelze upravit. Jedná se o mezeru mezi hostovaným kódem XML a zděděným souborem, který některým zákazníkům zabránil v migraci na zděděný model. Teď můžete upravit popis v systémových polích. 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 pro stejné pole u různých typů 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. Když vytvoříte nebo aktualizujete žádost o přijetí změn, můžete některé z nich zavřít, vyřešit některé z nich a ponechat zbytek otevřený. Teď můžete k tomu použít komentáře, jako jsou komentáře zobrazené na obrázku níže. Další podrobnosti najdete v dokumentaci.

Pole nadřazeného objektu na panelu úloh

Vzhledem k oblíbeným požadavkem teď můžete přidat pole Nadřazený do podřízených i nadřazených karet na panelu úkolů.

Odebrání pravidla Přiřazeno pro typ pracovní položky Chyby

Existuje několik skrytých systémových pravidel pro všechny různé typy pracovních položek v Agilních, Scrum a CMMI. Tato pravidla existovala již více než deset let a obecně fungovala dobře bez jakýchkoli stížností. Existuje však několik pravidel, která jim uvítají. Jedno pravidlo konkrétně způsobilo hodně bolesti pro nové a stávající zákazníky a rozhodli jsme se, že je čas ho odstranit. Toto pravidlo existuje u typu Pracovní položka chyby v procesu agilního procesu.

"Nastavte přiřazenou hodnotu Na Hodnotu Vytvořeno při změně stavu na Vyřešeno"

Obdrželi jsme spoustu vašich názorů na toto pravidlo. V reakci jsme toto pravidlo odebrali z typu Pracovní položka chyby v procesu Agilní. Tato změna ovlivní každý projekt pomocí zděděného agilního procesu nebo přizpůsobeného zděděného agilního procesu. Pro zákazníky, kteří se vám líbí a závisí na tomto aktuálním pravidlu, se podívejte na náš blogový příspěvek o krocích, které můžete provést k opětovnému přidání pravidla pomocí vlastních pravidel.

Odstraněné 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řazeny mimo jiné. Poskytuje několik přizpůsobených pivotů a filtrů. Jednou z hlavních stížností pro pivot "Přiřazeno ke mně" je, že zobrazuje Odebrané pracovní položky (to znamená pracovní položky ve stavu Odebráno). A souhlasíme! Odebrané položky jsou pracovní, které už nejsou hodnoty, a proto byly odebrány 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 ke 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 podporuje změnu výchozího názvu větve pro existující úložiště.

Další informace najdete v tématu Správa větví a změna výchozí větve.

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

Pro preferovaný počáteční název větve pro nová úložiště je teď k dispozici nastavení na úrovni kolekce. Pokud projekt nevybral počáteční název větve, použije se toto nastavení na úrovni organizace. Pokud jste v nastavení organizace nebo nastavení projektu nezadali počáteční název větve, budou nová úložiště používat výchozí nastavení Azure DevOps.

Přidání nového rozsahu ověřování pro přispívání poznámek PR

Tato verze přidá nový obor OAuth pro čtení a zápis komentářů k žádostem o přijetí změn. Pokud máte robota nebo automatizaci, která potřebuje pracovat jenom s komentáři, můžete mu poskytnout pat pouze 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 pomocí následujících možností:

• Zviditelnit volitelné kontroly

Zákazníci používají volitelné kontroly k upoutat pozornost vývojáře na potenciální problémy. V předchozím prostředí to bylo zřejmé, když tyto kontroly selžou. To ale není případ v prostředí preview. Velká zelená značka zaškrtnutí na požadovaných kontrolách maskuje chyby v volitelných kontrolách. Uživatelé můžou zjistit, že volitelné kontroly selhaly otevřením kontrolního panelu. Vývojáři to často nedělají, když se nezobrazí žádná indikace problému. V tomto nasazení jsme v souhrnu zviditelní stav volitelných kontrol.

• Stisknutou klávesou Ctrl se zobrazí položky nabídky.

Nabídky karet v žádosti o přijetí změn nepodporují stisknutí klávesy Ctrl. Uživatelé při kontrole žádosti o přijetí změn často 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ůže identifikovat nové soubory. Vzhledem k tomu, že poznámka byla za třemi tečky, nebyla často viditelná pro delší názvy souborů.

• Rozevírací seznam aktualizací žádostí o přijetí změn znovu získá informace o časování

Rozevírací seznam pro výběr možnosti aktualizovat a porovnat soubory v žádosti o přijetí změn ztratil důležitý prvek v prostředí náhledu. Při provedení této aktualizace se nezobrazit. 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 napravo, 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 potvrzení liší od jeho vlastního nadřazeného objektu. To je často potřeba, když chcete porozumět všem změnám ve vydané verzi. Do potvrzení jsme přidali kartu rodiče, která vám pomůže toho dosáhnout.

• Více místa pro složky a soubory s dlouhými názvy na kartě souborů PR

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

Obrázek nového stromu souborů:

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

• Předem daná pozice posuvníku při změně velikosti rozdílového panelu na kartě souborů PR

Při změně velikosti podokna rozdílu vedle sebe na kartě Soubory žádosti o přijetí změn by se ztratilo umístění posouvání uživatele. Tento problém byl opraven; Umístění posouvání uživatele je nyní zachováno ve změně velikosti rozdílového podokna.

• Hledá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 obtížné najít potvrzení hodnotou hash a otevřít ho. Tato oprava byla opravena.

• Vylepšené využití místa pro nové rozdílové mobilní zobrazení souborů PR

Tuto stránku jsme aktualizovali tak, aby lépe využívala místo, aby uživatelé viděli více souboru v mobilních zobrazeních místo toho, aby 40 % obrazovky zabírající záhlavím.

• Vylepšené obrázky v souhrnném zobrazení žádosti o přijetí změn

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

• Vylepšené možnosti větvení 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 porovnávané větve.

Pipelines

Další platforma agenta: ARM64

Do seznamu podporovaných platforem pro agenta Azure Pipelines jsme přidali Linux/ARM64. I když změny kódu byly minimální, muselo být nejprve dokončeno hodně zákulisí práce a s radostí oznamujeme jeho vydání!

Podpora filtrů značek pro prostředky kanálů

Do kanálů YAML jsme teď přidali značky. Pomocí značek můžete nastavit, aby se kanál CI spustil nebo kdy se má automaticky aktivovat.

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

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í) neaktivuje některý jiný zdroj nebo prostředek nebo naplánovaný trigger spuštění.

Pokud máte například naplánovanou sadu aktivačních událostí pro kanál CD, který chcete spustit jenom v případě, že vaše CI má produkční značku, značky v části aktivačních událostí zajistí, že se kanál CD aktivuje jenom v případě, že je splněna podmínka označování událostí dokončení CI.

Určení, které úlohy jsou v kanálech povolené

Úkoly z Marketplace teď můžete zakázat. Některá z vás můžou povolit rozšíření Marketplace, ale ne úlohy kanálů, které přinášejí. Pro ještě větší kontrolu vám také umožníme nezávisle zakázat všechny úkoly v poli (kromě rezervace, což je zvláštní akce). Pokud jsou obě tato nastavení povolená, jediné úlohy, které se dají spustit v kanálu, by se nahrály pomocí tfx. Pokud https://dev.azure.com/<your_org>/_settings/pipelinessettings chcete začít, navštivte část s názvem Omezení úkolů a vyhledejte ji.

Zásady výhradního uzamčení nasazení

Díky této aktualizaci můžete zajistit, aby se do prostředí současně nasadí jenom jedno spuštění. Výběrem kontroly "Exkluzivní zámek" v prostředí bude pokračovat pouze jedno spuštění. Další spuštění, která chcete 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 zprostředkující spuštění budou zrušena.

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

Přidali jsme podporu dílčích fází jako filtru pro prostředky kanálu v YAML. S tímto filtrem nemusíte čekat, až se dokončí celý kanál CI, aby se aktivoval kanál CD. Teď se můžete rozhodnout, že kanál CD aktivujete 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 triggerů v kanálu CI se pro váš kanál CD automaticky aktivuje nové spuštění.

Obecné triggery založené na webhoocích pro kanály YAML

Dnes máme různé prostředky (například kanály, kontejnery, sestavení a balíčky), prostřednictvím kterých 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 představujeme podporu triggeru webhooku 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 jakýchkoli externích událostí prostřednictvím svých webhooků (GitHub, GitHub Enterprise, Nexus, Aritfactory atd.) a aktivovat vaše kanály.

Tady je postup konfigurace triggerů webhooku:

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

   • Adresa URL požadavku – Kolekcehttps://dev.azure.com/<> ADO/ _apis/public/distributedtask/webhooks/<Název> webhooku?api-version=6.0-preview
   • Tajný kód – Toto je volitelné. Pokud potřebujete datovou část JSON zabezpečit, zadejte hodnotu Tajné .

2. Vytvořte nové připojení služby Příchozí webhook. 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 měl odpovídat webhooku vytvořenému 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ý kód – Tajný kód se používá k analýze hodnoty hash datové části použité 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 webhooks prostředku. Pokud se chcete přihlásit k odběru události webhooku, musíte v kanálu definovat prostředek webhooku a nasměrovat ho na připojení služby Příchozí webhook. Můžete také definovat další filtry pro prostředek webhooku na základě dat datové části JSON a dále přizpůsobit triggery 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, aktivuje se nové spuštění pro všechny kanály, které se přihlásí k odběru události webhooku.

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

Může to být matoucí, když se triggery kanálu nespustí podle očekávání. Abychom to lépe pochopili, přidali jsme novou položku nabídky na stránce definice kanálu s názvem Problémy s triggery, kde se zobrazí informace týkající se toho, proč se triggery nespouštějí.

Triggery prostředků se nedají spustit ze dvou důvodů.

1. Pokud je zdroj zadaného připojení služby neplatný nebo pokud trigger obsahuje nějaké chyby syntaxe, trigger se vůbec nenakonfiguruje. Zobrazují se jako chyby.

2. Pokud se podmínky triggeru neshodují, trigger se nespustí. Kdykoli k tomu dojde, zobrazí se upozornění, abyste pochopili, proč se podmínky neshodovaly.

   

Triggery více úložiště

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

• Nástroj nebo knihovnu využíváte z jiného úložiště. Testy aplikace chcete spouštět při každé aktualizaci nástroje nebo knihovny.
• Soubor YAML zůstane v samostatném úložišti od kódu aplikace. Kanál chcete aktivovat při každém odeslání aktualizace do úložiště aplikace.

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

Tady je příklad, který ukazuje, jak definovat více prostředků úložiště v kanálu a jak nakonfigurovat triggery na všech 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 existují nějaké aktualizace:

• 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é načítání protokolů agenta

Když agent přestane komunikovat se serverem Azure Pipelines, úloha, která byla spuštěná, se zruší. Pokud jste se dívali na protokoly konzoly streamování, možná jste získali nějaké povědomí o tom, co agent byl v pořádku, než přestal reagovat. Pokud jste ale ne, nebo pokud jste stránku aktualizovali, byly tyto protokoly konzoly pryč. Pokud v této verzi agent přestane reagovat, než odešle úplné protokoly, ponecháme protokoly konzoly jako další nejlepší věc. Protokoly konzoly jsou omezené na 1 000 znaků na řádek a můžou být někdy neúplné, ale jsou mnohem užitečnější než zobrazení nic! Zkoumání těchto protokolů vám může pomoct při řešení potíží s vlastními kanály a určitě pomůže našim technikům podpory při řešení potíží.

Možnost připojit svazky kontejnerů jen pro čtení

Při spuštění úlohy kontejneru ve službě Azure Pipelines se jako svazky mapuje několik svazků obsahujících pracovní prostor, úlohy a další materiály. Tyto svazky mají výchozí přístup pro čtení a zápis. Pokud chcete zvýšit zabezpečení, můžete svazky připojit jen pro čtení změnou specifikace kontejneru v YAML. Každý klíč v části mountReadOnly lze nastavit jen true pro čtení (výchozí hodnota je false).

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

Detailní kontrola nad spuštěním/zastavením kontejneru

Obecně doporučujeme, abyste službě Azure Pipelines umožnili spravovat životní cyklus kontejnerů úloh a služeb. V některých neobvyklých scénářích ale můžete chtít spustit a zastavit je sami. V této verzi jsme tuto funkci vytvořili do úlohy Dockeru.

Tady je ukázkový kanál s využitím nové funkce:

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ů do proměnné Agent.ContainerMappingkanálu . Můžete ho použít, pokud chcete například zkontrolovat seznam kontejnerů ve skriptu. Obsahuje řetězecifikovaný objekt JSON, který mapuje název prostředku (tvůrce z výše uvedeného příkladu) na ID kontejneru, které agent spravuje.

Rozbalení balíčků úloh pro jednotlivé kroky

Když agent spustí úlohu, nejprve stáhne všechny sady úloh vyžadované kroky úlohy. Za normálních okolností pro výkon rozbalí úkoly jednou za každou úlohu, i když je úkol použit v několika krocích. Pokud máte obavy o nedůvěryhodný kód, který mění rozbalený obsah, můžete trochu odměnit výkon tím, že agent rozbalí úlohu při každém použití. Pokud chcete tento režim povolit, předejte --alwaysextracttask při konfiguraci agenta.

Vylepšené zabezpečení verzí na základě omezení rozsahu přístupových tokenů

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

Každá úloha spuštěná ve verzích 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, stáhneme artefakty, nahrajeme protokoly, výsledky testů 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.

S touto aktualizací vycházíme z vylepšení zabezpečení kanálu omezením rozsahu přístupových tokenů a rozšířením stejného rozsahu na klasické verze.

Tato funkce bude ve výchozím nastavení zapnutá pro nové projekty a kolekce. U existujících kolekcí je nutné ji povolit v nastavení > kanálu kolekce. > > Omezte rozsah autorizace úlohy na aktuální projekt pro kanály verze. Další informace najdete zde.

Vylepšení rozhraní API pro YAML ve verzi Preview

Teď můžete zobrazit náhled kompletního YAML kanálu, aniž byste ho spustili. Kromě toho jsme vytvořili vyhrazenou novou 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řebírá stejné parametry jako řazení do fronty spuštění, ale už nevyžaduje oprávnění Sestavení fronty.

Okamžité spuštění úlohy

Už jste někdy měli chybu, kterou jste potřebovali nasadit právě v tuto chvíli , ale museli čekat za úlohami CI a PR? V této verzi vám teď umožníme převést prioritu úlohy zařazené do fronty. Uživatelé s oprávněním Spravovat ve fondu – obvykle správci fondu – uvidí na stránce s podrobnostmi úlohy nové tlačítko Spustit další. Kliknutím na tlačítko nastavíte, aby se úloha spustila co nejdříve. (Samozřejmě budete potřebovat dostupný paralelismus a vhodný agent.)

Výrazy šablony povolené v bloku YAML resources

Dříve nebyly v části souboru YAML služby Azure Pipelines povoleny resources výrazy v čase kompilace (${{ }}). V této verzi jsme toto omezení pro kontejnery zrušili. To vám umožní použít obsah parametrů modulu runtime ve vašich prostředcích, například k výběru kontejneru v době fronty. Plánujeme tuto podporu prodloužit na další prostředky v průběhu času.

Kontrola nad automatizovanými aktualizacemi úloh z Marketplace

Při psaní kanálu YAML obvykle zadáte pouze hlavní číslo verze zahrnutých úloh. Díky tomu mohou vaše kanály automaticky využívat nejnovější doplňky funkcí a opravy chyb. Někdy může být potřeba vrátit se k předchozí verzi úkolu a s touto aktualizací jsme pro vás přidali možnost, jak to udělat. V kanálech YAML teď můžete zadat úplnou verzi úlohy major.minor.patch.

Nedoporučujeme, abyste to dělali pravidelně a používali ho jenom jako dočasné alternativní řešení, když zjistíte, že novější úkol přeruší vaše kanály. Také se tím neinstaluje starší verze úlohy z Marketplace. Ve vaší kolekci už musí existovat, jinak váš 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 6 už není podporovaný, migrujeme úlohy pro práci s Uzlem 10. Pro tuto aktualizaci jsme migrovali téměř 50 % úkolů v boxu do uzlu 10. Agent teď může spouštět úlohy Node 6 i Node 10. V budoucí aktualizaci zcela odebereme Uzel 6 z agenta. Abychom se připravili na odebrání uzlu 6 z agenta, žádáme vás, abyste brzy aktualizovali vaše interní rozšíření a vlastní úlohy tak, aby také používaly Node 10. Pokud chcete pro svůj úkol použít Node 10, v části , v task.jsončásti execution, aktualizovat z Node na Node10.

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

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

Nová funkce exportu nahrazuje funkci Zobrazit jako YAML, která byla dříve nalezena 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 nesprávnému generování YAML. Nová funkce exportu bere v úvahu přesně způsob zpracování kanálu 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í rychlejší a modernější, ale tyto stránky také poskytují jediný vstupní bod pro všechny zásady od úrovně projektu až po úroveň větve.

Díky tomuto novému prostředí se navigace pro projekty s velkým počtem úložišť zjednodušila kvůli 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í, na které jsou zásady nastavené. Teď kliknutím na větev zobrazíte zásady, aniž byste opustili stránku nastavení úložiště.

Když se zásady zdědí z vyššího rozsahu, než s čím pracujete, ukážeme vám, odkud se zásady zdědily vedle jednotlivých zásad. Můžete také přejít na stránku, kde byly nastaveny zásady vyšší úrovně kliknutím na název oboru.

Samotná stránka zásad byla také upgradována na novou webovou platformu s 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 pro každou část filtry hledání.

Integrace správy změn ServiceNow s využitím kanálů YAML

Aplikace Azure Pipelines pro ServiceNow vám pomůže integrovat Službu Azure Pipelines a Správu změn ServiceNow. V této aktualizaci se snažíme, aby služba Azure Pipelines věděla o procesu správy změn spravovaných ve službě ServiceNow dále ke kanálům YAML.

Konfigurací kontroly Správy změn ServiceNow u prostředku teď můžete změnu pozastavit, než do daného prostředku nasadíte sestavení. 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 stavem nasazení, poznámkami atd.

Artifacts

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

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

Kanály s oborem organizace teď můžete vytvářet prostřednictvím uživatelského rozhraní tak, že přejdete na 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 informační kanály v rozsahu projektu v souladu se zbytkem nabídek Azure DevOps, můžete znovu vytvářet, spravovat a používat informační kanály omezené na kolekce prostřednictvím uživatelského rozhraní a různých rozhraní REST API. Další informace najdete v dokumentaci k informačním kanálům.

Dostupnost rozhraní REST API pro aktualizaci verze balíčků pro balíčky Mavenu

K aktualizaci verzí balíčků Maven teď můžete použít rozhraní REST API aktualizace balíčku Azure Artifacts. Dříve můžete pomocí rozhraní REST API aktualizovat verze balíčků pro NuGet, Maven, npm a univerzální balíčky, ale ne balíčky Maven.

Chcete-li aktualizovat balíčky Maven, 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	In	Povinní účastníci	Typ	Popis
artifactId	path	TRUE	string	ID artefaktu balíčku
feed	path	TRUE	string	Název nebo ID informačního kanálu
groupId	path	TRUE	string	ID skupiny balíčku
– kolekce	path	TRUE	string	Název kolekce Azure DevOps
version	path	TRUE	string	Verze balíčku
projekt	path		string	ID projektu nebo název projektu
verze-api	query	TRUE	string	Verze rozhraní API, která se má použít. Pokud chcete použít tuto verzi rozhraní API, 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 aktualizaci.

Názory

Rádi uslyšíme váš názor! 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.

---

Na začátek stránky