Zpráva k vydání verze Pro Azure DevOps Server 2022

---

| Požadavky komunity | vývojářů na systém a licenční podmínky | kompatibility | DevOps Blog | SHA-256 hash |

---

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 chcete stáhnout produkty Azure DevOps Serveru, přejděte na stránku pro stahování Azure DevOps Serveru.

Přímý upgrade na Azure DevOps Server 2022 se podporuje z Azure DevOps Serveru 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 dočasných kroků. Další informace najdete na stránce Instalace.

---

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

Poznámka:

Opravy Azure DevOps Serveru jsou kumulativní, pokud jste neinstalovali opravu Patch 3, zahrnuje tato oprava aktualizace agenta Azure Pipelines. Nová verze agenta po instalaci patch 5 bude 3.225.0.

Soubor	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 ověření parametrů argumentů Povolit úlohy prostředí.
• Opravte problém, který způsoboval trvalé úpravy připojení služeb po kliknutí na tlačítko Zrušit.

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

Poznámka:

Opravy Azure DevOps Serveru jsou kumulativní, pokud jste neinstalovali opravu Patch 3, zahrnuje tato oprava aktualizace agenta Azure Pipelines. Nová verze agenta po instalaci 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 zablokování kanálů upgradem modelu spouštění kanálů.
• Opravili jsme chybu, která způsobovala, že identita vlastníka analýzy se na počítačích s upgradem oprav zobrazovala jako neaktivní identita.
• Úloha vyčištění sestavení obsahuje mnoho úkolů, z nichž každý odstraní artefakt sestavení. Pokud některý z těchto úkolů selhal, žádný z následujících úkolů nespadl. Toto chování jsme změnili tak, aby ignoroval selhání úloh a vyčistil 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 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: 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

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

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

• CVE-2023-36869: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• Opravili jsme chybu ve voláních PROTOKOLU SOAP, která způsobovala vyvolání AritmeticException pro odpověď XML s velkými metadaty.
• Implementovali jsme změny editoru připojení služby, aby se stav koncového bodu vyprazdňuje při zavření komponenty.
• Vyřešili jsme problém s nefunkčními relativními odkazy v souborech Markdownu.
• Opravili jsme problém s výkonem související s aplikační vrstvou, který trval déle než normálně, když bylo definováno velké množství značek.
• Vyřešené TF400367 chyby na stránce Fondy agentů.
• Opravili jsme chybu, kdy se identita vlastníka analýzy zobrazovala jako neaktivní identita.
• Oprava chyby nekonečné smyčky u CronScheduleJobExtension.

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

Vydali jsme opravu pro Azure DevOps Server 2022 Update 0.1, 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 v editoru připojení služeb. Nyní se stav konceptu koncového bodu vyprázdní při zavření komponenty.
• 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í azure DevOps Serveru 2022 Update 0.1: 9. května 2023

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

Datum vydání azure DevOps Serveru 2022 Update 0.1 RC: 11. dubna 2023

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

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

• Upgradovali jsme systém GVFS (Git Virtual File System) z verze 2.39.1.1-micorosoft.2, který řeší ohrožení zabezpečení.
• 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.
• Aktualizace AnalyticCleanupJob, stav úlohy byl zastaven a nyní hlásíme úspěch.
• Oprava příkazu tfx extension publish selhává s chybou Zadaný klíč nebyl ve slovníku k dispozici.
• Implementovali jsme alternativní řešení pro řešení a chybu při přístupu k rozšíření Týmový kalendář.
• CVE-2023-21564: Ohrožení zabezpečení skriptování mezi weby Azure DevOps Serveru
• CVE-2023-21553: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu serveru Azure DevOps
• Aktualizace úloh NÁSTROJE MSBuild a VSBuild pro podporu sady Visual Studio 2022
• Aktualizujte metodu načítání opětovného ověření, aby se zabránilo vektoru útoku XSS.
• Proxy server Azure DevOps 2022 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 adres prostřednictvím webového uživatelského rozhraní.
• Vyřešili jsme problém, který vyžadoval restartování služby tfsjobagent a fondu aplikací Azure DevOps Serveru po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu serveru Azure DevOps.
• Oznámení se neposílala po dobu 7 dnů před datem vypršení platnosti pat.

Datum vydání 4 opravy Azure DevOps Serveru 2022: 13. června 2023

