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

---

| | Developer Community Požadavky na systém a kompatibilita | Licenční podmínky | Pro Blog | DevOps Hodnotyhash SHA-256 |

---

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

Další informace o instalaci nebo upgradu nasazení Azure DevOps Server najdete v tématu Azure DevOps Server Požadavky.

Pokud si chcete stáhnout Azure DevOps Server produkty, navštivte stránku Azure DevOps Server soubory ke stažení.

Přímý upgrade na Azure DevOps Server 2022 se podporuje od Azure DevOps Server 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud je vaše nasazení TFS na TFS 2013 nebo starší, musíte před upgradem na Azure DevOps Server 2022 provést několik kroků. Další informace najdete na stránce Instalace .

---

Azure DevOps Server 2022 Update 0.1 Patch 5 Datum vydání: 14. listopadu 2023

Poznámka

Azure DevOps Server jsou kumulativní opravy. Pokud jste nenainstalovali opravu 3, zahrnuje tato oprava aktualizace agenta Azure Pipelines. Nová verze agenta po instalaci opravy Patch 5 bude 3.225.0.

File	Hodnota hash SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

• Rozšířili jsme seznam povolených znaků úloh PowerShellu pro povolení ověření parametrů argumentů úloh prostředí.
• Opravte problém, který způsoboval trvalé úpravy připojení služeb po kliknutí na tlačítko Zrušit.

Azure DevOps Server 2022 Update 0.1 Patch 4 Datum vydání: 10. října 2023

Poznámka

Azure DevOps Server jsou kumulativní opravy. Pokud jste nenainstalovali opravu 3, zahrnuje tato oprava aktualizace agenta Azure Pipelines. Nová verze agenta po instalaci opravy Patch 5 bude 3.225.0.

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

• Opravili jsme chybu, která způsobovala, že se kanály zablokovaly upgradem modelu spouštění kanálů.
• Opravili jsme chybu, kdy se identita vlastníka analýzy na počítačích s upgradem oprav zobrazovala jako neaktivní identita.
• Úloha vyčištění sestavení obsahuje mnoho úloh, z nichž každá odstraní artefakt sestavení. Pokud některá z těchto úloh selhala, nespěla žádná z následujících úloh. Toto chování jsme změnili tak, aby ignorovali selhání úloh a vyčistili tolik artefaktů, kolik můžeme.

datum vydání aktualizace Azure DevOps Server 2022 Update 0.1 Patch 3: 12. září 2023

Poznámka

Tato oprava zahrnuje aktualizace agenta Azure Pipelines. Nová verze agenta po instalaci opravy Patch 3 bude 3.225.0.

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

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

Azure DevOps Server 2022 Update 0.1 Patch 2 Datum vydání: 8. srpna 2023

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

• CVE-2023-36869: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• Opravili jsme chybu ve voláních SOAP, kdy bylo možné u velké odpovědi XML metadat volat AritmeticException.
• Implementovali jsme změny editoru připojení služeb, aby se stav koncového bodu vyprazdní při zavření komponenty.
• Byl vyřešen problém, kdy v souborech Markdownu nefungují relativní odkazy.
• Opravili jsme problém s výkonem související s tím, že spouštění aplikační vrstvy trvá déle než obvykle, když je definovaný velký počet značek.
• Byly vyřešeny TF400367 chyby na stránce Fondy agentů.
• Opravili jsme chybu, kdy se identita vlastníka analýzy zobrazovala jako neaktivní identita.
• Opravili jsme chybu nekonečné smyčky u CronScheduleJobExtension.

Azure DevOps Server 2022 Update 0.1 Patch 1 Datum vydání: 13. června 2023

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

• CVE-2023-21565: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• CVE-2023-21569: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• Opravili jsme chybu v editoru připojení služeb. Nyní se při zavření komponenty vyprázdní stav konceptu koncového bodu.
• Opravili jsme chybu, kdy odpojení nebo připojení kolekce selhalo a hlásilo následující chybu: "TF246018: Operace databáze překročila časový limit a byla zrušena.

datum vydání Azure DevOps Server 2022 Update 0.1: 9. května 2023

Azure DevOps Server 2022.0.1 je soubor oprav chyb. Obsahuje všechny opravy ve verzi Azure DevOps Server 2022.0.1 RC, která byla vydána dříve. Můžete nainstalovat přímo Azure DevOps Server 2022.0.1 nebo upgradovat z Azure DevOps Server 2022 nebo Team Foundation Serveru 2015 nebo novějšího.

datum vydání Azure DevOps Server 2022 Update 0.1 RC: 11. dubna 2023

Azure DevOps Server 2022.0.1 RC je soubor oprav chyb. Zahrnuje všechny opravy v dříve vydaných opravách Azure DevOps Server 2022. Můžete nainstalovat přímo Azure DevOps Server 2022.0.1 nebo upgradovat z Azure DevOps Server 2022 nebo Team Foundation Serveru 2015 nebo novějšího.

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

