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

Komunita vývojářů | Systémové požadavky | Licenční podmínky | DevOps Blog | SHA-1 Hashy

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í běhu kanálu (sestavení), který funguje na nastavení na úrovni projektu.

Azure DevOps Server 2020 zpracovává zachování sestavení odlišně na základě zásad zachování na úrovni pipeline. Některé konfigurace zásad vedou k odstranění spuštění kanálu po upgradu. Spuštění kanálu, které bylo ručně zachováno nebo je zachováno nasazením, se po upgradu neodstraní.

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í Azure DevOps Server 2020, verze 1.2, oprava 15: 11. března 2025

Soubor	SHA-256 hash
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

Vydali jsme Patch 15 pro Azure DevOps Server 2020 Update 1.2, aby zahrnoval následující:

• Aktualizace úkolů kvůli zrušení Edgio CDN. Další podrobnosti najdete v blogovém příspěvku Přepnutí poskytovatelů CDN.

Datum vydání aktualizace 1.2 Záplata 14 pro Azure DevOps Server 2020: 12. listopadu 2024

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

Vydali jsme Aktualizaci 14 pro Azure DevOps Server 2020 Update 1.2, která zahrnuje aktualizaci ohrožené závislosti.

Azure DevOps Server 2020, aktualizace 1.2 opravný balíček 13, datum vydání: 12. března 2024

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

Vydali jsme záplatu 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	SHA-256 hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

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

• 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	SHA-256 hash
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í aktualizace 1.2 Patch 10 serveru Azure DevOps 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ů pro úlohy PowerShellu při ověřování parametrů argumentů v rámci povolení úloh.

Instalace oprav

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

• 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

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

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.  

Konfigurace TFX

1. Postupujte podle kroků v dokumentaci k nahrání úkolů do kolekce projektů pro instalaci a přihlášení 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.

• Na klasice:

  Definujte proměnnou na kartě proměnných v procesu.

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Datum vydání opravy 7 pro 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 modulu 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žadováno členem skupiny" v nastavení webhooku.
• Opravit chybu při gated check-in sestavení, když nastavení organizace pro pipeline mělo konfiguraci rozsahu autorizace úlohy omezenou na aktuální projekt pro nerelease pipelines.
• 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.

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

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

  • Vytvořte pronájmy pro 3 nejnovější vygenerované buildy během provozu 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 pronájmy se nezapočítávají do minimální hodnoty pro udržení 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ářů nevedl na správné místo v zobrazení souborů.

• Frontu stavby nelze přeskočit pomocí tlačítka Pokračovat dál. Dříve bylo tlačítko "Spustit další" povoleno pouze pro správce kolekcí projektů.

• Po zakázání účtu uživatele ve službě Active Directory zrušte všechny osobní přístupové tokeny.

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

Vydali jsme opravný balíček pro Azure DevOps Server 2020.1.1, který obsahuje opravy následujících problémů.

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

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ý na C:\Program Files\{TFS Version Folder}\Search\zip do vzdálené složky Elasticsearch.
4. Spusťte Configure-TFSSearch.ps1 -Operation update na počítači serveru Elasticsearch.

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

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 podmínkou "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ýsledkových údají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í:

• Vyřešit selhání při 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.

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 zobrazení zaškrtávacích políček pro omezené typy dědičnosti slučování, aby bylo možné upravit omezené typy slučování po nastavení zásad pro křížové repozitáře.

Azure Pipelines

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

Obecné

• Opravili jsme pravopis v průvodci konfigurací serveru.
• Zvýšení velikosti balíčku rozšíření a možnost změnit tuto 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í problémy.

• Oprava chyby v uživatelském 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í problémy.

• Zabezpečené soubory cookie používané v autorizačních tocích, které uplatňují 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 je souhrn oprav chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2020.1 RC2 dříve vydaném. Azure DevOps Server 2020.1 RTW je kumulativní aktualizace oprav 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.

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á zkušenost s pull requesty
• 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:

• Desky
• Repos
• Pipelines
• Artefakty

---

Desky

Pravidla pro omezení přechodů stavů

Pokračujeme v uzavírání mezery v paritě funkcí mezi hostovaným XML a zděděným procesním modelem. 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é mohou přesouvat uživatelské příběhy z Nového do Schváleného.

Zkopírujte pracovní položku a zkopírujte podřízené položky

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. Přidali jsme novou možnost "Zahrnout podřízené pracovní položky" do dialogového okna pro kopírování 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ď byla pravidla pro aktivováno kým, datum aktivace, vyřešeno kým a datum vyřešení 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 kým 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.

Zainteresované osoby můžou přesouvat pracovní položky přes sloupce tabule.