Vydali jsme opravu pro Azure DevOps Server 2022, 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 v editoru připojení služeb. Nyní se stav konceptu koncového bodu vyprázdní při zavření komponenty.
• 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í 3 opravy Azure DevOps Serveru 2022: 21. března 2023

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

• Vyřešili jsme problém, který vyžadoval restartování služby tfsjobagent a fondu aplikací Azure DevOps Serveru po aktualizaci nastavení souvisejícího s protokolem SMTP v konzole pro správu serveru Azure DevOps.
• Místo předání odkazu zkopírujte stav koncového bodu do panelu úprav koncového bodu služby.
• Při úpravách připojení služby se úpravy dříve zachovaly v uživatelském rozhraní po výběru tlačítka zrušit. S touto opravou jsme opravili sadu SDK pro oznámení, pokud má tým nastavené doručování oznámení na hodnotu Nedoručovat. Pokud je v tomto scénáři nakonfigurované odběr oznámení s možností doručování předvoleb týmu, členové týmu oznámení oznámení nedostanou. Není nutné rozšiřovat identity pod týmem, aby se zkontrolovaly předvolby členů.

Datum vydání 2 opravy Azure DevOps Serveru 2022: 14. února 2023

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

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

Datum vydání 1 opravy Azure DevOps Serveru 2022: 24. ledna 2023

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

• 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.
• Aktualizace AnalyticCleanupJob, stav úlohy byl zastaven a nyní hlásíme úspěch.
• Oprava příkazu tfx extension publish selhává s chybou Zadaný klíč nebyl ve slovníku k dispozici.
• Implementovali jsme alternativní řešení pro řešení a chybu při přístupu k rozšíření Týmový kalendář.

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

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

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

Azure DevOps Server 2022 RC2 je součástí oprav chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2022 RC1, které byly vydány dříve.

Poznámka:

Nové povolené algoritmy RSA SSH

Podpora veřejného klíče RSA byla vylepšena tak, aby podporovala typy veřejných klíčů SHA2 kromě sha1 SSH-RSA, které jsme dříve podporovali.

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

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

Požadovaná akce

Pokud jste implementovali alternativní řešení, abyste povolili SSH-RSA tím, že ho explicitně zadáte do .ssh/config1 souboru, budete ho muset buď odebrat PubkeyAcceptedTypes, nebo ho upravit tak, aby používal RSA-SHA2-256, nebo RSA-SHA2-512, nebo obojí. Podrobnosti o tom, co dělat, když se stále zobrazí výzva k zadání hesla a GIT_SSH_COMMAND="ssh -v" git fetch v dokumentaci se nezobrazí žádný algoritmus vzájemného podpisu.

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

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

Shrnutí novinek v Azure DevOps Serveru 2022

Důležité

Služba Warehouse a Analysis Service byla v předchozí verzi Azure DevOps Serveru (2020) zastaralá. V Azure DevOps Serveru 2022 se z produktu odebrala služba Warehouse and Analysis Service. Analýzy teď poskytují prostředí pro generování sestav v rámci produktu.

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

• Plány doručení
• Zobrazení správných osob na odkazech 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
• Seskupení podle značek dostupných ve widgetech grafů

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

• Panely
• Repos
• Pipelines
• Sestavy

---

Boards

Delivery Plans

S radostí oznamujeme, že služba Delivery Plans je teď součástí Azure DevOps Serveru. Plány doručení poskytují 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. Filtrování, značky a kritéria polí jsou také součástí plánů doručení.

Existují dvě hlavní zobrazení: zhuštěné a rozšířené

Plány doručení 2.0 umožňují zobrazit všechny pracovní položky v plánu na časové ose pomocí počátečních a cílových dat nebo iteračních dat. Pořadí priorit je počáteční a cílové datum a potom následuje iterace. Díky tomu můžete přidat pracovní položky na úrovni portfolia, jako je NapříkladEpic, které se často nedefinují do iterace.

Existují dvě hlavní zobrazení , zhuštěné zobrazení a rozšířené zobrazení. Můžete také přiblížit a oddálit plán kliknutím na lupu v ruce na straně plánu.

Existují dvě hlavní zobrazení , zhuštěné zobrazení a rozšířené zobrazení. Můžete také přiblížit a oddálit plán kliknutím na lupu v pravé části plánu.