• Upgrade systému GVFS (Git Virtual File System) z verze 2.39.1.1-micorosoft.2 za účelem vyřešení chyby zabezpečení
• Testovací data nebyla odstraněna, což způsobilo zvětšení databáze. Touto opravou jsme aktualizovali uchovávání sestavení, aby se zabránilo vytváření nových osamocených testovacích dat.
• Aktualizace na AnalyticCleanupJob, stav úlohy byl Zastaveno a teď hlásíme Úspěch.
• Opravili jsme chybu příkazu "tfx extension publish" s chybou "Daný klíč nebyl přítomen ve slovníku".
• Implementovali jsme alternativní řešení a chybu při přístupu k rozšíření týmového kalendáře.
• CVE-2023-21564: Ohrožení zabezpečení z důvodu Azure DevOps Server skriptování mezi weby
• CVE-2023-21553: Azure DevOps Server ohrožení zabezpečení z důvodu možnosti vzdáleného spuštění kódu
• Aktualizace úloh MSBuild a VSBuild pro podporu sady Visual Studio 2022
• Aktualizujte metodiku načítání opětovného ověřování, aby se zabránilo vektoru útoku XSS.
• Azure DevOps Server 2022 Proxy hlásí následující chybu: VS800069: Tato služba je dostupná jenom v místním Azure DevOps.
• Opravili jsme problém s přístupností sad odložených odložených dat prostřednictvím webového uživatelského rozhraní.
• Byl vyřešen problém, který po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu Azure DevOps Server vyžadoval restartování služby tfsjobagent a Azure DevOps Server fondu aplikací.
• Oznámení pro pat se neodesílala sedm dní před datem vypršení platnosti.

Datum vydání aktualizace Patch 4 Azure DevOps Server 2022: 13. června 2023

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

• CVE-2023-21565: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• CVE-2023-21569: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.
• Opravili jsme chybu v editoru připojení služeb. Nyní se při zavření komponenty vyprázdní stav konceptu koncového bodu.
• Opravili jsme chybu, kdy odpojení nebo připojení kolekce selhalo a hlásilo následující chybu: "TF246018: Operace databáze překročila časový limit a byla zrušena.

Datum vydání Azure DevOps Server Patch 3 z roku 2022: 21. března 2023

Vydali jsme opravu (19.205.33506.1) pro Azure DevOps Server 2022, která obsahuje opravy pro následující:

• Byl vyřešen problém, který po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu Azure DevOps Server vyžadoval restartování služby tfsjobagent a Azure DevOps Server fondu aplikací.
• Místo předání odkazu zkopírujte stav koncového bodu na panel úprav koncového bodu služby.
• Při úpravách připojení služeb se dříve úpravy zachovaly v uživatelském rozhraní po výběru tlačítka Zrušit. Touto opravou jsme v sadě SDK pro oznámení opravili, že je doručování oznámení týmu nastavené na Nedoručovat. Pokud je v tomto scénáři u odběru oznámení nakonfigurovaná možnost Týmové doručování předvoleb , členové týmu oznámení nedostanou. Není potřeba dále rozšiřovat identity v rámci týmu, aby se zkontrolovaly preference členů.

datum vydání patche 2 Azure DevOps Server 2022: 14. února 2023

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

• CVE-2023-21564: Azure DevOps Server ohrožení zabezpečení spočívající ve skriptování mezi weby
• Aktualizace úloh MSBuild a VSBuild pro podporu sady Visual Studio 2022
• Aktualizujte metodiku načítání opětovného ověřování, aby se zabránilo možnému vektoru útoku XSS.
• Azure DevOps Server 2022 Proxy hlásí následující chybu: VS800069: Tato služba je dostupná jenom v místním Azure DevOps.

Azure DevOps Server 2022 Patch 1 Datum vydání: 24. ledna 2023

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

• Testovací data nebyla odstraněna, což způsobilo zvětšení databáze. Touto opravou jsme aktualizovali uchovávání sestavení, aby se zabránilo vytváření nových osamocených testovacích dat.
• Aktualizace na AnalyticCleanupJob, stav úlohy byl Zastaveno a teď hlásíme Úspěch.
• Opravili jsme chybu příkazu tfx extension publish s chybou "Daný klíč nebyl přítomen ve slovníku".
• Implementovali jsme alternativní řešení a chybu při přístupu k rozšíření týmového kalendáře.

Azure DevOps Server 2022 Datum vydání: 6. prosince 2022

Azure DevOps Server 2022 je sada oprav chyb. Obsahuje všechny funkce dříve vydaných Azure DevOps Server 2022 RC2 a RC1.

Azure DevOps Server 2022 RC2 Datum vydání: 25. října 2022

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

Poznámka

Nové algoritmy SSH RSA povolené

Kromě dříve podporovaného SSH-RSA byla vylepšena podpora veřejných klíčů RSA tak, aby podporovala typy veřejných klíčů SHA2.

Mezi podporované typy veřejných klíčů teď patří:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Požadovaná akce

Pokud jste implementovali práci pro povolení SSH-RSA explicitním zadáním v .ssh/config1 souboru, budete muset buď odebrat PubkeyAcceptedTypes, nebo ho upravit tak, aby používal buď RSA-SHA2-256, nebo RSA-SHA2-512, nebo obojí. Podrobnosti o tom, co dělat, pokud se stále zobrazí výzva k zadání hesla a GIT_SSH_COMMAND="ssh -v" git fetch nezobrazuje se žádný algoritmus vzájemného podpisu, najdete tady v dokumentaci.

Podpora eliptických klíčů ještě nebyla přidána a zůstává vysoce požadovanou funkcí v našem backlogu.

Azure DevOps Server 2022 RC1 Datum vydání: 9. srpna 2022

Shrnutí novinek v Azure DevOps Server 2022

Důležité

Služba Warehouse a Analysis Service byly vyřazeny v předchozí verzi Azure DevOps Server (2020). V Azure DevOps Server 2022 byly z produktu odebrány služby Warehouse a Analysis Service. Analýza teď poskytuje prostředí pro vytváření sestav v rámci produktu.

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