Úč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 už dlouho byl pro zákazníky problém a s radostí oznamujeme, že teď můžete přesouvat pracovní položky napříč sloupcích na desce.

Typy systémových pracovních položek pro backlogy a nástěnky

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

Proces	Typ pracovní položky
Agilní	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 záložku Úrovně backlogu. Vyberte požadovanou úroveň backlogu (příklad: Backlog požadavků) a zvolte možnost úprav. 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í Pull Requestu uzavří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 pull requestu a vyhledáme hodnotu stavu, po níž následuje označení pracovních položek pomocí #. 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í pull requestu.

Pull requesty často odkazují na více pracovních úkolů. Když vytvoříte nebo aktualizujete žádost o přijetí změn, můžete některé z nich zavřít, některé vyřešit a zbytek ponechat 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 Hlášení o chybě

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á už nejsou vítána. 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žky Chyba v agilním procesu.

Nastavte přiřazenou hodnotu na "Vytvořeno kým" 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žky Chyba v agilním procesu. 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ří mají toto aktuální pravidlo rádi a spoléhají se na něj, 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 nastavení 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í na funkci "Přiřazeno ke mně" je, že zobrazuje odebrané pracovní položky (tzn. pracovní položky ve stavu Odebráno). A souhlasíme! Odebrané položky jsou práce, která už nemá hodnotu, a proto byly odebrány ze zásobníku, a proto jejich 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ává nový obor OAuth pro čtení a zápis komentářů k pull requestům. Pokud máte robota nebo automatizaci, která potřebuje pracovat jenom s komentáři, můžete mu přidělit Personal Access Token (PAT) pouze s tímto rozsahem. 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í:

• Zviditelnit volitelné kontroly

Zákazníci používají volitelné kontroly k upozornění vývojáře na možné 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 rámci tohoto nasazení jsme v souhrnu zviditelnili stav volitelných kontrol.

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

Nabídky karet v PR nepodporovaly kliknutí při držení 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í nabídka aktualizací PR znovu získá časové informace

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. Nebylo vidět, kdy byla tato aktualizace provedena. 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 rodičovský commit a dále pochopit, jak se tento commit liší od svého vlastního rodiče. To je často potřeba, když chcete porozumět všem změnám ve vydané verzi. K commitu jsme přidali kartu rodiče/rodičů, 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ů. Získali jsme více místa ve stromové struktuře úpravou jejího odsazení tak, aby odpovídalo kořenovému uzlu, a skrytím tlačítka se třemi tečkami na stránce, pokud nad ním myší nepřejedete.

Obrázek nového stromu souborů:

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

• Zachovat pozici 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; pozice posouvání uživatele je nyní zachována po 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 commit podle jeho hashe a otevřít ho. Nyní je opraveno.

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

Tuto stránku jsme aktualizovali pro lepší využití prostoru, aby uživatelé viděli více souboru v mobilních zobrazeních místo toho, aby záhlaví zabíralo 40 % obrazovky.

• Vylepšené obrázky v souhrnném zobrazení PR

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á zkušenost s větvením při vytváření nové žádosti o změny

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.

Potrubí

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ěkteří z vás mohou povolit rozšíření Marketplace, ale ne úkoly v rámci Pipeline, které přinášejí. Pro ještě větší kontrolu vám také umožníme nezávisle zakázat všechny přednastavené úkoly (kromě pokladny, což je zvláštní akce). Pokud jsou obě tato nastavení povolená, jediné úlohy, které by se mohly spustit v kanálu, jsou ty nahrané pomocí tfx. Navštivte https://dev.azure.com/<your_org>/_settings/pipelinessettings a najděte sekci s názvem "Omezení úkolů", abyste mohli začít.

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

Díky této aktualizaci můžete zajistit, aby se do prostředí současně nasazoval pouze jeden běh. Výběrem volby "Exkluzivní zámek" v prostředí dojde pouze k jednomu spuštění. Další nasazení do daného prostředí budou pozastavena. Po dokončení spuštění s exkluzivním zámkem proběhne nejnovější spuštění. Všechna zprostředkující spuštění budou zrušena.

Filtry fází pro triggery zdrojů 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 spouštěčů v potrubí CI se pro vaše potrubí CD automaticky spustí nový běh.

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, Artifactory atd.) a spouštět své pipeline.

Tady je postup konfigurace triggerů webhooku:

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

   • Adresa URL požadavku - "https://dev.azure.com/<ADO kolekce>/_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 prostředku webhooks. Pokud se chcete přihlásit k odběru události webhooku, musíte v pipelinu definovat zdroj 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 se spouštěčem zdrojů YAML – podpora a sledovatelnost