• Zhuštěné zobrazení

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

  Tady je příklad přepnutí plánu mezi zhuštěnými a rozbalenými zobrazeními.

  

• Rozbalené zobrazení

  Rozbalené zobrazení zobrazuje průběh pracovní položky počítáním počtu podřízených a propojených položek a zobrazením procenta dokončení. Průběh je v současné době určen počtem pracovních položek.

  Tady je příklad plánu s použitím rozšířeného zobrazení. Poznamenejte si indikátory průběhu a procento dokončení.

  

Sledování závislostí

Sledování závislostí je založeno na odkazech předchůdců a následníků, které jsou definovány v pracovních položkách. Pokud tyto odkazy nejsou definovány, nezobrazí se žádné čáry závislostí. Pokud dojde k problému se závislostí s pracovní položkou, ikona propojení závislostí je barevná červeně.

• 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 závislostí. Pokud chcete otevřít panel, jednoduše klikněte 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á barevná čára značí problém.

  Zde je uvedeno několik příkladů.

  

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

  

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

  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ů přidat pravidlo a potom klepněte na tlačítko 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.

Odebrání položek v centru Pracovních položek

Centrum pracovních položek je místo pro zobrazení seznamu položek, které jste vytvořili nebo které jsou vám přiřazeny. Poskytuje několik přizpůsobených kontingenčních a filtrovaných funkcí pro zjednodušení výpisu pracovních položek. Jednou z hlavních stížností kontingenčního panelu Přiřazeno je , že zobrazuje odebrané pracovní položky. Souhlasíme s tím, že odebrané pracovní položky už nejsou hodnotné 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 potvrzení

Část 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 spolu s přidruženým časem. V této aktualizaci jsme opravili problém s nesprávným zobrazením avatara autora.

Odebrání možnosti stažení odstraněné přílohy z historie pracovních položek

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

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 chyby 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č položka přešla z jednoho státu na jiný. V této aktualizaci jsme přidali hodnotu důvodu neopravy typů pracovních položek chyby v procesu Agilního procesu. Hodnota bude k dispozici jako důvod při přesouvání chyb z nové nebo aktivní na Vyřešeno. Další informace o definování, zachycení, třídění a správě chyb softwaru najdete v dokumentaci k Azure Boards.

Pipelines

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

Zásady uchovávání informací teď můžete nakonfigurovat pro klasické buildy i kanály YAML v nastavení projektu Azure DevOps. Pravidla uchovávání jednotlivých kanálů pro klasické kanály buildu 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 sestavení na základě jednotlivých kanálů. V nadcházející verzi jsme odebrali všechna pravidla uchovávání jednotlivých kanálů pro kanály buildu Classic.

To znamená pro vás: jakýkoli klasický kanál buildu, který se používá k tomu, aby měl pravidla uchovávání informací pro jednotlivé kanály, se řídí pravidly uchovávání na úrovni projektu.

Abychom zajistili, že při upgradu nepřijdete o žádné buildy, vytvoříme zapůjčení pro všechna sestavení existující 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 konkrétně vyžaduje vlastní pravidla, můžete v 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říkaz setVariable 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á například váš kanál krok, který vypíše seznam souborů na serveru FTP, může osoba s přístupem k serveru FTP přidat nový soubor, jehož název obsahuje setVariable příkaz a způsobit, že kanál změní jeho 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 například následující, task.jsonmůže autor úkolu řídit, jestli jsou podle jejich úkolu 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 běžně používají forky k přispívání do upstreamového úložiště. Když Azure Pipelines sestaví příspěvky z forku úložiště GitHub Enterprise, omezí oprávnění udělená tokenu přístupu k úloze a neumožňuje přístup k tajným kódům kanálu těmito úlohami. Další informace o zabezpečení forků budov 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í, protože uživatelé můžou stále těžit z modelu pro spolupráci vnitřního zdroje. Nastavení v kanálu sice můžete nakonfigurovat tak, aby zpřístupnily tajné kódy forkům, ale 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 z triggerů v editoru kanálů. Před změnou tohoto nastavení se ujistěte, že plně rozumíte dopadům na zabezpečení při povolování této konfigurace.

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