• Delivery Plans
• Zobrazení správných osob na odkazech pro potvrzení
• Nové ovládací prvky pro proměnné prostředí v kanálech
• Generování neomezeného tokenu pro sestavení forku
• Nové stránky TFVC
• Seskupovat značky dostupné ve widgetech grafů

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

• Boards
• Repos
• Pipelines
• Generování sestav

---

Boards

Delivery Plans

S radostí oznamujeme, že součástí Azure DevOps Server jsou nyní plány doručení. Delivery Plans nabízí 3 klíčové scénáře:

• Zobrazení časové osy plánu
• Průběh práce
• Sledování závislostí

Níže jsou uvedeny hlavní funkce. Součástí plánů doručení jsou také filtrování, značky a kritéria polí.

Existují dva hlavní pohledy: zhuštěné a rozšířené

Delivery Plans 2.0 umožňuje zobrazit všechny pracovní položky v plánu na časové ose pomocí počátečního a cílového data nebo data iterace. Pořadí priorit je začátek & cílových dat a pak následuje iterace. To vám umožní přidat pracovní položky na úrovni portfolia, jako je NapříkladEpic, které často nejsou definovány do iterace.

K dispozici jsou dva hlavní zobrazení zhuštěné zobrazení a rozšířené zobrazení. Plán můžete také přiblížit nebo oddálit kliknutím na lupu na druhé straně plánu.

K dispozici jsou dva hlavní zobrazení zhuštěné zobrazení a rozšířené zobrazení. Plán můžete také přiblížit nebo oddálit kliknutím na lupu na pravé straně plánu.

• Zhuštěné zobrazení

  Ve zhuštěném zobrazení jsou všechny karty pracovních položek sbalené , což znamená, že se nezobrazují všechny informace o kartě. Toto zobrazení je užitečné pro celkové zobrazení práce v plánu. Pokud chcete pole karet sbalit, klikněte na ikonu karty vedle ikon lupy na pravé straně plánu.

  Tady je příklad přecházení plánu mezi zhuštěným a rozšířeným zobrazením.

  

• Rozšířené zobrazení

  Rozbalené zobrazení zobrazuje průběh pracovní položky tak, že počítá počet podřízených a propojených položek a zobrazuje procento dokončení. V současné době je průběh určen počtem pracovních položek.

  Tady je příklad plánu pomocí rozšířeného zobrazení. Všimněte si indikátorů průběhu a procenta dokončení.

  

Sledování závislostí

Sledování závislostí je založené na odkazech předchůdců a následníků definovaných v pracovních položkách. Pokud tato propojení nejsou definovaná, nezobrazí se žádné čáry závislostí. Pokud dojde k problému se závislostí u pracovní položky, je ikona odkazu na závislost červeně zbarvená.

• Zobrazení závislostí

  Konkrétní závislosti jsou zobrazeny prostřednictvím panelu závislostí, který zobrazuje všechny závislosti pro danou pracovní položku, včetně směru. Červený vykřičník označuje problém se závislostí. Pokud chcete panel otevřít, stačí kliknout na ikonu odkazu na závislost v pravém horním rohu karty. Tady jsou příklady závislostí.

  

  

• Čáry závislostí

  Závislosti mezi pracovními položkami jsou vizualizovány pomocí směrových šipek mezi příslušnými pracovními položkami. Více závislostí se zobrazí jako více řádků. Červeně zbarvená čára značí problém.

  Tady je několik příkladů.

  

  Tady je příklad pracovní položky s více závislostmi, která funguje i pomocí zhuštěného zobrazení.

  

  Pokud dojde k problému, barva čáry je červená a ikona závislosti je také červená.

  Zde je příklad.

  

Stylování karet

Karty se teď dají stylovat pomocí pravidel, jako jsou panely Kanbanu. Otevřete nastavení plánu a klikněte na Styly. V podokně Styly klikněte na + Přidat pravidlo stylů , aby se pravidlo přidalo, a potom klikněte na Uložit. Může existovat až 10 pravidel a každé pravidlo může mít až 5 klauzulí.

• Před

• Po

Další informace o plánech doručení najdete v této dokumentaci.

Odebrané položky v centru Pracovních položek

Centrum Pracovních položek je místo, kde můžete zobrazit seznam položek, které jste vytvořili nebo které jsou vám přiřazeny. Poskytuje několik přizpůsobených funkcí kontingenční tabulky a filtrování, které zjednoduší výpis pracovních položek. Jednou z hlavních stížností kontingenčního panelu Přiřazeno ke mně je, že zobrazuje odebrané pracovní položky. Souhlasíme s tím, že odebrané pracovní položky už nemají hodnotu a neměly by být v backlogu. V tomto sprintu skryjeme všechny odebrané položky ze zobrazení Přiřazeno mně v centru Pracovních položek.

Zobrazení správných osob na odkazech pro potvrzení

Oddíl Vývoj v pracovní položce zobrazuje seznam relevantních potvrzení a žádostí o přijetí změn. Můžete zobrazit autora potvrzení nebo žádosti o přijetí změn společně s přidruženým časem. Touto aktualizací jsme opravili problém s nesprávným zobrazením avatara autora v zobrazení.

Odebrání možnosti stáhnout odstraněnou přílohu z historie pracovních položek

Opravili jsme malý problém, kdy uživatelé mohli stahovat přílohy z historie pracovních položek, a to i po odebrání přílohy z formuláře. Po odebrání přílohy se teď nedá stáhnout z historie ani z odpovědi rozhraní REST API nebude dostupná adresa URL pro stažení.