Může to být matoucí, když se spouštěče 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 pipelinu s názvem Problémy s triggery, kde se zobrazují informace týkající se toho, proč se triggery nespouštějí.

Spouštěče 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 nejsou splněny podmínky spouštěče, spouštěč se nespustí. Kdykoli k tomu dojde, zobrazí se upozornění, abyste pochopili, proč se podmínky neshodovaly.

   

Spouštěče více úložišť

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. Chcete aktivovat procesní řetězec při každém pushnutí aktualizace do úložiště aplikace.

S touto aktualizací budou triggery pro více repozitářů 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 repozitářů v pipeline 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

Datový tok v tomto příkladu se aktivuje, pokud dojde k jakýmkoli aktualizacím:

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

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 logy streamovací konzole, možná jste získali nějaké indicie o tom, co agent dělal, než přestal reagovat. Pokud jste ale nebyli přítomni, nebo pokud jste stránku aktualizovali, tyto protokoly konzoly zmizely. Pokud v této verzi agent přestane reagovat, než odešle úplné protokoly, ponecháme protokoly konzoly jako další nejlepší věc. Logy konzoly jsou omezené na 1 000 znaků na řádek a mohou být někdy neúplné, ale jsou mnohem užitečnější než nezobrazit 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 je namapováno 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. S tímto vydáním jsme tuto funkci integrovali do úlohy Dockeru.

Tady je příklad pipeline s využitím nové funkčnosti:

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 serializovaný objekt JSON, který mapuje název prostředku (sestavovač z výše uvedeného příkladu) na ID kontejneru, který spravuje agent.

Rozbalení balíčků úkolů 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, že nedůvěryhodný kód mění rozbalený obsah, můžete obětovat kousek výkonu 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í zlepšujeme zabezpečení nasazovací pipeline omezením rozsahu platnosti přístupových tokenů a rozšířením tohoto opatření 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í kolekce > Kanály > Nastavení. > Omezte rozsah autorizace úlohy na aktuální projekt pro uvolňovací kanály. 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. Nyní můžete odeslat POST na https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview a získat 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.

Spusťte tuto úlohu příště

Už jste někdy měli opravu chyby, kterou jste potřebovali nasadit právě v tuto chvíli, ale museli čekat kvůli úlohám kontinuální integrace (CI) a pull requestů (PR)? S touto aktualizací vám nyní umožňujeme zvýšit 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 jsou povoleny v bloku YAML resources

Dříve nebyly výrazy v čase kompilace (${{ }}) povoleny v části resources souboru YAML služby Azure Pipelines. 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 jej jenom jako dočasné alternativní řešení, když zjistíte, že novější úkol přeruší vaše pipeline. 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ím aktualizaci zcela odebereme Node 6 z agenta. Abychom se připravili na odebrání Node 6 z agenta, žádáme vás, abyste brzy aktualizovali svá interní rozšíření a vlastní úlohy tak, aby také používaly Node 10. Pokud chcete pro svůj úkol použít Node 10, přejděte do task.json v execution a aktualizujte z Node na Node10.

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

V této verzi zavádíme novou funkci „export do YAML“ pro návrhářské build pipeline. 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 přesně zohledňuje, jak bude kanál zpracováván, a generuje YAML, který plně odpovídá návrhu kanálu.

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 napříč úložišti.

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ž jsou zásady zděděny z vyššího rozsahu, než se kterým pracujete, ukážeme vám, odkud byly zděděny, vedle každé jednotlivé zásady. 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 pokračujeme v naší cestě k tomu, aby si Azure Pipelines uvědomily proces řízení změn, které jsou spravovány v ServiceNow, a zahrnuli je i do kanálů YAML.

Nastavením kontroly Správy změn ServiceNow u prostředku nyní můžete pozastavit proces, dokud nebude změna schválena, než nasadíte 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 stavem nasazení, poznámkami atd.

Artefakty

Možnost vytvářet kanály zaměřené na organizaci z uživatelského rozhraní

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

Kanály v rámci organizace můžete nyní vytvářet pomocí uživatelského rozhraní tím, že přejdete na Artefakty –> Vytvořit informační kanál a zvolíte typ kanálu v rámci rozsahu.

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é	Typ	Popis
artifactId	cesta	Pravda	řetězec	ID artefaktu balíčku
kanál	cesta	PRAVDA	řetězec	Název nebo ID informačního kanálu
identifikátor skupiny	cesta	PRAVDA	řetězec	ID skupiny balíčku
kolekce	cesta	PRAVDA	string	Název kolekce Azure DevOps
verze	cesta	TRUE	řetězec	Verze balíčku
projekt	cesta		řetězec	ID projektu nebo název projektu
verze-api	dotaz	Pravda	řetězec	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 bude přidána 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