Projekt Azure DevOps můžete uspořádat tak, aby hostovala mnoho dílčích projektů – každý s vlastním úložištěm Git Azure DevOps a jedním nebo více kanály. V této struktuře můžete chtít řídit, které kanály mají přístup k úložištím. Řekněme například, že máte ve stejném projektu dvě úložiště A a B a dva kanály X a Y, které normálně sestavují tato úložiště. Možná budete chtít zabránit tomu, aby kanál Y přistupoval k úložišti A. Obecně chcete, aby přispěvatelé A mohli řídit, ke kterým kanálům chtějí poskytnout přístup.

I když to bylo možné s úložišti a kanály Azure Git částečně, nemělo to zkušenosti se správou. Tato funkce tuto mezeru řeší. Úložiště Azure Git se teď dají 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 oprávnění kontroly a kanálu. Uděláte to tak, že přejdete do nastavení projektu, vyberete Úložiště a pak úložiště. Všimněte si nové nabídky s názvem "Kontroly", kde můžete nakonfigurovat libovolnou z možností v poli nebo vlastních kontrol ve formě azure functions.

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 všechny kontroly a oprávnění splněné.

Poznámka:

Tato oprávnění a kontroly platí jenom pro 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ě. Pokud chcete kanál chránit před přístupem k prostředku, může vlastník prostředku nakonfigurovat oprávnění a kontrolovat tento prostředek. Pokaždé, když se kanál pokusí o přístup k prostředku, vyhodnotí se všechna nakonfigurovaná oprávnění a kontroly. Tyto ochrany jsou k dispozici na připojeních služeb, prostředích a fondech agentů už nějakou dobu. Nedávno byly přidány do úložišť. V této verzi přidáváme stejné ochrany 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í Pipelines.

Ke konfiguraci kontrol nebo schválení, která by se měla vyhodnotit při každém spuštění kanálu, použijte funkci Schválení a kontroly funkce Knihovna .

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 v kontextu uživatele nebo v kontextu systému. V následujících tocích služba Azure Pipelines ví o uživateli, který provádí operaci:

• Průvodce vytvořením kanálu YAML použijete ve webovém prostředí Azure Pipelines a odkazujete na prostředí, které ještě nebylo vytvořeno.
• 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ů služba Azure Pipelines jasně rozumí uživateli, který operaci provádí. Proto vytvoří prostředí a přidá uživatele do role správce pro dané 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ý vytváří prostředí: aktualizujete soubor YAML pomocí jiného externího editoru kódu, přidáte odkaz na prostředí, které neexistuje, a pak způsobí 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í.

Obdrželi jsme vaši zpětnou vazbu ohledně udělení oprávnění správce prostředí všem členům projektu. Jak jsme slyšeli vaši zpětnou vazbu, slyšeli jsme, že bychom neměli automaticky vytvářet prostředí, pokud není jasné, kdo je uživatel provádějící operaci. V této verzi jsme provedli změny automatického vytváření prostředí:

• V budoucnu nebudou spuštění kanálu automaticky vytvářet prostředí, pokud neexistuje, a pokud kontext uživatele není známý. V takových případech kanál selže s chybou Prostředí nenalezena. Před použitím v kanálu je potřeba předem vytvořit prostředí se správným zabezpečením a zkontrolovat konfiguraci.
• Kanály se známým kontextem uživatele budou stále automaticky vytvářet prostředí stejně jako v minulosti.
• Nakonec je třeba poznamenat, že funkce pro automatické vytvoření prostředí byla přidána pouze kvůli zjednodušení procesu zahájení práce se službou Azure Pipelines. Byl určen pro testovací scénáře, nikoli 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 buildu

Na základě vaší zpětné vazby se dialogové okno Přehledy úkolů nebo kanálu, které se zobrazí při navigaci v kanálu buildu, bylo odebráno za účelem zlepšení pracovního postupu. Analýza kanálu je stále dostupná, abyste měli přehledy, které potřebujete.

Podpora sekvenčních nasazení místo nejnovějších pouze při použití exkluzivních kontrol zámků

V kanálech YAML se kontroly používají k řízení provádění fází u chráněných prostředků. Jednou z běžných kontrol, které můžete použít, je exkluzivní kontrola zámku. Tato kontrola umožňuje pokračovat pouze jedním spuštěním z kanálu. Když se několik spuštění pokusí nasadit do prostředí současně, 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ým přístupem, když jsou 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í. Pomocí této nové funkce můžete povolit všem spuštěním pokračovat a nasadit postupně do prostředí, nebo zachovat předchozí chování zrušení starých spuštění a povolit pouze nejnovější. Toto chování můžete zadat pomocí nové vlastnosti volané lockBehavior v souboru YAML kanálu. Hodnota sequential znamená, že všechna spuštění získávají zámek postupně k chráněnému prostředku. 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 s nasazeními sequential , postupujte runLatesttakto:

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í ve fázi:

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