Přidání hodnoty "Will not Fix" do pole Důvod chyby

Stejně jako u všech ostatních typů pracovních položek má typ pracovní položky Chyba dobře definovaný pracovní postup. Každý pracovní postup se skládá ze tří nebo více stavů a důvodu. Důvody určují, proč se položka přechádila z jednoho státu do jiného. S touto aktualizací jsme přidali hodnotu Důvod se neopraví pro typy pracovních položek chyb v procesu agilního procesu. Hodnota bude k dispozici jako důvod při přesunu chyb z nové nebo aktivní na Vyřešeno. Další informace o tom, jak definovat, zachytit, třídit a spravovat softwarové chyby, najdete v Azure Boards dokumentaci.

Pipelines

Odebrání zásad uchovávání informací pro jednotlivé kanály v klasických buildech

V nastavení projektu Azure DevOps teď můžete nakonfigurovat zásady uchovávání informací pro klasické buildy i kanály YAML. Pravidla uchovávání jednotlivých kanálů pro kanály klasického sestavení se už nepodporují. I když je to jediný způsob, jak nakonfigurovat uchovávání pro kanály YAML, můžete také nakonfigurovat uchovávání pro klasické kanály buildu pro jednotlivé kanály. V nadcházející verzi jsme odebrali všechna pravidla uchovávání jednotlivých kanálů pro kanály buildu Classic.

Co to pro vás znamená: Všechny klasické kanály sestavení, které dříve měly pravidla uchovávání informací pro jednotlivé kanály, se budou řídit pravidly uchovávání na úrovni projektu.

Abychom zajistili, že při upgradu nepřijdete o žádná sestavení, vytvoříme zapůjčení všech buildů existujících v době upgradu, které nemají zapůjčení.

Po upgradu doporučujeme zkontrolovat nastavení uchovávání informací na úrovni projektu. Pokud váš kanál vyžaduje vlastní pravidla, můžete ve svém kanálu použít vlastní úlohu. Informace o přidávání zapůjčení uchovávání informací prostřednictvím úlohy najdete v dokumentaci k nastavení zásad uchovávání informací pro sestavení, vydané verze a testy.

Nové ovládací prvky pro proměnné prostředí v kanálech

Agent Azure Pipelines prohledá standardní výstup pro speciální příkazy protokolování a spustí je. PříkazsetVariable lze použít k nastavení proměnné nebo úpravě dříve definované proměnné. To může potenciálně zneužít aktér mimo systém. Pokud má váš kanál například krok, který vytiskne seznam souborů na serveru FTP, pak osoba s přístupem k serveru FTP může přidat nový soubor, jehož název obsahuje setVariable příkaz a způsobit, že kanál změní své chování.

Máme mnoho uživatelů, kteří spoléhají na nastavení proměnných pomocí příkazu protokolování ve svém kanálu. V této verzi provádíme následující změny, abychom snížili riziko nežádoucího setVariable použití příkazu.

• Přidali jsme nový konstruktor pro autory úkolů. Zahrnutím fragmentu kódu, jako je následující v task.jsonnástroji , může autor úkolu určit, jestli jsou jeho úkolem nastaveny nějaké proměnné.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Kromě toho aktualizujeme řadu předdefinovaných úloh, jako je SSH, aby je nebylo možné zneužít.

• Nakonec můžete pomocí konstruktorů YAML řídit, jestli může krok nastavit proměnné.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generování neomezeného tokenu pro sestavení forku

Uživatelé GitHubu Enterprise často používají forky k přispívání do upstreamového úložiště. Když Azure Pipelines vytváří příspěvky z forku úložiště GitHub Enterprise, omezuje oprávnění udělená přístupovým tokenům úloh a neumožňuje přístup k tajným kódům kanálu pro tyto úlohy. Další informace o zabezpečení stavebních forků najdete v naší dokumentaci.

To může být v takových uzavřených prostředích více omezující, než je žádoucí, a uživatelé můžou stále těžit z modelu spolupráce s vnitřním zdrojem. I když můžete nakonfigurovat nastavení v kanálu, aby byly tajné kódy dostupné pro forky, neexistuje žádné nastavení pro řízení oboru přístupového tokenu úlohy. V této verzi vám dáváme kontrolu nad generováním běžného přístupového tokenu úlohy i pro sestavení forků.

Toto nastavení můžete změnit v části Aktivační události v editoru kanálů. Před změnou tohoto nastavení se ujistěte, že plně rozumíte dopadům povolení této konfigurace na zabezpečení.

Úložiště jako chráněný prostředek v kanálech YAML

Projekt Azure DevOps můžete uspořádat tak, aby hostil mnoho dílčích projektů – každý z nich má vlastní úložiště Git Azure DevOps a jeden nebo více kanálů. V této struktuře můžete chtít určit, které kanály mají přístup ke kterým úložištím. Řekněme například, že máte dvě úložiště A a B ve stejném projektu a dva kanály X a Y, které tato úložiště obvykle vytvářejí. Můžete chtít zabránit kanálu Y v přístupu k úložišti A. Obecně chcete, aby přispěvatelé skupiny A ovládli, ke kterým kanálům chtějí poskytnout přístup.

I když to bylo částečně možné s úložišti a kanály Azure Git, neexistovalo žádné prostředí pro jeho správu. Tato funkce tuto mezeru řeší. Úložiště Azure Git je teď možné považovat za chráněné prostředky v kanálech YAML, stejně jako připojení služeb a fondy agentů.

Jako přispěvatel úložiště A můžete do úložiště přidat kontroly a oprávnění kanálu. Uděláte to tak, že přejdete do nastavení projektu, vyberete Úložiště a pak vaše úložiště. Všimněte si nové nabídky s názvem "Kontroly", kde můžete nakonfigurovat kteroukoli z kontrol v krabici nebo vlastní kontroly ve formě funkcí Azure.

Na kartě Zabezpečení můžete spravovat seznam kanálů, které mají přístup k úložišti.

Kdykoli kanál YAML používá úložiště, infrastruktura Azure Pipelines ověří a zajistí, že jsou splněné všechny kontroly a oprávnění.

Poznámka

Tato oprávnění a kontroly se vztahují pouze na kanály YAML. Klasické kanály tyto nové funkce nerozpoznávají.

Oprávnění a kontroly skupin proměnných a zabezpečených souborů

V kanálech YAML můžete použít různé typy sdílených prostředků . Mezi příklady patří připojení služeb, skupiny proměnných, zabezpečené soubory, fondy agentů, prostředí nebo úložiště. Aby byl kanál chráněn před přístupem k prostředku, může vlastník prostředku nakonfigurovat oprávnění a kontrolovat ho. Pokaždé, když se kanál pokusí o přístup k prostředku, vyhodnocují se všechna nakonfigurovaná oprávnění a kontroly. Tyto ochrany jsou nějakou dobu k dispozici pro připojení služeb, prostředí a fondy agentů. Nedávno se přidaly do úložišť. V této verzi přidáváme stejnou ochranu do skupin proměnných a zabezpečených souborů.

Pokud chcete omezit přístup ke skupině proměnných nebo zabezpečenému souboru na malou sadu kanálů, použijte funkci Oprávnění kanálů .

Pokud chcete nakonfigurovat kontroly nebo schválení, které by se měly vyhodnocovat při každém spuštění kanálu, použijte funkci Schválení a kontroly knihovny .

Změny v automatickém vytváření prostředí

Když vytvoříte kanál YAML a odkazujete na prostředí, které neexistuje, Azure Pipelines automaticky vytvoří prostředí. K tomuto automatickému vytvoření může dojít buď v kontextu uživatele, nebo v kontextu systému. V následujících tocích Azure Pipelines ví o uživateli, který operaci provádí:

• Ve webovém prostředí Azure Pipelines použijete průvodce vytvořením kanálu YAML a odkazujete na prostředí, které ještě není vytvořené.
• Soubor YAML aktualizujete pomocí webového editoru Azure Pipelines a po přidání odkazu na prostředí, které neexistuje, kanál uložíte. V každém z výše uvedených případů azure Pipelines jasně rozumí uživateli, který operaci provádí. Proto vytvoří prostředí a přidá uživatele do role správce prostředí. Tento uživatel má všechna oprávnění ke správě prostředí nebo k zahrnutí dalších uživatelů do různých rolí pro správu prostředí.

V následujících tocích Azure Pipelines nemá informace o uživateli, který prostředí vytváří: aktualizujete soubor YAML pomocí jiného externího editoru kódu, přidáte odkaz na prostředí, které neexistuje, a pak způsobíte aktivaci kanálu kontinuální integrace. V takovém případě Azure Pipelines o uživateli neví. Dříve jsme tento případ řešili přidáním všech přispěvatelů projektu do role správce prostředí. Každý člen projektu pak mohl tato oprávnění změnit a zabránit ostatním v přístupu k prostředí.

Dostali jsme vaši zpětnou vazbu k udělení oprávnění správce prostředí všem členům projektu. Když jsme naslouchali vaší zpětné vazbě, dozvěděli jsme se, že bychom neměli automaticky vytvářet prostředí, pokud není jasné, kdo uživatel operaci provádí. V této verzi jsme provedli změny automatického vytváření prostředí:

• Spuštění kanálu v budoucnu automaticky nevytvoří prostředí, pokud neexistuje a pokud není známý kontext uživatele. V takových případech kanál selže s chybou Prostředí nenalezena. Před použitím v kanálu musíte předem vytvořit prostředí se správným zabezpečením a zkontrolujte konfiguraci.
• Kanály se známým uživatelským kontextem budou stále automaticky vytvářet prostředí stejně jako v minulosti.
• Nakonec je potřeba poznamenat, že funkce automatického vytvoření prostředí byla přidána pouze kvůli zjednodušení procesu zahájení práce s Azure Pipelines. Byl určen pro testovací scénáře, a ne pro produkční scénáře. Vždy byste měli předem vytvořit produkční prostředí se správnými oprávněními a kontrolami a pak je používat v kanálech.

Dialogové okno Odebrat přehledy z kanálu sestavení

Na základě vaší zpětné vazby se odebralo dialogové okno Přehledy úkolu nebo kanálu, které se zobrazí při procházení kanálu sestavení, aby se pracovní postup zlepšil. Analýzy kanálů jsou stále k dispozici, abyste měli přehledy, které potřebujete.

Podpora sekvenčních nasazení místo nejnovějších pouze při použití výhradních kontrol uzamčení

V kanálech YAML se kontroly používají k řízení provádění fází na chráněných prostředcích. Jednou z běžných kontrol, které můžete použít, je kontrola výhradního uzamčení. Tato kontrola umožňuje pokračovat pouze jedním spuštěním z kanálu. Když se více spuštění pokusí nasadit do prostředí najednou, kontrola zruší všechna stará spuštění a povolí nasazení nejnovějšího spuštění.