Nastavte kanál:

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

Pokud nezadáte , lockBehaviorpředpokládá se, že runLatestje .

Podpora pro québecovou verzi ServiceNow

Azure Pipelines má existující integraci s ServiceNow. Integrace spoléhá na aplikaci v ServiceNow a rozšíření v Azure DevOps. Aktualizovali jsme aplikaci tak, aby fungovala s verzí ServiceNow v Quebecu. Klasické kanály i kanály YAML teď fungují s Québecem. Pokud chcete zajistit, aby tato integrace fungovala, upgradujte na novou verzi aplikace (4.188.0) z úložiště Service Now. Další informace najdete v tématu Integrace se správou změn ServiceNow.

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

Psaní podmíněných výrazů v souborech YAML je teď jednodušší s použitím ${{ else }} výrazů a ${{ elseif }} výrazů. Níže jsou uvedeny 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 lze 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. Například nelze zahrnout všechny cesty, které odpovídají src/app/**/myapp*. Na to upozornilo několik zákazníků jako nepříjemnosti. Tato aktualizace tuto mezeru vyplní. Při zadávání filtrů cest teď můžete použít zástupné znaky (**, *nebo ?).

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

Image windows-2022 je připravená být výchozí verzí popisku windows-latest v agentech hostovaných Microsoftem v Azure Pipelines. Dosud tento popisek odkazoval na agenty windows-2019. Tato změna bude vydána během několika týdnů od 17. ledna. Migraci plánujeme dokončit do března.

Azure Pipelines se od září 2021 podporuje windows-2022 . Monitorovali jsme vaši zpětnou vazbu, abychom zlepšili windows-2022 stabilitu obrázků 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 problémem na GitHubu a windows-2019seznamte se s ním. Úplný seznam softwaru nainstalovaných na imagi najdete tady.

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

Složky obsahující kanály lze přejmenovat. Přejmenování složky bude nyní úspěšné pouze v případě, že uživatel má oprávnění k úpravám alespoň 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 pro 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 rozhraní .NET), spouští úlohy, které jsou implementovány buď v uzlu nebo PowerShellu, a proto tyto moduly runtime hostují za ně.

Nadcházející upgrade na vyřazení .NET 6 a Red Hat 6

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

Vzhledem k řadě omezení, která to znamená, jsme od našeho agenta 30. dubna 2022 rušili podporu Red Hat Enterprise Linuxu 6.

Aktualizace ú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 má několik aktualizací, které často požadovala komunita:

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

• Pomocí nové verze AzCopy můžete také nakonfigurovat nastavení pro vyčištění cíle, pokud je cílovým typem objektu blob Azure. Nastavením této možnosti odstraníte všechny složky a 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 nainstalované v agentovi místo modulů AzureRM. V některých případech se při použití úkolu odebere zbytečné upozornění.

Změny jsou součástí aktualizace hlavní verze pro tuto úlohu. Kanály byste museli explicitně aktualizovat tak, aby používaly novou verzi. Tuto volbu jsme zvolili při aktualizaci hlavní verze, abychom zajistili, že nerušíme žádné kanály, které jsou stále závislé na modulech AzureRM.

Nové body rozšíření pro zobrazení podrobností pipelines

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

• Vlastní tlačítko v hlavičce 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í na soubor manifestu vss-extension.jsonrozšíř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ýsledkem bude:

• Vlastní tlačítko v hlavičce kanálu

  

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

  

Vylepšená migrace do Azure DevOps Services

Při spouštění importu z Azure DevOps Serveru do Azure DevOps Services musíte zvážit, že Azure DevOps už nepodporuje pravidla uchovávání jednotlivých kanálů. Při této aktualizaci jsme tyto zásady odebrali při migraci na Azure DevOps Services z místního Serveru Azure DevOps. 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 spuštění kanálů

Dříve kanály spouští rozhraní REST API, které vrátilo pouze self úložiště. V této aktualizaci vrátí rozhraní REST API Služby Pipelines všechny prostředky úložiště sestavení.