Zrušení starých spuštění je dobrý přístup, pokud jsou vaše vydané verze kumulativní a obsahují všechny změny kódu z předchozích spuštění. Existují však některé kanály, ve kterých nejsou změny kódu kumulativní. S touto novou funkcí můžete povolit, aby všechna spuštění pokračovala a nasadí se postupně do prostředí, nebo zachovat předchozí chování zrušení starých spuštění a povolení pouze nejnovějších. Toto chování můžete zadat pomocí nové vlastnosti s názvem lockBehavior v souboru YAML kanálu. Hodnota znamená sequential , že všechna spuštění získávají zámek chráněného prostředku postupně. Hodnota runLatest znamená, že zámek prostředku získá pouze nejnovější spuštění.

Pokud chcete použít kontrolu výhradního zámku u sequential nasazení nebo runLatest, postupujte takto:

1. Povolte kontrolu výhradního zámku v prostředí (nebo jiném chráněném prostředku).
2. V souboru YAML pro kanál zadejte novou vlastnost s názvem lockBehavior. To je možné zadat pro celý kanál nebo pro danou fázi:

Nastavení na ploše:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Nastavte v kanálu:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Pokud nezadáte lockBehavior, předpokládá se runLatest, že je .

Podpora pro quebecovou verzi ServiceNow

Azure Pipelines má existující integraci s ServiceNow. Integrace spoléhá na aplikaci v ServiceNow a rozšíření v Azure DevOps. Teď jsme aplikaci aktualizovali tak, aby fungovala s verzí ServiceNow v Quebecu. Kanály Classic i YAML teď fungují s Quebecem. Pokud chcete zajistit, aby tato integrace fungovala, upgradujte na novou verzi aplikace (4.188.0) z úložiště Service Now (Služba). Další informace najdete v tématu Integrace se službou ServiceNow Change Management.

Nové podmíněné výrazy YAML

Psaní podmíněných výrazů v souborech YAML je díky použití výrazů ${{ else }} a ${{ elseif }} jednodušší. Níže najdete příklady použití těchto výrazů v souborech kanálů YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Podpora zástupných znaků ve filtrech cest

Zástupné znaky se dají použít při zadávání větví zahrnutí a vyloučení pro triggery CI nebo PR v souboru YAML kanálu. Nelze je však použít při zadávání filtrů cest. Nemůžete například zahrnout všechny cesty, které odpovídají src/app/**/myapp*. To bylo označeno jako nepříjemnosti několika zákazníky. Tato aktualizace tuto mezeru vyplní. Teď můžete při zadávání filtrů cest používat zástupné znaky (**, *nebo ?).

Výchozí specifikace agenta pro kanály bude Windows-2022.

Image windows-2022 je připravená jako výchozí verze pro popisek v agentech hostovaných Microsoftem windows-latest v Azure Pipelines. Až dosud tento popisek odkazoval na agenty windows-2019. Tato změna bude zaváděná po dobu několika týdnů od 17. ledna. Migraci plánujeme dokončit do března.

Azure Pipelines se podporuje windows-2022 od září 2021. Monitorovali jsme vaši zpětnou vazbu, abychom zlepšili stabilitu obrázku windows-2022 , a teď jsme připraveni ji nastavit jako nejnovější.

Obrázek windows-2022 obsahuje Visual Studio 2022. Úplný seznam rozdílů mezi windows-2022 a windows-2019najdete v tématu o problému GitHubu. Úplný seznam softwaru nainstalovaného v imagi najdete tady.

Přejmenování složky kanálu ověřuje oprávnění

Složky obsahující kanály je možné přejmenovat. Přejmenování složky bude nyní úspěšné pouze v případě, že má uživatel oprávnění k úpravám alespoň u jednoho kanálu obsaženého ve složce.

Plánování upgradu modulu runtime agenta pipelines

Co je agent kanálu?

Agent kanálu Azure DevOps je softwarový produkt, který běží na hostiteli kanálu ke spouštění úloh kanálu. Běží na agentech hostovaných Microsoftem, agentech škálovací sady a agentech v místním prostředí. V druhém případě ho nainstalujete sami. Agent kanálu se skládá z naslouchacího procesu a pracovního procesu (implementovaného v .NET). Pracovní proces spouští úlohy, které jsou implementované buď v uzlu, nebo v PowerShellu, a proto tyto moduly runtime hostují pro ně.

Nadcházející upgrade na .NET 6 & vyřazení Red Hatu 6

S vydáním .NET 6 jsme schopni využívat nové multiplatformní funkce. Konkrétně budeme schopni poskytnout nativní kompatibilitu pro Apple Silicon a Windows Arm64. Proto plánujeme v nadcházejících měsících přejít na .NET 6 pro agenta kanálu (naslouchací proces a pracovní proces).

Vzhledem k řadě omezení, která to ukládá, vyřazujeme podporu Red Hat Enterprise Linuxu 6 z našeho agenta 30. dubna 2022.

Aktualizace do úlohy Kopírování souborů Azure

Zavádíme novou verzi úlohy Kopírování souborů Azure. Tato úloha se používá ke kopírování souborů do objektů blob úložiště Microsoft Azure nebo virtuálních počítačů. Nová verze obsahuje několik aktualizací, o které komunita často žádá:

• Verze nástroje AzCopy byla aktualizována na 10.12.2, která podporuje typy obsahu souborů. V důsledku toho se při kopírování SOUBORŮ PDF, Excelu, PPT nebo některého z podporovaných typů mime správně nastaví typ obsahu souboru.

• V nové verzi AzCopy můžete také nakonfigurovat nastavení pro vyčištění cíle, pokud je cílovým typem Azure Blob. Nastavením této možnosti odstraníte všechny složky nebo soubory v tomto kontejneru. Nebo pokud je k dispozici předpona objektu blob, odstraní se všechny složky nebo soubory v této předponě.

• Nová verze úlohy spoléhá na moduly Az, které jsou nainstalované v agentovi, a ne na moduly AzureRM. V některých případech se tak při použití úlohy odebere zbytečné upozornění.

Změny jsou součástí aktualizace hlavní verze pro tuto úlohu. Abyste mohli používat novou verzi, museli byste kanály explicitně aktualizovat. Rozhodli jsme se aktualizovat hlavní verzi, abychom zajistili, že nenarušíme žádné kanály, které jsou stále závislé na modulech AzureRM.

Nové body rozšíření pro zobrazení podrobností o kanálech

Přidali jsme dva nové body rozšiřitelnosti, na které můžete v rozšířeních cílit. Tyto body rozšiřitelnosti umožňují přidat vlastní tlačítko do záhlaví kanálu a vlastní nabídku do složky kanálu:

• Vlastní tlačítko v záhlaví kanálu: ms.vss-build-web.pipelines-header-menu
• Vlastní nabídka ve složce kanálu: ms.vss-build-web.pipelines-folder-menu

Pokud chcete tyto nové body rozšiřitelnosti použít, jednoduše přidejte nový příspěvek, který je cílí do souboru manifestu vss-extension.json rozšíření Azure DevOps.

Příklad:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Výsledek bude:

• Vlastní tlačítko v záhlaví kanálu

  

• Vlastní nabídka ve složce kanálu

  

Vylepšená migrace na Azure DevOps Services

Při spouštění importu z Azure DevOps Server do Azure DevOps Services je potřeba vzít v úvahu, že Azure DevOps už nepodporuje pravidla uchovávání informací pro jednotlivé kanály. Díky této aktualizaci jsme tyto zásady odebrali při migraci z místního Azure DevOps Server na Azure DevOps Services. Další informace o konfiguraci zásad uchovávání informací najdete v naší dokumentaci k nastavení zásad uchovávání informací pro sestavení, vydané verze a testy.

Vylepšení rozhraní REST API pro spouštění kanálů

Rozhraní REST API Pipelines Runs dříve vrátilo self jenom úložiště. V této aktualizaci rozhraní REST API Pro spouštění kanálů vrátí všechny prostředky úložiště sestavení.

Šablonám rozšířených kanálů YAML je teď možné předávat kontextové informace pro fáze, úlohy a nasazení.

S touto aktualizací přidáváme novou templateContext vlastnost pro jobkomponenty kanálu , deploymenta stage YAML, které se mají používat ve spojení se šablonami.

Tady je scénář pro použití templateContext:

• Šablony používáte ke snížení duplicit kódu nebo ke zlepšení zabezpečení kanálů.

• Šablona přebírá jako parametr seznam stages, jobsnebo deployments

• Šablona zpracuje vstupní seznam a provede některé transformace v jednotlivých fázích, úlohách nebo nasazeních. Například nastaví prostředí, ve kterém se jednotlivé úlohy spouští, nebo přidá další kroky k vynucení dodržování předpisů.

• Zpracování vyžaduje, aby autor kanálu předal do šablony pro každou fázi, úlohu nebo nasazení v seznamu další informace.

Podívejme se na příklad. Řekněme, že vytváříte kanál, který spouští kompletní testy pro ověření žádostí o přijetí změn. Vaším cílem je otestovat jenom jednu komponentu systému, ale protože plánujete spouštět kompletní testy, potřebujete prostředí, ve kterém je k dispozici více součástí systému a budete muset určit jejich chování.

Uvědomíte si, že jiné týmy budou mít podobné potřeby, takže se rozhodnete extrahovat kroky pro nastavení prostředí do šablony. Jeho kód vypadá takto:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Šablona pro každou úlohu v parametru testSet nastavuje odpověď komponent systému určených parametrem ${{ testJob.templateContext.requiredComponents }} tak, aby vrátila ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Pak můžete vytvořit vlastní kanál, který se testing-template.yml rozšíří jako v následujícím příkladu.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Tento kanál spustí dva testy, jeden pozitivní a jeden negativní. Oba testy vyžadují, aby byla komponenta dimensionsapi dostupná. Úloha positive_test očekává návratový dimensionsapi kód HTTP 200, zatímco negative_test očekává, že vrátí kód HTTP 500.

Podpora skupinových účtů spravované služby jako účtu služby agenta

Agent Azure Pipelines teď podporuje účty spravované služby skupiny u agentů v místním prostředí ve Windows.

Skupinové účty spravované služby poskytují centralizovanou správu hesel pro doménové účty, které fungují jako účty služeb. Agent Azure Pipelines dokáže rozpoznat tento typ účtu, takže se při konfiguraci nevyžaduje heslo:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Informační spuštění

Při informačním spuštění se azure DevOps nepodařilo načíst zdrojový kód kanálu YAML. Takové spuštění vypadá takto.

Azure DevOps načte zdrojový kód kanálu YAML v reakci na externí události, například na nabízené potvrzení, nebo v reakci na interní triggery, například za účelem kontroly, jestli nedošlo ke změnám kódu, a spuštění naplánovaného spuštění. Když tento krok selže, systém vytvoří informační spuštění. Tato spuštění se vytvoří jenom v případě, že je kód kanálu v úložišti GitHub nebo BitBucket.