Rozšířené šablony kanálů YAML teď můžou být předány kontextové informace pro fáze, úlohy a nasazení.

V této aktualizaci přidáváme novou templateContext vlastnost pro joba deploymentstage komponenty kanálu YAML určené pro použití ve spojení se šablonami.

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

• Pomocí šablon omezíte duplikaci kódu nebo zlepšíte zabezpečení kanálů.

• Vaše šablona přebírá jako parametr seznam stages, jobsnebo deployments

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

• Zpracování vyžaduje předání dalších informací autorem kanálu do šablony pro každou fázi, úlohu nebo nasazení v seznamu.

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 pouze 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 potřebujete určit jejich chování.

Uvědomujete si, že ostatní 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 }}

To, co šablona dělá, pro každou úlohu v parametru testSet nastaví odpověď komponent systému určených ${{ testJob.templateContext.requiredComponents }} tak, aby vrátila ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Pak můžete vytvořit vlastní kanál, který se testing-template.yml rozšíří podobně 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 spouští dva testy, kladné a záporné. Oba testy vyžadují, aby byla komponenta dimensionsapi k dispozici. Ú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 skupinové účty spravovaných služeb na agentech v místním prostředí ve Windows.

Skupinové účty spravované služby poskytují centralizovanou správu hesel pro účty domény, které fungují jako účty služeb. Agent Azure Pipelines dokáže tento typ účtu rozpoznat, takže během konfigurace se 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í běhy

Informační spuštění sděluje, že se službě 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 nasdílené 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í nebo ne. Pokud 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ů:

• Poskytovatel úložiště, u kterých 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.

Zastaralá vlastnost rozhraní REST API retentionRules definice sestavení

V typu retentionRules odpovědi rozhraní REST APIBuildDefinition definice sestavení je vlastnost nyní označena 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 požadovali způsob, jak zakázat úložiště a zabránit uživatelům v přístupu k jeho obsahu. Můžete to například udělat v těchto případech:

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

V takových případech můžete chtít dočasně zakázat úložiště, zatímco pracujete na vyřešení problému. Při této aktualizaci 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 vypsat úložiště v seznamu úložišť.
• Obsah úložiště nelze přečíst.
• Obsah úložiště nelze aktualizovat.
• Podívejte se na zprávu, že úložiště bylo zakázané, když se pokusí o přístup k úložišti v uživatelském rozhraní Azure Repos.

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 do Nastavení projektu, vyberte Úložiště a pak konkrétní úložiště.

Možnost nakonfigurovat tvůrce větví tak, aby nedostávali oprávnění pro správu svých větví

Když vytvoříte novou větev, získáte u této větve oprávnění Spravovat. 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ý externí uživatel mohl 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 tyto změny provádět.

V této aktualizaci můžete nakonfigurovat všechna úložiště ve vašem týmovém projektu a omezit tvůrce větví, aby získali oprávnění Spravovat 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é a napodobuje stávající chování. Pokud ale chcete tuto novou funkci zabezpečení používat, můžete ji vypnout.

Možnost zabránit uživatelům forků v hlasování o upstreamových žádostech o přijetí změn

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 uživatelé mohli odeslat žádost o přijetí změn se změnami upstreamu, musí k upstreamu přispívat k žádostem o přijetí změn. Toto oprávnění ale také řídí, kdo může hlasovat o žádostech o přijetí změn v upstreamovém úložišti. V důsledku toho můžete skončit v situacích, kdy uživatel, který není přispěvatelem úložiště, může odeslat žádost o přijetí změn a způsobit jejich sloučení v závislosti na tom, jak nastavíte zásady větve.

V projektech, které podporují model vnitřního zdroje, je běžný vzor forku a přispívání. Abychom tento model dále zabezpečili a podpořili, měníme oprávnění hlasovat pro žádost o přijetí změn z příspěvku na žádosti o přijetí změn na příspěvek. 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.

Sestavy

Seskupení podle značek dostupných ve widgetech grafů

Widget 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 informace výběrem všech značek nebo sady značek ve widgetu.

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

Dříve jste nemohli zobrazit vlastní typy pracovních položek nakonfigurované ve widgetu burn down a sečíst nebo spočítat podle vlastního pole. V této aktualizaci jsme tento problém opravili a teď můžete zobrazit vlastní typy pracovních položek ve widgetu burndown.

---

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