Načtení kódu YAML kanálu může selhat z následujících důvodů:

• U poskytovatele úložiště dochází k výpadku
• Omezování požadavků
• Authentication issues
• Nelze načíst obsah souboru .yml kanálu

Přečtěte si další informace o informačních spuštěních.

Vlastnost rozhraní REST API retentionRules definice sestavení je zastaralá.

V typu retentionRules odpovědi rozhraní REST APIBuildDefinition definice sestavení je vlastnost označená jako zastaralá, protože tato vlastnost vždy vrací prázdnou sadu.

Repos

Nové stránky TFVC

Aktualizovali jsme různé stránky v Azure DevOps tak, aby používaly novou webovou platformu s cílem zajistit konzistentnější a přístupnější prostředí napříč různými službami. Stránky TFVC byly aktualizovány tak, aby používaly novou webovou platformu. V této verzi zpřístupňujeme nové stránky TFVC obecně.

Zakázání úložiště

Zákazníci často žádali o způsob, jak zakázat úložiště a zabránit uživatelům v přístupu k jeho obsahu. To můžete chtít udělat například v těchto případech:

• V úložišti jste našli tajný kód.
• Skenovací nástroj třetí strany zjistil, že úložiště nedodržuje předpisy.

V takových případech můžete během práce na vyřešení problému dočasně zakázat úložiště. S touto aktualizací můžete úložiště zakázat, pokud máte oprávnění k odstranění úložiště . Zakázáním úložiště:

• Může uvést úložiště v seznamu úložišť.
• Nelze přečíst obsah úložiště.
• Nelze aktualizovat obsah úložiště.
• Při pokusu o přístup k úložišti v uživatelském rozhraní Azure Repos se zobrazí zpráva, že se úložiště zakázalo.

Po provedení nezbytných kroků pro zmírnění rizik můžou uživatelé s oprávněním Odstranit úložiště úložiště znovu povolit. Pokud chcete úložiště zakázat nebo povolit, přejděte na Nastavení projektu, vyberte Úložiště a pak konkrétní úložiště.

Nakonfigurujte tvůrce větví tak, aby ve svých větvích nezískaly oprávnění ke správě.

Když vytvoříte novou větev, získáte pro tuto větev oprávnění ke správě. Toto oprávnění umožňuje změnit oprávnění jiných uživatelů nebo povolit dalším uživatelům přispívat do této větve. Tvůrce větve může například toto oprávnění použít k tomu, aby jinému externímu uživateli umožnil provádět změny kódu. Nebo můžou kanálu (identitě služby sestavení) povolit změnu kódu v této větvi. V některých projektech s vyššími požadavky na dodržování předpisů by uživatelé neměli mít možnost provádět takové změny.

Díky této aktualizaci můžete nakonfigurovat všechna úložiště v týmovém projektu a zabránit tvůrcům větví, aby získali oprávnění Ke správě oprávnění. Uděláte to tak, že přejdete do nastavení projektu, vyberete Úložiště a pak Nastavení pro všechna úložiště nebo konkrétní úložiště.

Toto nastavení je ve výchozím nastavení zapnuté, aby napodoboval stávající chování. Pokud ale chcete tuto novou funkci zabezpečení využít, můžete ji vypnout.

Zabránění uživatelům forku v hlasování o upstreamových žádostech

S Azure Repos můžou uživatelé s oprávněním ke čtení v úložišti vytvořit fork úložiště a provádět změny ve svém forku. Aby mohli uživatelé odeslat žádost o přijetí změn se svými změnami do upstreamu, potřebují oprávnění "přispívat k žádostem o přijetí změn" na upstreamu. Toto oprávnění ale také určuje, kdo může hlasovat o žádostech o přijetí změn v nadřazeném úložišti. V důsledku toho se můžete dostat do situací, kdy uživatel, který není přispěvatelem úložiště, může odeslat žádost o přijetí změn a způsobit, že se tato žádost sloučí v závislosti na tom, jak nastavíte zásady větve.

V projektech, které propagují model vnitřního zdroje, je běžným vzorem fork-and-contribute. Abychom tento model dále zabezpečili a propagovali, měníme oprávnění hlasovat pro žádost o přijetí změn z přispívání k žádostem o přijetí změn na přispívání. Tato změna se ale ve výchozím nastavení neprovází ve všech projektech. Pokud chcete toto oprávnění přepnout, musíte se přihlásit a vybrat v úložišti novou zásadu s názvem Režim striktního hlasování. Doporučujeme, abyste to udělali, pokud se spoléháte na forky v Azure Repos.

Generování sestav

Seskupovat značky dostupné ve widgetech grafů

Widget grafu Seskupit podle značek je teď ve výchozím nastavení dostupný pro všechny zákazníky. Při použití widgetu grafu je teď k dispozici možnost pro značky. Uživatelé můžou vizualizovat své informace tak, že ve widgetu vyberou všechny značky nebo sadu značek.

Zobrazení vlastních typů pracovních položek ve widgetu burndown

Dříve se vám nepodařilo zobrazit vlastní typy pracovních položek nakonfigurované ve widgetu burn down a sečtené nebo spočítané podle vlastního pole. Touto aktualizací jsme tento problém vyřešili a teď můžete ve widgetu burndown zobrazit vlastní typy pracovních položek.

---

Zpětná vazba

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

---

Začátek stránky