Zpráva k vydání verze Azure DevOps Server 2019

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

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

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

Přímý upgrade na Azure DevOps Server 2020 se podporuje od Azure DevOps Server 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud tfs nasadíte v TFS 2010 nebo starší verzi, musíte před upgradem na Azure DevOps Server 2019 provést několik kroků. Další informace najdete v tématu Instalace a konfigurace Azure DevOps v místním prostředí.

---

Bezpečný upgrade z Azure DevOps Server 2019 na Azure DevOps Server 2020

Azure DevOps Server 2020 zavádí nový model uchovávání spuštění kanálu (build), který funguje na základě nastavení na úrovni projektu.

Azure DevOps Server 2020 zpracovává uchovávání sestavení odlišně v závislosti na zásadách uchovávání informací na úrovni kanálu. Některé konfigurace zásad vedou k odstranění spuštění kanálu po upgradu. Spuštění kanálu, která byla ručně zachována nebo která jsou zachována ve vydané verzi, se po upgradu neodstraní.

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

Azure DevOps Server 2019.0.1 Patch 16 Datum vydání: 14. listopadu 2023

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

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

Poznámka

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

Instalace oprav

Důležité

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

File	Hodnota hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Požadavky na kanál

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

• V klasickém režimu:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 15 Datum vydání: 12. září 2023

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

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

Důležité

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

Poznámka

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

Instalace oprav

1. Stáhněte a nainstalujte Azure DevOps Server 2019.0.1 Patch 15.

Aktualizace agenta Azure Pipelines

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

Poznámka

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

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

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

Požadavky na kanál

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

• V klasickém režimu:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 14 Datum vydání: 8. srpna 2022

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

• CVE-2023-36869: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity.

Azure DevOps Server 2019.0.1 Patch 13 Datum vydání: 17. května 2022

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

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

Azure DevOps Server 2019.0.1 Patch 12 Datum vydání: 26. ledna 2022

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

• Byla vyřešena chyba zabezpečení Elasticsearch odebráním třídy jndilookup z binárních souborů log4j.

Kroky instalace

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

Poznámka

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

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

Hash SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Patch 11 Datum vydání: 10. srpna 2021

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

• Oprava chyby uživatelského rozhraní definice sestavení

datum vydání patche 10 Azure DevOps Server 2019.0.1: 13. dubna 2021

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

• CVE-2021-27067: Zpřístupnění informací

Pokud chcete použít opravu 10, budete muset úlohu nainstalovat AzureResourceGroupDeploymentV2 .

Instalace úlohy AzureResourceGroupDeploymentV2

Poznámka

Všechny kroky uvedené níže je potřeba provést na počítači s Windows.

Instalace

1. Extrahujte balíčekAzureResourceGroupDeploymentV2.zip do nové složky v počítači. Příklad: AzureResourceGroupDeploymentV2.

2. Stáhněte a nainstalujte Node.js 14.15.1 a npm (součástí Node.js stažení) podle svého počítače.

3. Otevřete příkazový řádek v režimu správce a spuštěním následujícího příkazu nainstalujte tfx-cli.

npm install -g tfx-cli

4. Vytvořte osobní přístupový token s úplnými přístupovými oprávněními a zkopírujte ho. Tento osobní přístupový token se použije při spuštění příkazu tfx login .

5. Z příkazového řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a osobní přístupový token.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Spuštěním následujícího příkazu nahrajte úlohu na server. Použijte cestu k extrahovanému souboru .zip z kroku 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 9 Datum vydání: 8. prosince 2020

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-1325: Azure DevOps Server ohrožení zabezpečení z důvodu falšování identity
• CVE-2020-17135: Ohrožení zabezpečení z důvodu falšování identity Azure DevOps Server
• CVE-2020-17145: Ohrožení zabezpečení z důvodu falšování identity Azure DevOps Server a Team Foundation Serveru
• Oprava potíží, kdy TFVC nezpracovává všechny výsledky

Důležité

Před instalací této opravy si prosím přečtěte úplné pokyny uvedené níže.

Obecná instalace oprav

Pokud máte Azure DevOps Server 2019.0.1, měli byste nainstalovat opravu 9 Azure DevOps Server 2019.0.1.

Ověření instalace

• Možnost 1: Spusťte devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe je soubor, který se stáhne z výše uvedeného odkazu. Výstup příkazu buď bude hlásit, že oprava je nainstalovaná, nebo že nainstalovaná není.

• Možnost 2: Zkontrolujte verzi následujícího souboru: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 je ve výchozím nastavení nainstalovaný na c:\Program Files\Azure DevOps Server 2019 . Po instalaci Azure DevOps Server 2019.0.1 Patch 9 bude verze 17.143.30723.4 .

Instalace úlohy AzurePowerShellV4

Poznámka

Všechny kroky uvedené níže je potřeba provést na počítači s Windows.

Požadavky

1. Na počítač privátního agenta nainstalujte Azure PowerShell Azure PowerShell modulu Az.

2. Vytvořte kanál pomocí úlohy AzurePowerShellV4 . V úloze se zobrazí pouze jedno selhání při standardní chybě .

Instalace

1. Extrahujte balíčekAzurePowerShellV4.zip do složky s názvem AzurePowerShellV4.

2. Stáhněte a nainstalujte Node.js 14.15.1 a npm (součástí Node.js stažení) podle svého počítače.

3. Otevřete příkazový řádek v režimu správce a spuštěním následujícího příkazu nainstalujte tfx-cli.

npm install -g tfx-cli

4. Vytvořte osobní přístupový token s úplnými přístupovými oprávněními a zkopírujte ho. Tento osobní přístupový token se použije při spuštění příkazu tfx login .

5. Z příkazového řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a osobní přístupový token.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Spuštěním následujícího příkazu nahrajte úlohu na server. Cesta extrahovaného balíčku bude D:\tasks (1)\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

datum vydání patche 8 Azure DevOps Server 2019.0.1: 8. září 2020

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• DTS 1713492 – Neočekávané chování při přidávání skupin AD k oprávněním zabezpečení.

Azure DevOps Server 2019.0.1 Patch 7 Datum vydání: 14. července 2020

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-1326: Ohrožení zabezpečení při skriptování mezi weby
• Kanál buildu zobrazuje nesprávné připojení neoprávněným uživatelům při výběru možnosti Jiný zdroj Git.
• Oprava chyby při změně dědičnosti na Zapnuto nebo Vypnuto v definici sestavení XAML

Azure DevOps Server 2019.0.1 Patch 6 Datum vydání: 10. června 2020

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-1327: Ujistěte se, že Azure DevOps Server sanitizuje vstupy uživatelů.
• Přidání podpory pro SHA2 v SSH v Azure DevOps

Azure DevOps Server 2019.0.1 Patch 5 Datum vydání: 10. března 2020

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která opravuje následující: Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-0700: Ohrožení zabezpečení při skriptování mezi weby
• CVE-2020-0758: Ohrožení zabezpečení z důvodu zvýšení oprávnění
• CVE 2020-0815: Ohrožení zabezpečení z důvodu zvýšení oprávnění

Azure DevOps Server 2019.0.1 Patch 3 Datum vydání: 10. září 2019

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která odstraňuje následující chyby. Další informace najdete v tomto blogovém příspěvku.

• CVE-2019-1305 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Repos
• CVE-2019-1306 : Ohrožení zabezpečení v souvislosti s možným vzdáleným spuštěním kódu ve Wiki

---

datum vydání patche 2 Azure DevOps Server 2019.0.1: 13. srpna 2019

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která odstraňuje následující chybu. Další informace najdete v tomto blogovém příspěvku.

• Do připojení služeb jsme přidali informace, které objasňují, že jsou ve výchozím nastavení autorizovaná pro všechny kanály.

---

Azure DevOps Server 2019.0.1 Patch 1 Datum vydání: 9. července 2019

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která odstraňuje následující chyby. Další informace najdete v tomto blogovém příspěvku.

• CVE-2019-1072 : Ohrožení zabezpečení v souvislosti s možným vzdáleným spuštěním kódu při sledování pracovních položek
• CVE-2019-1076 : Chyba skriptování mezi weby (XSS) v žádostech o přijetí změn

---

datum vydání Azure DevOps Server 2019.0.1: 21. května 2019

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

Poznámka

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

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

Azure Boards

• "Kritéria pole pro tento plán mají chybu" při konfiguraci plánu. Nahlášeno prostřednictvím Developer Community.
• Apiwitcontroller.executequery vyvolá výjimku, pokud dotaz obsahuje stejný sloupec vícekrát.
• V objektovém modelu klienta používajícím obor vso.work_full oauth se workItemServer.DownloadFile() nezdaří.
• Zkopírování vloženého obrázku z pole pracovní položky do jiného pole pracovní položky v jiném projektu může vytvořit poškozený obrázek.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• Karta Test Analytics má star (*), která označuje náhled, i když tato funkce není ve verzi Preview.
• Na kartě Vydané verze se teď všem uživatelům zobrazí akce pro správu zabezpečení bez ohledu na to, jestli můžou oprávnění změnit nebo ne.
• Na cílových stránkách Vydané verze se při akci Spustit koncept verze vytvořila nová verze, ale teď se spustí koncept verze.

Azure Test Plans

• 1hodinový filtr pro TestRuns a TestResults CompletedDate je příliš podrobný.
• Typ pracovní položky Testovací případ by neměl být lokalizován.
• Testovací případy se nezobrazují v MTM ani v prohlížeči.
• Při spouštění automatizovaných testů z testovacího plánu nemáte oprávnění k aktivaci verzí v přidruženém kanálu verze. Nahlášeno prostřednictvím Developer Community.
• Pomocí rozhraní API pro odstranění testovacího případu je možné testovací případy odstranit z jiných projektů. Nahlášeno prostřednictvím Developer Community.
• Kliknutím na odkaz na pracovní položku v nástroji Test Runner se místo výchozího prohlížeče otevře adresa URL pracovní položky v nástroji Test Runner.
• Stav testovacího případu se neaktualizuje pro uživatele, kteří se odhlásí z Test Runneru.
• Uživatelské jméno a e-mailová adresa se nezobrazují v rozevíracím seznamu uživatele v nástroji Test Runner.

Azure Artifacts

• Funkce Move Up up a Move Down nejsou lokalizovány v upstreamech.

Analýzy

• Analytické sestavy můžou zobrazovat neúplná data, protože model se před dokončením označí jako připravený.
• Widgety pro rychlost, burndown a burnup zobrazují různou plánovanou práci pro uživatele v různých časových pásmech.
• Při provádění údržby může být u příjmu dat z analytics umístěna blokování, což může způsobit zastaralé sestavy.

Obecné

• Levé navigační položky se v IE zmáčknou, když není dostatek místa.

Správa

• Do upgradu kolekce bylo přidáno další protokolování, které pomáhá s laděním problémů.
• Pokud TfsConfig offlineDetach selže, chybová zpráva není možné reagovat.
• Dojde k chybovému ukončení služby TfsJobAgent.
• Rozšíření Search se po dokončení konfigurace nenainstaluje.
• Konzola pro správu přestane reagovat, když je poškozena konfigurační databáze.
• Funkce Service Hooks nemusí správně zpracovávat oznámení.
• Indexování vyhledávání kódu se po konfiguraci vyhledávání nespustí.
• Ve výsledcích hledání stránek jsou nelokalizované řetězce.

Tato verze obsahuje následující aktualizaci:

Podpora sady Visual Studio 2019 (VS2019) v úloze Visual Studio Test

Přidali jsme podporu pro Visual Studio 2019 k úloze Visual Studio Test v kanálech. Pokud chcete spustit testy pomocí testovací platformy pro Visual Studio 2019, v rozevíracím seznamu Verze testovací platformy vyberte možnosti Nejnovější nebo Visual Studio 2019 .

---

Azure DevOps Server 2019 Patch 2 Datum vydání: 14. května 2019

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019, která opravuje následující chyby. Další informace najdete v tomto blogovém příspěvku.

• CVE-2019-0872 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Test Plans
• CVE-2019-0971 : Ohrožení zabezpečení spočívající ve zpřístupnění informací v rozhraní API pro Repos
• CVE-2019-0979 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v centru uživatelů

---

Azure DevOps Server 2019 Patch 1 Datum vydání: 9. dubna 2019

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019, která opravuje následující chyby. Další informace najdete v tomto blogovém příspěvku.

• CVE-2019-0857: Ohrožení zabezpečení falšování identity na wikiwebu
• CVE-2019-0866 : Ohrožení zabezpečení v souvislosti s možným vzdáleným spuštěním kódu v Pipelines
• CVE-2019-0867 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Pipelines
• CVE-2019-0868 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Pipelines
• CVE-2019-0869: Ohrožení zabezpečení z důvodu injektáže HTML v kanálech
• CVE-2019-0870 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Pipelines
• CVE-2019-0871 : Ohrožení zabezpečení v souvislosti se skriptováním mezi weby (XSS) v Pipelines
• CVE-2019-0874: Ohrožení zabezpečení skriptování mezi weby (XSS) v pipelines
• CVE-2019-0875: Ohrožení zabezpečení z důvodu zvýšení oprávnění v tabulích

---

Azure DevOps Server 2019 Datum vydání: 5. března 2019

Poznámka

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

---

RC2 Datum vydání: 22. ledna 2019

Shrnutí novinek v Azure DevOps Server 2019 RC2

Do verze RC2 jsme přidali následující funkce:

• Propojení potvrzení GitHubu Enterprise a žádostí o přijetí změn s Azure Boards pracovními položkami
• Konfigurace sestavení pomocí YAML
• Poznámky ke kartám zahrnují chyby a vlastní typy pracovních položek.
• Vylepšený výběr větví
• Změny licencování kanálů nasazení Release Management artefaktů a Release Management

---

RC1 Datum vydání: 19. listopadu 2018

Shrnutí novinek v Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 přináší nové navigační prostředí a mnoho nových funkcí. Mezi nejzajímavější z nich patří:

• Nové navigační prostředí
• Teď je k dispozici rozšíření Analytics Marketplace pro vytváření sestav.
• Podpora pro Azure SQL Database
• Dědičnost procesu u nových kolekcí
• Nové centrum Pracovních položek
• Nové panely, backlogy a centra sprintů
• Nové centrum dotazů
• Standardizace popisů žádostí o přijetí změn pomocí šablon
• Změna cílové větve žádosti o přijetí změn
• Správa kanálů sestavení pomocí nové stránky Builds
• Správa kanálů vydaných verzí pomocí nové stránky vydaných verzí
• Vizualizace průběhu vydávání
• Místní aktualizace agenta
• Postupné zveřejnění a fáze nasazení pomocí bran vydaných verzí
• Upstreamové zdroje
• Vytvoření obsahu pro stránky wikiwebu

Můžete také přejít na jednotlivé oddíly a podívat se na nové funkce:

• Obecné
• Boards
• Repos
• Pipelines
• Test Plans
• Artifacts
• Wiki
• Generování sestav

---

Obecné

Oznamujeme Azure DevOps Server

10. září jsme oznámili Azure DevOps jako vývoj Visual Studio Team Services a Team Foundation Serveru. Azure DevOps Server 2019 je naše první místní verze s touto novou značkou. Další informace najdete v našem blogovém příspěvku.

Nové navigační prostředí

Představujeme novou navigaci, která modernizuje uživatelské prostředí. Tato nová navigace byla nasazena ve službě Azure DevOps a je nyní k dispozici v Azure DevOps Server 2019. Další informace najdete na našem blogu .

Změny licencování kanálů nasazení Release Management artefaktů a Release Management

Na základě zpětné vazby uživatelů provádíme v našich licencích Azure DevOps Server 2019 dvě klíčové změny. Zákazníci si už nebudou muset kupovat rozšíření Artifacts, aby mohli artifacts používat. Použití licence Artifacts bude nyní součástí základní licence. Artefakty teď budou moct používat všichni uživatelé, kteří mají přiřazenou základní licenci. Za druhé už zákazníci nebudou muset kupovat kanály nasazení Release Management. Stejně jako kanály buildu jsou teď kanály nasazení Release Management součástí Azure DevOps Server 2019.

Podpora Azure SQL Database

Abychom zjednodušili používání Azure DevOps 2019 v Azure, povolili jsme podporu služby Azure SQL Database (Pro obecné účely S3 a vyšší). To vám umožní využívat rozsáhlé funkce zálohování a možnosti škálování tak, aby vyhovovaly vašim potřebám, a zároveň snížit administrativní režii spojenou se spuštěním služby. Mějte na paměti, že virtuální počítač hostitele se musí nacházet ve stejné oblasti Azure jako vaše databáze, aby se zachovala nízká latence. Další informace najdete v dokumentaci .

Pracovní položka & rozhraní API SOAP objektového modelu klienta v budoucích verzích

Azure DevOps Server 2019 i nadále podporuje rozhraní API SOAP pro sledování pracovních položek a objektový model klienta. V budoucích verzích aplikace Azure DevOps Server se ale označí jako zastaralá. Další informace najdete v naší dokumentaci.

Dědičnost procesů u nových kolekcí

Dědičnost procesů je teď k dispozici u nových kolekcí. Při vytváření nové kolekce se uživatelé budou muset ohledně modelu procesu rozhodnout svědomím. Informace o tom, co je model dědičnosti a jak se liší od XML, najdete v naší dokumentaci .

Rozbalené vyhledávací pole

Chápeme důležitost vyhledávání a vracíme zpět rozšířené vyhledávací pole v záhlaví produktu. Kromě toho teď můžete vyhledávací pole vyvolat jednoduše kliknutím na "/" na libovolné stránce služby v Azure DevOps.

Tady je výchozí vyhledávací pole:

Jakmile zadáte "/", zobrazí se rozbalené vyhledávací pole:

Vysouvací panel Moje práce

Novou funkcí, kterou s radostí představujeme, je informační panel moje práce . Vyslyšeli jsme zpětnou vazbu, že když jste v jedné části produktu a chcete nějaké informace z jiné části, nechcete ztratit svůj kontext. Díky této nové funkci máte k tomuto informačnímu rámečku přístup odkudkoli v produktu a získáte rychlý přehled o důležitých informacích, včetně pracovních položek, žádostí o přijetí změn a všech oblíbených položek. Pokud jste v repos v tomto novém informačním rámečku, ve svém kódu se dostanete dolů, ale pak chcete rychle zkontrolovat, na které pracovní položce byste měli pracovat jako další, můžete jednoduše kliknout na informační panel, zobrazit vám přiřazené pracovní položky a vybrat další položku.

Níže se můžete podívat na vysouvací panel Moje práce s přiřazenými pracovními položkami:

Tady vidíte druhý pivot, který zobrazuje žádosti o přijetí změn, které mám přiřazené. V informačním rámečku máte také přístup jedním kliknutím, abyste zobrazili další žádosti o přijetí změn:

Tady uvidíte poslední pivot, což je vše, co jste si oblíbili. Patří sem vaše oblíbené týmy, řídicí panely, panely, backlogy, dotazy a úložiště:

Boards

Propojení potvrzení GitHub Enterprise a žádostí o přijetí změn s Azure Boards pracovními položkami

Týmy, které používají GitHub Enterprise pro kód a chtějí bohaté možnosti správy projektů, teď můžou integrovat svá úložiště s Azure Boards. Propojením GitHubu a Azure Boards můžete získat všechny funkce, jako jsou backlogy, panely, nástroje pro plánování sprintů, více typů pracovních položek, a stále mít pracovní postup, který se integruje s pracovními postupy vývojářů v GitHubu.

Propojení potvrzení a žádostí o přijetí změn s pracovními položkami je snadné. Zmiňte pracovní položku pomocí následující syntaxe:

AB#{work item ID}

Zmiňte pracovní položku v potvrzovací zprávě, názvu žádosti o přijetí změn nebo popisu žádosti o přijetí změn a Azure Boards vytvoří odkaz na tento artefakt. Představte si například zprávu potvrzení, která vypadá takto:

Adds support for deleting connections. Fixes AB#20.

Tím se vytvoří odkaz z pracovní položky č. 20 na potvrzení v GitHubu, který se zobrazí v oddílu Vývoj pracovní položky. ​

Pokud jsou před zmínkou o pracovní položce slova "fix", "fixes" nebo "fixed" (jak je znázorněno výše), pracovní položka se při sloučení potvrzení s výchozí větví přesune do dokončeného stavu.

Týmy, které k vytváření kódu na GitHubu používají Azure Pipelines, uvidí v souhrnu sestavení také pracovní položky propojené s potvrzeními GitHubu.

Nové centrum pracovních položek

Centrum pracovních položek je naše nové centrum, které bude sloužit jako domovská stránka vašich pracovních položek. Tady máte mnoho různých zobrazení seznamu pracovních položek, které jsou pro vás omezené. Zobrazením Přiřazeno mně můžete rychle získat přehled o veškeré práci, která je vám přiřazena, nebo v nedávné aktualizaci, která zobrazuje všechny pracovní položky ve vašem projektu, které byly naposledy aktualizovány. Všechny možnosti seznamu najdete níže:

Pokud chcete seznam ještě více omezit, můžete filtrovat podle typu, přiřazení, stavu, oblasti, značek a klíčových slov. Jakmile budete mít požadované zobrazení seznamu, můžete pracovní položky seřadit jednoduše kliknutím na záhlaví sloupce. Pokud je jeden sloupec příliš úzký na to, abyste mohli zobrazit jeho úplný obsah, můžete snadno změnit velikost sloupce v oblasti záhlaví. Tyto možnosti můžete vidět níže:

Nové panely, backlogy a centra sprintů

Centrum Backlogs (Backlogs ) bylo rozděleno do tří různých center, aby se zlepšilo uživatelské prostředí. I když je staré centrum Backlogs výkonné, bylo domovem příliš mnoha funkcí. To často způsobovalo, že bylo obtížné najít funkci nebo možnosti, které uživatelé hledali. Abychom tento problém vyřešili, rozdělili jsme centrum Backlogs na:

• Centrum Backlogs (Backlogs ) je teď domovem pouze backlogů pro projekt. Backlog je seznam práce týmu seřazený podle priority. Backlogy poskytují nástroje pro plánování, jako je hierarchie pracovních položek, prognózování a nové prostředí pro plánování sprintů.
• Nové centrum Boards je domovem pro všechny kanbanové panely pro projekt. Panely slouží ke komunikaci o stavu a toku. Karty (pracovní položky) se přesouvají zleva doprava na panelu prostřednictvím sloupců definovaných týmem.
• Nové centrum Sprints je domovem funkcí, které se používají k plánování a provádění přírůstkové práce. Každý sprint obsahuje backlog sprintu, taskboard a zobrazení pro správu a nastavení kapacity pro tým.

Nové centrum dotazů

Nové centrum dotazů zjednodušuje řadu stávajících funkcí dotazů ze starého centra s modernějším vzhledem a chováním a poskytuje nové možnosti, které usnadňují přístup k dotazům, které jsou pro vás důležité. Mezi nejdůležitější prvky nového prostředí patří:

• Stránky adresáře s naposledy upravenými informacemi a možností vyhledávání dotazů
• Popis cesty s jedinečnými adresami URL pro složky, které si označit jako záložku důležitých skupin dotazů
• Rychlý přístup k oblíbeným dotazům ze stránky výsledků

Další informace o těchto zajímavých aktualizacích najdete na našem blogu DevOps.

Přesunutí pracovních položek do jiného projektu a změna typu pracovní položky

Teď můžete změnit typ pracovní položky nebo přesunout pracovní položky do jiného projektu v rámci kolekce projektů. Tyto funkce vyžadují, aby byl datový sklad zakázaný. Když je datový sklad zakázaný, můžete k podpoře svých potřeb vytváření sestav použít analytickou službu . Další informace o zakázání datového skladu najdete v tématu Zakázání datového skladu a datové krychle.

Funkce plánování sprintů

Nové funkce plánování sprintů pomáhají urychlit a vylepšit prostředí pro plánování sprintů.

• Vytvořte svůj další sprint nebo se přihlaste k odběru existujícího plánu sprintů přímo z centra Sprints .
• Pomocí nového podokna Plánování v backlogu můžete přetáhnout pracovní položky do budoucích sprintů. Podokno Plánování obsahuje data sprintů, počty pracovních položek a plánované úsilí.
• Přidejte požadavky do horní části hlavního panelu nebo pomocí rychlého vytvoření přidejte do vybraného horního, dolního řádku nebo do backlogu sprintu.
• Pomocí filtrů pro příjemce, typ pracovní položky, stav a značky můžete zobrazení přizpůsobit svým potřebám.

Stránky nového adresáře

Všechna nová centra, včetně backlogů, boards a sprintů, teď mají nové stránky adresáře uspořádané do následujících oddílů:

• Pokračovat tam, kde jste přestali Tento nový oddíl vám poskytne rychlý odkaz přímo na poslední (Panel | Backlog | Sprint), na které jste byli.
• Oblíbené položky Všechny vaše oblíbené panely, sprinty a backlogy napříč všemi týmy.
• Můj Všechny panely, backlogy a sprinty pro týmy, do nichž patříte.
• Všechny Úplný seznam všech vašich panelů, backlogů a sprintů

Nabídka Nové možnosti zobrazení

Nová centra, včetně backlogů, panelů a sprintů, mají novou nabídku Možnosti zobrazení . Toto je nová domovská stránka pro všechny akce, které slouží k přizpůsobení rozložení a obsahu stránky. Pomocí možností zobrazení můžete povolit další zobrazení, například zobrazení hierarchie v backlogech nebo změnu možnosti Seskupit podle na panelu úloh, zapnout boční panel pro mapování a plánování sprintů nebo prozkoumat grafy podrobností o práci.

Další informace o těchto zajímavých aktualizacích, novém podokně Profil týmu a oblíbené položky si můžete přečíst na našem blogu DevOps.

Poznámky ke kartám zahrnují chyby a vlastní typy pracovních položek.

Poznámky ke kartám jsou oblíbené pro intuitivní zobrazení kontrolního seznamu a interakci. Dříve byly poznámky ke kartám omezené na výchozí typy na úrovni backlogu a nepodpořily chyby ani vlastní typy. V nové verzi jsme odebrali omezení typů pracovních položek a přidali jsme možnost zobrazovat chyby a jakýkoliv vlastní typ pracovní položky jako poznámku na kartě.

Nastavení panelu pro poznámky ke kartám bylo rozbalené tak, aby zahrnovalo všechny typy pracovních položek dostupné pro danou úroveň backlogu.

Pokud jsou povoleny poznámky k pracovní položce, jsou počty pro tento typ pracovní položky zahrnuty na kartě jako samostatný kontrolní seznam.

Rychlé vytvoření povolených typů pracovních položek je k dispozici také prostřednictvím místní nabídky karty.

Přesunutí práce pomocí navrhovaných oblastí a iterací

Může být běžné pracovat ve stejné oblasti nebo iteraci a při přesouvání pracovních položek opakovaně procházet hierarchiemi. Ovládací prvky Oblast a Cesta iterace teď obsahují seznam naposledy použitých hodnot jako Návrhy, které umožňují rychlý přístup k nastavení a pohybu dál.

Data iterace jsou navíc uvedena napravo od názvu, abyste mohli rychle posoudit, kdy má být pracovní položka doručena.

Dotazování v rámci plánu iterace s +/- @CurrentIteration

Makro @CurrentIteration , které pomáhá týmu sledovat práci na základě plánu iterace, teď podporuje celočíselný posun. Snadno si udržujte přehled o práci, která se nezavřela @CurrentIteration pomocí – 1, nebo se podívejte dopředu na práci naplánovanou pro budoucí iterace s @CurrentIteration + 1. Další informace najdete v @CurrentIteration příspěvku na blogu Microsoft DevOps.

Objasnění plánů iterace dotazů pomocí parametru @CurrentIteration Team

Pokud jste makro používali @CurrentIteration v dotazech v minulosti, možná jste si všimli, že se výsledky můžou lišit, pokud se kontext týmu v různých týmech mění s různými plány iterací. Když teď vytvoříte nebo upravíte dotaz pomocí @CurrentIteration makra, budete muset také vybrat tým s plánem iterace, který je pro dotaz relevantní. S parametrem Team můžete makro použít @CurrentIteration ve stejném dotazu, ale napříč týmy. Jedním z příkladů může být dotaz na pracovní položky ve dvou různých týmových projektech s použitím různých názvů iterací a dokonce i plánů. To znamená, že při změně sprintů už nemusíte aktualizovat dotazy. Další informace najdete v @CurrentIteration příspěvku na blogu Microsoft DevOps.

Práce s dotazem v cestách oblastí týmu pomocí nového @TeamAreas makra

V nastavení pro tým můžete přidružit jednu nebo více cest oblastí, což vám pomůže zaměřit backlogy, panely, plány a dokonce i řídicí panely jenom na práci pro daný tým. Pokud jste ale chtěli napsat dotaz pro tým, museli jste v klauzulích dotazu uvést konkrétní cesty oblastí pro tento tým. Nyní je k dispozici nové makro @TeamAreas , abyste mohli snadno odkazovat na cesty oblasti vlastněné pro zadaný tým.

Dotaz na prázdná pole ve formátu RTF

Pomocí nového operátoru dotazu IsEmpty vyhledejte pracovní položky, které mají prázdné pole s formátovaným textem, například Popis.

Snadné vyhledání existujících pracovních položek v prostředích propojování a zmínek

Když chcete propojit dvě existující pracovní položky, můžete teď snadno najít položku, která je pro vás důležitá, pomocí našeho nového ovládacího prvku hledání pracovních položek. Volič dotazu byl nahrazen vloženými návrhy založenými na nedávno použitých pracovních položkách a také vstupním bodem pro vyhledání konkrétní pracovní položky podle ID nebo názvu.

Otevření pracovních položek z vyhledávání

Dříve nešlo pracovní položku otevřít ze stránky výsledků hledání, pokud bylo vypnuté podokno náhledu pracovní položky. To by ztěžovalo prozkoumání výsledků hledání. Teď můžete kliknout na název pracovní položky a otevřít je v modálním okně.

Repos

Vylepšený výběr větví

Většina prostředí v Azure Repos vyžadovat, abyste vybrali úložiště a pak větev v daném úložišti. Abychom toto prostředí vylepšili pro organizace s velkým počtem větví, zavádíme nový nástroj pro výběr větví. Výběr teď umožňuje vybrat oblíbené větve nebo rychle vyhledat větev.

Příjem oznámení při obejití zásad žádostí o přijetí změn

Pro týmy, které používají žádosti o přijetí změn (PR) a zásady větví, můžou narazit situace, kdy lidé potřebují tyto zásady přepsat a obejít – například při nasazování opravy hotfix do produkčního problému uprostřed noci. Je vhodné důvěřovat vývojářům, že dělají správnou věc, a používat funkci přepsání střídmě. Týmy zároveň potřebují způsob, jak ověřit, že se přepsání zásad používají ve správných situacích. Abychom to podpořili, přidali jsme nový filtr oznámení, který uživatelům a týmům umožňuje dostávat e-mailová upozornění při každém obcházení zásady. Začněte šablonou Vytvoření nebo aktualizace žádosti o přijetí změn a v seznamu filtrů vyberte Obejít zásady . Jako hodnotu Vyberte Zásady byly vynechány a při každém dokončení žádosti o přijetí změn dostanete oznámení a zásady se obejdou.

Povolení obejití zásad větví bez vzdání se ochrany před nabízenými oznámeními

Existuje mnoho scénářů, kdy občas potřebujete obejít zásady větve – vrácení změny, která způsobila přerušení sestavení, použití opravy hotfix uprostřed noci atd. Dříve jsme nabídli oprávnění ("Vyloučení z vynucování zásad"), abychom týmům pomohli spravovat, kteří uživatelé dostali možnost obejít zásady větve při dokončování žádosti o přijetí změn. Toto oprávnění však také udělilo možnost nasdílení změn přímo do větve a proces žádosti o přijetí změn zcela obchází.

Abychom toto prostředí vylepšili, rozdělili jsme stará oprávnění, abychom týmům, které udělují oprávnění k obejití, nabídli větší kontrolu. Původní oprávnění můžete nahradit dvěma novými oprávněními:

1. Obcházení zásad při dokončování žádostí o přijetí změn Uživatelé s tímto oprávněním budou moct pro žádosti o přijetí změn používat prostředí Přepsat.
2. Obejití zásad při nasdílením změn Uživatelé s tímto oprávněním budou moct odesílat změny přímo do větví s nakonfigurovanými požadovanými zásadami.

Když uživatel udělí první oprávnění a druhé oprávnění odepře, bude moct v případě potřeby použít možnost obcházení, ale bude mít i nadále ochranu před náhodným nasdílením změn do větve se zásadami.

Poznámka

Tato změna nezavádí žádné změny chování. Uživatelům, kterým byla dříve udělena možnost Povolit pro výjimku z vynucování zásad, se udělí možnost Povolit pro obě nová oprávnění, takže budou moct jak přepsat dokončování žádostí o přijetí změn, tak přímo do větví se zásadami.

Další informace najdete v dokumentaci k nastavení oprávnění větví .

Rychlé popisy žádostí o přijetí změn pomocí potvrzovacích zpráv

Psaní popisných zpráv potvrzení přidává hodnotu do historie libovolného úložiště Git. Nové žádosti o přijetí změn, které mají více potvrzení, vyžadují, aby přispěvatelé zadali název ručně.

Popisy žádostí o přijetí změn budou ve výchozím nastavení nadále prázdné, ale nová funkce usnadní začlenění zpráv o potvrzení z potvrzení žádosti o přijetí změn do popisu žádosti o přijetí změn. Pokud chcete přidat potvrzovací zprávy, jednoduše klikněte na Přidat zprávy potvrzení a připojte potvrzovací zprávy na konec textu popisu žádosti o přijetí změn.

Vytváření žádostí o přijetí změn bez výchozího týmu jako revidujícího

Když jsme poprvé spustili prostředí žádostí o přijetí změn, mysleli jsme si, že by mělo smysl přiřadit všechny žádosti o přijetí změn k kontextu týmu, který jste vybrali při vytváření žádosti o přijetí změn. Toto chování bylo frustračním bodem, protože mnoho lidí si nevšimlo spojení mezi týmovým kontextem a přiřazením žádosti o přijetí změn.

V rámci nových změn navigace jsme využili příležitost změnit toto výchozí přidružení k týmům. Všimněte si dvou změn:

1. Při vytváření žádosti o přijetí změn se ve výchozím nastavení nepřidávají žádní revidující. Seznam revidujících má funkci, která usnadňuje přidávání jednotlivců a skupin, které byly nedávno přidány do žádostí o přijetí změn. Zásady požadovaných revidujících můžou také pomoct týmům, které chtějí zajistit, aby se ke kontrole kódu přidali konkrétní revidující.
2. Centrum Žádosti o přijetí změn má nový přizpůsobitelný oddíl. Ve výchozím nastavení tato část zobrazuje žádosti o přijetí změn přiřazené mým týmům a poskytují ekvivalentní funkce jako starý oddíl. Pokud ale patříte do více týmů, zobrazí se v této části žádosti o přijetí změn přiřazené k některému z vašich týmů. Oddíl je také přizpůsobitelný – stačí kliknout na akci Přizpůsobit toto zobrazení v blízkosti záhlaví oddílu.

Standardizace popisů žádostí o přijetí změn pomocí šablon

Psaní správných popisů žádostí o přijetí změn je skvělý způsob, jak revidujícímu pomoci zjistit, co při kontrole kódu očekávat. Představují také skvělý způsob, jak pomoct sledovat věci, které by se měly udělat pro každou změnu, jako je testování, přidávání testů jednotek a aktualizace dokumentace. Mnozí z vás požadovali, abychom přidali šablony žádostí o přijetí změn, které týmům usnadní psaní skvělých popisů, a teď jsme tuto funkci přidali.

Kromě podpory výchozí šablony popisu žádosti o přijetí změn můžou týmy přidat několik šablon, které se zobrazí v nabídce na stránce vytvoření žádosti o přijetí změn. Stačí kliknout na tlačítko Přidat šablonu a vybrat některou šablonu v úložišti a připojit ji k popisu žádosti o přijetí změn.

Podporují se také šablony specifické pro větev, pokud chcete použít jinou šablonu pro žádost o přijetí změn do konkrétní větve nebo složky větve. Pokud například chcete mít šablonu specifickou pro všechny větve, které začínají na "hotfix/", můžete do těchto větví přidat šablonu, která bude použita pro všechny žádosti o přijetí změn.

Další informace o vytváření a používání šablon najdete v dokumentaci k šablony žádostí o přijetí změn.

Změna cílové větve žádosti o přijetí změn

U většiny týmů cílí téměř všechny žádosti o přijetí změn na stejnou větev, například main nebo develop. V případě, že potřebujete cílit na jinou větev, je ale snadné zapomenout změnit cílovou větev z výchozí. S novou funkcí, která mění cílovou větev aktivní žádosti o přijetí změn, je to teď jednoduchá akce. Stačí kliknout na ikonu tužky v blízkosti názvu cílové větve v záhlaví žádosti o přijetí změn.

Kromě pouhé opravy chyb funkce pro změnu cílových větví také usnadňuje "retarget" žádosti o přijetí změn, když byla cílová větev sloučena nebo odstraněna. Představte si scénář, kdy žádost o přijetí změn cílí na větev funkcí, která obsahuje některé funkce, na kterých jsou vaše změny závislé. Chcete zkontrolovat závislé změny izolovaně od ostatních změn ve větvi funkcí, takže zpočátku cílíte features/new-featurena . Revidující pak uvidí jenom vaše změny a zanechají příslušné komentáře.

Teď zvažte, co by se stalo, kdyby větev funkce měla také aktivní žádost o přijetí změn a před vašimi změnami se sloučila main s? Dříve byste museli upustit od změn a vytvořit novou žádost o přijetí změn do main, nebo sloučit žádost o přijetí změn do features/new-featurea pak vytvořit další žádost o přijetí změn z features/new-feature do main. Pomocí této nové akce pro aktualizaci cílové větve můžete jednoduše změnit cílovou větev žádosti o přijetí změn na features/new-featuremaina zachovat veškerý kontext a komentáře. Změnou cílové větve se dokonce vytvoří nová aktualizace žádosti o přijetí změn, která usnadňuje pohled na předchozí rozdíly před změnou cílové větve.

Autoři rozšíření se můžou dotazovat na kontext aktuálního úložiště.

Jednou z výzev pro autora rozšíření správy verzí je získání kontextu úložiště, které se uživateli zobrazuje, jako je jméno, ID a adresa URL. Abychom tomu pomohli, přidali jsme VersionControlRepositoryService jako službu s podporou rozšíření. Autor rozšíření se tak může dotazovat na informace o aktuálním kontextu úložiště Git v rámci webového uživatelského rozhraní. V současné době má jednu metodu getCurrentGitRepository().

• Pokud je vybrané úložiště Git, vrátí se objekt GitRepository se základními daty o úložišti (název, ID a adresa URL).
• Pokud je vybrané úložiště TFVC nebo se ke službě přistupuje mimo stránky Azure Repos, vrátí se hodnota null.

Tady je ukázkové rozšíření , které tuto službu používá.

Pipelines

Správa kanálů sestavení pomocí nové stránky Builds

Provádíme několik vylepšení a zavádíme novou verzi stránky Sestavení . Tato nová verze kombinuje adresář všech kanálů sestavení a seznam aktuálních buildů, abyste mohli rychle procházet sestaveními projektu a zobrazit jejich stav. Obsahuje také verzi Preview testovací analýzy pro vybraný kanál.

Lepší správa e-mailů o dokončení sestavení a nasazení pomocí vylepšeného formátování

Aktualizovali jsme e-maily o dokončení sestavení a nasazení, aby bylo možné lépe filtrovat podle pravidel e-mailu. Nyní řádek předmětu obsahuje na první pohled relevantnější informace, tělo obsahuje více podrobností a jejich styl byl aktualizován o nejnovější značku.

Prvky nového formátu jsou:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Tady je pár příkladů:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Postupujte podle nové sjednocené terminologie Azure Pipelines.

V průběhu buildů a vydaných verzí se v minulosti pro podobné koncepty používaly různé termíny. V jiných případech byly významy termínů vágní. Můžete například říct rozdíl mezi fondem agentů a frontou agenta.

Terminologie byla v Azure Pipelines sjednocena, aby se objasnily její koncepty. Teď uvidíte následující sjednocené termíny:

Předchozí termín	Jednotný termín	Význam
Hostovaný agent	Agent hostovaný Microsoftem	Agent sestavení/verze, který běží na infrastruktuře hostované v cloudu spravované Microsoftem.
Privátní agent	Agent v místním prostředí	Agent sestavení/verze, který běží na počítači, který poskytujete a spravujete.
Fond agentů	Fond agentů	Sada počítačů agentů na úrovni organizace, které můžou spouštět sestavení nebo vydané verze.
Fronta agentů	Fond agentů	Sada počítačů agentů na úrovni projektu, které můžou spouštět sestavení nebo vydané verze. Je propojený s fondem agentů na úrovni organizace.
Definice sestavení	Kanál buildu	Kompletní sada kroků sestavení pro aplikaci.
Sestavení	Sestavení	Instance kanálu sestavení, který je spuštěný nebo spuštěný.
Fáze	Úloha	Řada úloh, které se na agentu spouští postupně nebo paralelně. Kanál sestavení nebo verze může obsahovat jednu úlohu nebo graf více úloh.
Definice verze	Kanál verze	Kompletní sada kroků vydané verze pro aplikaci, která se má nasadit v různých fázích.
Vydat	Vydat	Instance kanálu verze, který je spuštěný nebo spuštěný.
Prostředí	Fáze	Logická a nezávislá entita, která představuje, kam chcete nasadit verzi vygenerovanou z kanálu verze.
Souběžná úloha nebo kanál	Paralelní úloha	Paralelní úloha umožňuje spustit jednu úlohu sestavení nebo vydané verze najednou ve vaší organizaci. Pokud máte k dispozici více paralelních úloh, můžete současně spouštět více úloh sestavení a vydaných verzí.
Koncový bod služby	Připojení služby	Skupina nastavení, například přihlašovací údaje, která slouží k připojení k externím službám za účelem provádění úloh v sestavení nebo vydané verzi.

Další informace najdete v dokumentaci k konceptům .

Správa kanálů vydaných verzí pomocí nové stránky vydaných verzí

Pro cílovou stránku verze je k dispozici nové a plně přepracované uživatelské prostředí. Podívejte se na seznam kanálů verzí, které často vydáváte, na levé straně. Kanály můžete také prohledávat a označit je jako oblíbené.

Změňte zobrazení složek a vytvořte složky pro organizaci a zabezpečení. Zabezpečení je možné nastavit na úrovni složky.

Vizualizace průběhu vydávání verzí

Nové zobrazení průběhu vydání vám poskytne živé aktualizace průběhu nasazení a přístup k dalším podrobnostem jedním kliknutím. Nové zobrazení vizualizuje kanál verze, což usnadňuje pochopení toho, co se děje, a zobrazuje příslušné podrobnosti a akce v různých fázích vydání.

Kanál, podrobnosti o verzi a prostředí

V zobrazení Kanál se zobrazují artefakty vydané verze a prostředí, ve kterých se nasadí. Oblast Vydání obsahuje podrobnosti o verzi, jako je aktivační událost vydané verze, verze artefaktů a značky.

Prostředí jsou modelována způsobem, který pomáhá pochopit jejich stav a podrobný postup. K protokolům se můžete kdykoli dostat kliknutím na odkaz na stav v rámci prostředí.

Před nasazením a po nasazení

Pokud jsou pro prostředí nastavené podmínky před nasazením nebo po nasazení, je to v prostředí označeno s přítomností schválení a bran. Průběh schvalování a bran se také projeví ve stavu prostředí. Kliknutím na ikonu podmínky prostředí na pravé nebo levé straně prostředí můžete provést akci nebo zobrazit další podrobnosti.

Potvrzení a pracovní položky

S každou novou verzí můžete kliknutím na prostředí zobrazit seznam přidružených potvrzení a pracovních položek pro každé prostředí zvlášť. Pokud je seznam dlouhý, najděte potvrzení nebo pracovní položku, které vás zajímají, pomocí filtrů.

Průběh nasazení a protokoly

Prostředí zobrazují živé aktualizace probíhajících nasazení, včetně počtu dokončených fází a úkolů a doby běhu. Kliknutím na stav prostředí otevřete zobrazení obsahující protokoly s fokusem na aktuálně aktivní položky.

Kliknutím na protokoly můžete přejít do zobrazení s fokusem.

Dopad upgradu na Azure DevOps Server 2019 na úlohy: Kopírování souborů počítače s Windows a PoweShell na cílovém počítači

Skupiny počítačů v centru testování byly v TFS 2017 RTM zastaralé . V Azure DevOps Server 2019 už není služba Skupiny počítačů dostupná. To bude mít vliv na uživatele úlohy Kopírování souborů počítače s Windows verze 1* a Úlohy PowerShellu na cílových počítačích verze 1.*. Aby vaše kanály dál fungovaly,

• Musíte přepnout na úlohu Kopírování souborů počítače s Windows verze 2* a místo jenom názvu počítače zadat úplný plně kvalifikovaný název domény pro cílový počítač.
• Přepněte na úlohu PowerShell na cílovém počítači verze 2* nebo novější a zadejte úplný plně kvalifikovaný název domény počítače nebo počítače následovaný porty vzdálené správy systému Windows (http/https). Například targetMachine:5985 nebo targetMachine:5986

Výsledky testů a rozšiřitelnost

Výsledky z provádění testů se také zobrazí pro každé prostředí. Kliknutím na výsledky testu se otevře zobrazení s podrobnostmi o testu, včetně výsledků z jiných rozšíření, která k procesu přispívají.

Stávající rozšíření fungují v tomto novém zobrazení a navíc jsou k dispozici nové body rozšiřitelnosti, které umožňují rozšíření vyvíjet a zobrazovat ještě více informací pro prostředí. Další informace najdete v dokumentaci k příspěvkům a rozšířením .

Konfigurace sestavení pomocí YAML

Kanály sestavení založené na YAML jsou k dispozici ve vašem Azure DevOps Server. Automatizujte kanál průběžné integrace pomocí souboru YAML, který je vrácený do vašeho úložiště. Kompletní referenční informace o schématu YAML najdete tady.

Abychom zajistili plynulejší podporu kanálů sestavení založených na YAML, změnili jsme výchozí chování pro všechny nové prostředky, které vytvoříte (například připojení služeb, skupiny proměnných, fondy agentů a zabezpečené soubory), aby byly použitelné ve všech kanálech daného projektu. Pokud chcete mít nad prostředky přísnější kontrolu, můžete výchozí model autorizace zakázat (viz obrázek níže). Když to uděláte, musí někdo s oprávněními k použití prostředku po přidání odkazu na prostředek do souboru YAML kanál explicitně uložit ve webovém editoru.

Řetězení souvisejících sestavení pomocí triggerů dokončení sestavení

Velké produkty mají několik komponent, které jsou na sobě závislé. Tyto komponenty se často vytvářejí nezávisle. Když se změní nadřazená komponenta (například knihovna), musí být podřízené závislosti znovu sestaveny a znovu ověřovány. Týmy obvykle tyto závislosti spravují ručně.

Teď můžete aktivovat sestavení po úspěšném dokončení dalšího sestavení. Artefakty vytvořené nadřazeným sestavením je možné stáhnout a použít v pozdějším sestavení a můžete také získat data z těchto proměnných: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Další informace najdete v dokumentaci k triggerům sestavení .

Mějte na paměti, že v některých případech může vašim potřebám vyhovovat jedno vícefázové sestavení . Trigger dokončení sestavení je ale užitečný, pokud vaše požadavky zahrnují různá nastavení konfigurace, možnosti nebo jiný tým, který vlastní závislý proces.

Místní aktualizace agenta

Úlohy, které instalujete z galerie, někdy vyžadují novější verzi agenta kanálů. Pokud se váš Azure DevOps Server může připojit k internetu, novější verze se stáhnou automaticky. Pokud ne, musíte každého agenta upgradovat ručně. Počínaje touto verzí můžete nakonfigurovat Azure DevOps Server tak, aby soubory balíčku agenta hledala na místním disku, a ne z internetu. Získáte tak flexibilitu a kontrolu nad tím, jaké verze agenta zpřístupníte, aniž byste museli vystavit Azure DevOps Server na internetu.

Adresa URL odznáčku stavu nového buildu

Odznáčky sestavení vložené do domovské stránky úložiště představují běžný způsob, jak zobrazit stav úložiště. I když jsme dosud měli odznáčky buildů, došlo k několika problémům:

• Adresa URL nebyla intuitivní.
• Odznáček nebyl specifický pro větev.
• Uživatel neměl možnost kliknout na odznáček a převést ho na nejnovější build dané definice.

Nyní zavádíme nové rozhraní API pro odznáčky buildů, které tyto problémy řeší. Nové rozhraní API umožňuje uživatelům publikovat stav jednotlivých větví a může uživatele převést na nejnovější sestavení vybrané větve. Adresu URL nového odznáčku stavu získáte tak, že na nové stránce Builds (Buildy) vyberete akci nabídky Stavový odznáček.

Kvůli zpětné kompatibilitě budeme dál dodržovat i starší adresy URL odznáček buildu.

Přidání vlastních čítačů sestavení do sestavení

Čítače sestavení poskytují způsob, jak sestavení jednoznačně očíslovat a označovat. Dříve jste k tomu mohli použít speciální proměnnou $(rev:r). Teď můžete v definici sestavení definovat vlastní proměnné čítačů, které se automaticky navyšují při každém spuštění sestavení. Provedete to na kartě proměnných definice. Tato nová funkce poskytuje větší výkon v následujících ohledech:

• Můžete definovat vlastní čítač a nastavit jeho počáteční hodnotu. Například můžete začít na čítači 100. $(rev:r) začíná vždy hodnotou 0.
• K resetování čítače můžete použít vlastní logiku. $(rev:r) je svázaná se generováním čísla sestavení a automaticky se resetuje, kdykoli je v čísle buildu nová předpona.
• V každé definici můžete definovat více čítačů.
• Můžete zadat dotaz na hodnotu čítače mimo sestavení. Pomocí čítače můžete například spočítat počet sestavení, která se spustila od posledního resetování.

Další informace o čítačích sestavení najdete v dokumentaci k uživatelem definovaným proměnným .

Azure Policy dodržování předpisů a ověření zabezpečení v pipelines

Chceme zajistit stabilitu a zabezpečení softwaru v rané fázi procesu vývoje a zároveň chceme spojit vývoj, zabezpečení a provoz. K tomu jsme přidali podporu pro Azure Policy.

Azure Policy pomáhá zajišťovat správu a prevenci potíží s IT prostřednictvím definic zásad, které vynucují pravidla a efekty pro vaše prostředky. Když používáte Azure Policy, prostředky zůstanou v souladu s vašimi firemními standardy a smlouvami o úrovni služeb.

Abychom v rámci procesu vydávání verzí dodržovali pokyny pro dodržování předpisů a zabezpečení, vylepšili jsme prostředí pro nasazení skupiny prostředků Azure. Teď při nasazování šablon ARM dochází k selhání úlohy nasazení skupiny prostředků Azure s příslušnými chybami souvisejícími se zásadami.

Kromě toho jsme přidali Azure Policy šablonu definice vydané verze. To umožní uživatelům vytvářet zásady Azure a přiřazovat je prostředkům, předplatným nebo skupinám pro správu ze samotné definice vydané verze.

Sestavování na 32bitových platformách Linux/ARM a Windows

Agent Azure Pipelines open source pro různé platformy byl vždy podporován v 64bitových (x64) systémech Windows, macOS a Linux. V této verzi zavádíme dvě nové podporované platformy: Linux/ARM a Windows/32-bit. Tyto nové platformy vám umožňují stavět na méně běžných, ale ne méně důležitých platformách, jako je Raspberry Pi, počítač s Linuxem/ARM.

Vylepšené prostředí pro testy v kanálech

Karta Testy teď nabízí moderní prostředí, které poskytuje bohaté kontextové informace o testech pro kanály. Nové prostředí poskytuje zobrazení probíhajícího testu, možnosti ladění na celou stránku, historii kontextových testů, hlášení přerušeného spuštění testu a souhrn na úrovni spuštění.

Zobrazení provádění probíhajících testů

Testy, jako jsou testy integrace a funkční testy, můžou běžet dlouhou dobu, takže je důležité, aby se testy spouštěly v jakémkoli okamžiku. V zobrazení In-Progress test už nemusíte čekat na dokončení provádění testu, abyste poznali výsledek testu. Výsledky jsou během spuštění dostupné téměř v reálném čase, což vám pomůže rychleji provádět akce. Můžete ladit selhání nebo přerušit, vytvořit chybu nebo přerušit kanál. Tato funkce je v současné době dostupná pro kanál buildu i verze pomocí testovací úlohy VS ve fázi více agentů, pomocí úlohy Publikovat výsledky testu nebo publikování výsledků testu pomocí rozhraní API. V budoucnu plánujeme toto prostředí rozšířit o spouštění testů pomocí jednoho agenta.

Následující zobrazení ukazuje souhrn In-Progress testu v zobrazení průběhu nové verze, kde se zobrazuje celkový počet testů a počet selhání testů v daném časovém okamžiku.

Kliknutím na souhrn testu In-Progress výše můžete zobrazit podrobný souhrn testu spolu s informacemi o neúspěšném nebo přerušeném testu v Test Plans. Souhrn testu se aktualizuje v pravidelných intervalech s možností aktualizovat zobrazení podrobností na vyžádání v závislosti na dostupnosti nových výsledků.

Zobrazení podrobností ladění testovacího spuštění na celé stránce

Chybové zprávy a trasování zásobníku jsou ze své podstaty zdlouhavé a potřebují dostatek informací k zobrazení podrobností během ladění. Pokud chcete mít imerzivní prostředí ladění, můžete nyní rozšířit zobrazení testovacího nebo testovacího běhu na zobrazení na celou stránku a stále můžete provádět požadované kontextové operace, jako je vytvoření chyby nebo přidružení požadavků pro aktuální výsledek testu.

Zobrazení historie testů v kontextu

V minulosti musely týmy přejít do centra Spuštění , aby si zobrazily historii výsledků testu. S novým prostředím přinášíme historii testů přímo v kontextu na kartě Test Plans pro sestavení a vydání. Informace o historii testů jsou poskytovány progresivním způsobem, počínaje aktuální definicí sestavení nebo prostředím pro vybraný test, po kterém následují další větve a prostředí pro sestavení a verzi.

Zobrazení přerušených testů

Provádění testu může být přerušeno z několika důvodů, jako je chybný testovací kód, testový zdroj nebo problémy s prostředím. Bez ohledu na důvod přerušení je důležité diagnostikovat chování a identifikovat původní příčinu. Nyní můžete zobrazit přerušené testy a testovací běhy společně s dokončenými spuštěními v Test Plans. Tato funkce je aktuálně dostupná pro kanál buildu i verze pomocí testovací úlohy VS ve fázi více agentů nebo publikování výsledků testu pomocí rozhraní API. V budoucnu plánujeme toto prostředí rozšířit o spouštění testů pomocí jednoho agenta.

Podpora prostředí sledovatelnosti testů a vydaných verzí v historii testů

Přidáváme podporu pro zobrazení historie automatizovaného testu seskupených podle různých vydaných prostředí, ve kterých se test spouští. Pokud modelujete prostředí verzí jako kanály verzí nebo testovací prostředí a spouštíte testy napříč těmito prostředími, můžete zjistit, jestli test ve vývojovém prostředí projde, ale v prostředí integrace selže. Můžete zjistit, jestli předává anglické národní prostředí, ale selhává v prostředí, které má turecké národní prostředí. Pro každé prostředí najdete stav nejnovějšího výsledku testu, a pokud test v daném prostředí selhal, najdete také verzi, od které test selhal.

Kontrola souhrnných výsledků testů

Během provádění testu může test vytvořit více instancí testů, které přispívají k celkovému výsledku. Mezi příklady patří: testy, které se znovu spustí kvůli selháním, testy složené z seřazené kombinace jiných testů (např. seřazený test) nebo testy s různými instancemi na základě zadaného vstupního parametru (testy řízené daty). Vzhledem k tomu, že tyto testy spolu souvisejí, musí být hlášeny společně s celkovým výsledkem odvozeným na základě výsledků jednotlivých testů. V této aktualizaci zavádíme vylepšenou verzi výsledků testů, které se zobrazují jako hierarchie na kartě Testy ve vydané verzi. Podívejme se na příklad.

Dříve jsme v úloze VS Test zavedli možnost opětovného spuštění neúspěšných testů. Nahlásili jsme ale pouze poslední pokus testu, který poněkud omezil užitečnost této funkce. Tuto funkci jsme teď rozšířili tak, aby hlásila každou instanci spuštění testu jako pokus. Rozhraní API pro správu testů teď navíc podporuje možnost publikovat a dotazovat se na výsledky hierarchických testů. Další informace najdete v dokumentaci k rozhraní API výsledků testů .

Poznámka

Metriky v části souhrnu testu (např. celkový počet testů, úspěšné atd.) se počítají pomocí kořenové úrovně hierarchie, nikoli pomocí jednotlivých iterací testů.

Zobrazení testovací analýzy v pipelines

Sledování kvality testů v průběhu času a zlepšování doprovodu testů je klíčem k zachování dobrého kanálu. Funkce analýzy testů poskytuje téměř v reálném čase přehled o testovacích datech pro buildy a kanály verzí. Pomáhá zlepšit efektivitu kanálu tím, že identifikuje opakující se problémy s kvalitou s vysokým dopadem.

Výsledky testů můžete seskupit podle různých prvků, identifikovat klíčové testy pro vaši větev nebo testovací soubory nebo přejít k podrobnostem konkrétního testu, abyste viděli trendy a porozuměli problémům s kvalitou, jako je přehlednost.

Podívejte se na testovací analýzy buildů a vydaných verzí, které jsou ve verzi Preview:

Další informace najdete v naší dokumentaci.

Zjednodušení definic pomocí několika úloh bez agentů

Úlohy ve fázi bez agentů se orchestrují pomocí nástroje a provádějí se na serveru. Fáze bez agenta nevyžadují agenta ani žádné cílové počítače. Na rozdíl od fází agenta bylo možné do každé fáze bez agenta v definicích přidat pouze jednu úlohu. To znamená, že bylo potřeba přidat několik fází, když v procesu bylo více než jedna úloha bez agenta, takže definice byla objemná. Toto omezení jsme uvolnili, což umožňuje udržovat více úloh ve fázích bez agentů. Úlohy ve stejné fázi by se spouštěly postupně, stejně jako u fází agenta. Další informace najdete v dokumentaci k fázím serveru .

Postupné zveřejnění a fáze nasazení pomocí bran vydaných verzí

Pomocí bran vydaných verzí můžete zadat kritéria stavu aplikace, která musí být splněna před povýšení verze do dalšího prostředí. Všechny zadané brány se pravidelně vyhodnocují před nebo po nasazení, dokud nebudou všechny úspěšné. K dispozici jsou čtyři typy bran a další brány můžete přidat z Marketplace. Budete moct auditovat splnění všech nezbytných kritérií pro nasazení. Další informace najdete v dokumentaci ověřování vydané verze.

Blokování nasazení, dokud brány nebudou konzistentně úspěšné

Brány vydaných verzí umožňují automatické vyhodnocení kritérií stavu před povýšení vydané verze do dalšího prostředí. Ve výchozím nastavení vydání pokračuje po přijetí jedné úspěšné ukázky pro všechny brány. I když je brána chybná a úspěšný přijatý vzorek je šum, uvolnění pokračuje. Pokud se chcete těmto typům problémů vyhnout, můžete teď nakonfigurovat verzi tak, aby před jejich průběhem ověřila konzistenci stavu po minimální dobu trvání. Za běhu by vydání zajistilo úspěšné po sobě jdoucí vyhodnocení bran před povolením povýšení. Celková doba vyhodnocení závisí na "době mezi vyhodnocením" a obvykle by byla delší než nakonfigurovaná minimální doba trvání. Další informace najdete v dokumentaci k řízení nasazení verzí pomocí bran .

Automatické nasazení do nových cílů ve skupině nasazení

Dříve se při přidání nových cílů do skupiny nasazení vyžadovalo ruční nasazení, aby se zajistilo, že všechny cíle budou mít stejnou verzi. Teď můžete prostředí nakonfigurovat tak, aby se poslední úspěšná verze automaticky nasadí do nových cílů. Další informace najdete v dokumentaci ke skupinám nasazení .

Průběžné nasazování buildů označených zpracováním po sestavení

Triggery průběžného nasazování vytvářejí vydání po dokončení sestavení. Někdy se ale sestavení zpracují až po zpracování a mělo by se vydat až po dokončení zpracování. Teď můžete využít značky sestavení, které by se přiřadily během následného zpracování ve filtrech aktivační události vydané verze.

Nastavení proměnné v době vydání

V definici vydané verze teď můžete zvolit proměnné, které chcete nastavit při vytváření vydané verze.

Hodnota zadaná pro proměnnou při vytvoření verze se použije pouze pro danou verzi. Tato funkce vám pomůže vyhnout se několika krokům pro vytvoření v konceptu, aktualizovat proměnné v konceptu a aktivovat vydání s proměnnou .

Předávání proměnných prostředí úlohám

Autoři úloh CI/CD můžou v souboru task.json nastavit novou vlastnost showEnvironmentVariables, která předá úkolům proměnné prostředí. Když to uděláte, vykreslí se pro úlohu v editoru sestavení další ovládací prvek. To je k dispozici pro úlohy PowerShellu, Cmd a Bash .

To umožňuje dva scénáře:

• Úloha vyžaduje proměnnou prostředí se zachováním velkých a malých písmen v názvu proměnné. Například ve výše uvedeném příkladu by proměnná prostředí předaná úloze byla "foo" a ne "FOO".
• Umožňuje bezpečné předávání hodnot tajných kódů skriptům. To se upřednostňuje před předáním tajných kódů jako argumentů skriptům, protože operační systém v agentovi může protokolovat vyvolání procesů včetně jejich argumentů.

Klonování skupin proměnných

Přidali jsme podporu klonování skupin proměnných. Kdykoli chcete replikovat skupinu proměnných a jenom aktualizovat několik proměnných, nemusíte procházet zdlouhavým procesem přidávání proměnných jednu po druhé. Teď můžete rychle vytvořit kopii skupiny proměnných, odpovídajícím způsobem hodnoty aktualizovat a uložit ji jako novou skupinu proměnných.

Poznámka

Hodnoty tajných proměnných se při klonování skupiny proměnných nezkopírují. Musíte aktualizovat šifrované proměnné a pak naklonovanou skupinu proměnných uložit.

Ignorování brány vydané verze pro nasazení

Brány vydaných verzí umožňují automatické vyhodnocení kritérií stavu před povýšení vydané verze do dalšího prostředí. Ve výchozím nastavení kanál verze postupuje pouze v případě, že jsou všechny brány ve stejnou dobu v pořádku. V určitých situacích, například při urychlení vydané verze nebo po ruční kontrole stavu, může schvalovatel chtít ignorovat bránu a povolit, aby vydání postupovalo, i když se tato brána ještě vyhodnotí jako v pořádku. Další informace najdete v dokumentaci k branám vydaných verzí .

Provedení dalšího testování pomocí triggeru vydání žádosti o přijetí změn

Byli jste schopni aktivovat sestavení na základě žádosti o přijetí změn (PR) a tuto rychlou zpětnou vazbu získat před sloučením na chvíli. Teď můžete nakonfigurovat trigger žádosti o přijetí změn i pro vydání verze. Stav vydané verze se publikuje zpátky do úložiště kódu a můžete ho vidět přímo na stránce žádosti o přijetí změn. To je užitečné, pokud chcete v rámci pracovního postupu žádosti o přijetí změn provést další funkční nebo ruční testování.

Vytvoření připojení služby Azure pomocí instančního objektu, který se ověřuje pomocí certifikátu

Teď můžete definovat připojení služby Azure s instančním objektem a certifikátem pro ověřování. Připojení služby Azure teď podporuje instanční objekt, který se ověřuje pomocí certifikátu, a můžete ho nasadit do služby Azure Stack s nakonfigurovanou službou AD FS. Pokud chcete vytvořit instanční objekt s ověřováním certifikátu, přečtěte si článek věnovaný vytvoření instančního objektu, který se ověřuje pomocí certifikátu.

Spuštění z balíčku podporovaného v nasazeních Azure App Service

Verze úlohy Azure App Service Deploy (4.*) teď podporuje runFromPackage (dříve označovanou jako RunFromZip).

App Service podporuje řadu různých technik nasazení souborů, jako jsou msdeploy (neboli WebDeploy), git, ARM a další. Ale všechny tyto techniky mají omezení. Vaše soubory se nasadí do složky wwwroot (konkrétně d:\home\site\wwwroot) a modul runtime pak spustí soubory z této složky.

Při použití příkazu Spustit z balíčku už neexistuje krok nasazení, který zkopíruje jednotlivé soubory do souboru wwwroot. Místo toho stačí nasměrovat soubor ZIP a soubor ZIP se připojí k souboru wwwroot jako systém souborů jen pro čtení. To má několik výhod:

• Snižuje riziko problémů s uzamčením kopírování souborů.
• Dá se nasadit do produkční aplikace (s restartováním).
• Můžete si být jistí, které soubory jsou ve vaší aplikaci spuštěné.
• Zlepšuje výkon nasazení Azure App Service.
• Může zkrátit časy studeného spuštění, zejména u javascriptových funkcí s velkými stromy balíčků npm.

Nasazení kontejnerů Linuxu pomocí úlohy Nasazení aplikačního serveru

Verze 4.* úlohy nasazení Azure App Service teď podporuje nasazení vlastního kontejneru do Azure Functions v Linuxu.

Linuxový model hostování pro Azure Functions je založený na kontejnerech Dockeru, které přinášejí větší flexibilitu z hlediska balení a využití závislostí specifických pro aplikace. Funkce v Linuxu je možné hostovat ve 2 různých režimech:

1. Integrovaná image kontejneru: Přinášíte kód aplikace funkcí a Azure poskytuje a spravuje kontejner (integrovaný režim image), takže se nevyžadují žádné konkrétní znalosti související s Dockerem. To je podporováno v existující verzi úlohy nasazení App Service.
2. Vlastní image kontejneru: Vylepšili jsme úlohu App Service Deploy (Nasadit), která podporuje nasazování vlastních imagí kontejnerů do Azure Functions v Linuxu. Pokud vaše funkce vyžadují konkrétní verzi jazyka nebo konkrétní závislost nebo konfiguraci, které nejsou k dispozici v integrované imagi, můžete pomocí Azure Pipelines vytvořit a nasadit vlastní image do funkce Azure Functions v Linuxu.

Úloha Xcode podporuje nově vydané Xcode 10.

V souladu s vydáním Xcode 10 od Společnosti Apple teď můžete nastavit své projekty tak, aby se sestavovaly nebo byly testovány konkrétně pomocí Xcode 10. Váš kanál může také spouštět úlohy paralelně s maticí verzí Xcode. Ke spouštění těchto sestavení můžete použít fond agentů macOS hostovaný Microsoftem. Projděte si doprovodné materiály k používání Xcode v Azure Pipelines.

Zjednodušení nasazení do Kubernetes pomocí Helmu

Helm je nástroj, který zjednodušuje instalaci a správu aplikací Kubernetes. V posledním roce získala také velkou popularitu a podporu komunity. Úloha Helm ve verzi Release je teď k dispozici pro balení a nasazení chartů Helm do Azure Container Service (AKS) nebo jakéhokoli jiného clusteru Kubernetes.

S přidáním této úlohy Helm teď můžete nastavit kanál CI/CD založený na Helmu pro doručování kontejnerů do clusteru Kubernetes. Další informace najdete v dokumentaci k nasazení pomocí Kubernetes do Azure Container Service .

Control Helm version used in Release

Úloha instalačního programu nástrojů Helm získá konkrétní verzi Nástroje Helm z internetu nebo mezipaměti nástrojů a přidá ji do cesty agenta (hostovaného nebo privátního). Pomocí této úlohy můžete změnit verzi Helmu použitou v následných úlohách, jako je úloha .NET Core cli . Přidáním této úlohy před úlohu Helm Deploy v definici sestavení nebo verze zajistíte, že aplikaci zabalíte a nasadíte se správnou verzí Helm. Tato úloha také pomáhá s volitelnou instalací nástroje kubectl , který je předpokladem pro fungování Nástroje Helm.

Průběžné nasazování do Azure Database for MySQL

Teď můžete průběžně nasazovat do Azure Database for MySQL – databáze MySQL v Azure jako služba. Spravujte soubory skriptů MySQL ve správě verzí a průběžně je nasazujte jako součást kanálu verze pomocí nativní úlohy místo skriptů PowerShellu.

Použití vylepšených vzdálených úloh windows založených na PowerShellu

K dispozici jsou nové a vylepšené úlohy založené na vzdáleném Prostředí PowerShell pro Windows. Tato vylepšení zahrnují několik oprav výkonu a podporují živé protokoly a výstupní příkazy konzoly, jako jsou Write-Host a Write-Output.

PowerShell v cílové úloze (verze: 3.*): Můžete přidat vložený skript, upravit možnosti PSSession, řídit "ErrorActionPreference" a selhat při standardní chybě.

Úloha Kopírování souborů Azure (verze: 2.*): Dodává se s nejnovějším nástrojem AzCopy (v7.1.0), který řeší problém na GitHubu.

Filtrování větví pro GitHub Enterprise nebo externí artefakty Gitu

Při vydávání z GitHubu Enterprise nebo externích úložišť Git teď můžete nakonfigurovat konkrétní větve, které budou vydány. Můžete například chtít nasadit do produkčního prostředí pouze buildy přicházející z konkrétní větve.

Vytváření aplikací napsaných v Go

Pomocí úlohy Instalační program nástroje Go můžete průběžně instalovat jednu nebo více verzí nástroje Go Tool. Tato úloha získá konkrétní verzi nástroje Go, kterou váš projekt potřebuje, a přidá ji do cesty agenta sestavení. Pokud už je cílová verze nástroje Go v agentu nainstalovaná, přeskočí tato úloha proces jeho stažení a opětovné instalace.

Úloha Go vám pomůže stáhnout závislosti, sestavit nebo otestovat aplikaci. Tuto úlohu můžete také použít ke spuštění vlastního příkazu Go podle vašeho výběru.

Spouštění vložených nebo souborových skriptů Pythonu v kanálu

Nová úloha skriptu Pythonu zjednodušuje spouštění skriptů Pythonu v kanálu. Úloha spustí skript ze souboru Pythonu (.py) ve vašem úložišti nebo ho můžete ručně zadat do nastavení úlohy a uložit ho jako součást kanálu. Úloha bude používat verzi Pythonu v cestě nebo můžete zadat absolutní cestu k interpretu Pythonu, který se má použít.

Využití vylepšeného výstupu sestavení a testování Xcode z xcpretty

xcpretty zlepšuje čitelnost výstupu xcodebuild a generuje výsledky testů ve formátu JUnit. Úloha sestavení Xcode teď automaticky používá xcpretty, pokud je k dispozici na počítači agenta, protože je na hostovaných agentech macOS. I když výstup xcpretty může být jiný a méně podrobný než výstup xcodebuild, s každým sestavením zpřístupníme úplné protokoly xcodebuild.

Test Plans

Klient Test Runner (Azure Test Plans) pro spouštění ručních testů desktopových aplikací

Pomocí klienta Test Runner (Azure Test Plans) teď můžete spouštět ruční testy desktopových aplikací. To vám pomůže přejít z Microsoft Test Manageru na Azure Test Plans. Projděte si naše doprovodné materiály tady. Pomocí klienta Test Runner můžete spustit ruční testy a zaznamenat výsledky testů pro každý krok testu. Máte také možnosti shromažďování dat, jako je snímek obrazovky, obrazový protokol akcí a záznam zvukového videa. Pokud při testování zjistíte problém, použijte Test Runner k vytvoření chyby s testovacími kroky, snímky obrazovky a komentáři, které jsou automaticky součástí chyby.

Test Runner (Azure Test Plans) vyžaduje jednorázové stažení a instalaci runneru. Vyberte Spustit pro desktopovou aplikaci , jak je znázorněno níže.

Artifacts

Upstreamové zdroje

Azure DevOps Server 2019 přináší významné aktualizace upstreamových zdrojů dostupných v informačních kanálech Azure Artifacts:

• Do existujících informačních kanálů vytvořených v předchozích verzích TFS můžete přidat nuget.org nadřazené zdroje. Podívejte se na banner nad balíčky informačního kanálu, kde najdete další informace, včetně změn chování, o které byste měli vědět před upgradem.
• Další informační kanály Azure DevOps Server můžete do svého kanálu přidat jako nadřazené zdroje, což znamená, že můžete používat balíčky NuGet a npm z těchto informačních kanálů prostřednictvím informačního kanálu.

Zavedli jsme také novou roli v Azure Artifacts: "Spolupracovník". Spolupracovník může ukládat balíčky z nadřazeného zdroje, ale nemůže balíčky publikovat přímo do informačního kanálu (například pomocí publikování nuget). To vám umožní omezit publikování balíčků pro důvěryhodného uživatele nebo sestavovací systém a současně umožnit technikům používat nové balíčky z vašich upstreamových zdrojů.

Sledování balíčků

Zjednodušili jsme nastavení oznámení pomocí nového tlačítka Sledovat přímo na každém balíčku. Tlačítko Sledovat je také kompatibilní se zobrazeními vydaných verzí. Pokud sledujete balíček a díváte se na něj prostřednictvím zobrazení, budete dostávat aktualizace jenom pro nové verze, které jsou povýšené na toto zobrazení.

Změna nastavení informačního kanálu bez nutnosti ručního ukládání

Vylepšili jsme několik interakcí na stránce nastavení informačního kanálu. Změny, které uděláte, například přidání upstreamu nebo oprávnění, se uloží okamžitě. To znamená, že se nemusíte starat o ztrátu změn při přepínání mezi pivoty nastavení.

Zjednodušení ověřování pomocí nového meziplatformového poskytovatele přihlašovacích údajů pro NuGet

Interakce s ověřenými informačními kanály NuGet je teď mnohem lepší. Nový zprostředkovatel přihlašovacích údajů Azure Artifacts založený na .NET Core funguje s nástroji msbuild, dotnet a nuget(.exe) ve Windows, macOS a Linuxu. Kdykoli budete chtít použít balíčky z informačního kanálu Azure Artifacts, poskytovatel přihlašovacích údajů automaticky získá a uloží token jménem klienta NuGet, kterého používáte. Token už nemusíte ručně ukládat a spravovat v konfiguračním souboru.

Pokud chcete získat nového poskytovatele, přejděte na GitHub a postupujte podle pokynů pro vašeho klienta a platformu.

Komprese symbolů při publikování do sdílené složky

Aktualizovali jsme úlohu Index & Publikovat symboly tak, aby podporovala komprimaci symbolů při jejich publikování do sdílené složky.

Wiki

Publikování souborů Markdownu z úložiště Git jako wikiwebu

Vývojáři v úložištích kódu vytvářejí dokumentaci pro rozhraní API, sady SDK a nápovědu k vysvětlení kódu. Čtenáři pak musí projít kód, aby našli správnou dokumentaci. Teď můžete jednoduše publikovat soubory markdownu z úložišť kódu a hostovat je ve Wiki.

Ve Wiki začněte kliknutím na Publikovat kód jako wiki. V dalším kroku můžete zadat složku v úložišti Git, která se má zvýšit.

Jakmile kliknete na Publikovat, budou všechny soubory Markdownu ve vybrané složce publikovány jako wikiweb. Tím se také namapuje hlava větve na wikiweb, aby se všechny změny provedené v úložišti Git okamžitě projevily.

Další informace najdete v blogovém příspěvku v dokumentaci k produktu .

Odkaz na nadpisy na stránce

Teď můžete kliknout na ikonu odkazu vedle záhlaví libovolného oddílu na stránce wikiwebu a vygenerovat adresu URL přímo do tohoto oddílu. Tuto adresu URL pak můžete zkopírovat a nasdílet ji členům týmu a propojit je přímo s daným oddílem.

Připojení souborů a obrázků do složek

Při úpravách stránek wikiwebu offline může být jednodušší přidat přílohy souborů a obrázky do stejného adresáře jako stránka wikiwebu. Teď můžete přidat přílohu nebo obrázek do libovolné složky wikiwebu a propojit je se stránkou.

Vložení videa na wiki

Teď můžete na stránku wikiwebu vkládat videa z online služby, jako jsou Microsoft Stream a YouTube. Adresu URL vloženého videa můžete přidat pomocí následující syntaxe:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Přejmenování wiki

Teď můžete wikiweb přejmenovat v uživatelském rozhraní wikiwebu a pomocí rozhraní REST API. V nabídce Další klikněte na Přejmenovat wiki a dejte wikiwebu zapamatovatelný název.

Otevřít stránku na nové kartě

Teď můžete kliknout pravým tlačítkem na stránku wikiwebu a otevřít ji na nové kartě nebo ji jednoduše otevřít na nové kartě stisknutím ctrl + kliknutí levým tlačítkem myši na stránce wikiwebu.

Zachování speciálních znaků v názvech stránek wikiwebu

Teď můžete vytvářet stránky wikiwebu se speciálními znaky, například : < > * ? | -. Teď stránky s názvy jako "Časté otázky?" nebo "Průvodce nastavením" lze vytvořit na Wiki. Následující znaky se přeloží do řetězců s kódováním UTF-8:

Znak	Kódovaný řetězec
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Zobrazení nefunkčních odkazů

Všechny odkazy na wikiwebu, které nejsou propojené správně, se zobrazí ve výrazné červené barvě a v poškozené ikoně odkazu, což vám poskytne vizuální povědomí o všech nefunkčních odkazech na stránce wikiwebu.

Oprava nefunkčních odkazů při přesouvání stránek

Nefunkční odkazy na stránky jsou jednou z hlavních příčin špatné kvality stránky v jakémkoli řešení dokumentace. Když jste dříve na wikiwebu přesunuli stránku ve stromové struktuře nebo ji přejmenovali, mohlo by dojít k přerušení odkazů na stránku z jiných stránek a pracovních položek. Teď můžete vyhledat a opravit odkazy dříve, než se přeruší.

Důležité

Nezapomeňte použít syntaxi markdownu []() pro odkazy na stránkách a typ odkazu na stránku wikiwebu v pracovních položkách, aby wikiweb mohl tyto potenciálně poškozené odkazy najít a opravit. Adresy URL a hypertextové odkazy ve formátu prostého textu v pracovních položkách nebudou touto funkcí převzaty.

Při přejmenování nebo přesunutí stránky se zobrazí výzva ke kontrole ovlivněných absolutních nebo relativních odkazů.

Před provedením akce se vám pak zobrazí seznam ovlivněných odkazů na stránku a pracovních položek .

Vytvoření obsahu pro stránky wikiwebu

Někdy můžou být stránky wikiwebu dlouhé a obsah je uspořádaný do několika nadpisů. Teď můžete pomocí [[_TOC_]] syntaxe přidat obsah na libovolnou stránku, která má alespoň jeden nadpis.

Obsah můžete také vložit kliknutím na příslušné tlačítko v podokně formátu při úpravách stránky.

Další informace o používání Markdownu v Azure DevOps najdete v dokumentaci s pokyny k Markdownu .

Metadata surface pro stránky wikiwebu a náhled kódu pomocí značek YAML

Přidání metadat do dokumentace může čtenářům a indexům vyhledávání pomoct získat a zobrazit smysluplný obsah. V této aktualizaci se všechny soubory, které obsahují blok YAML na začátku souboru, transformují na tabulku metadat s jedním záhlavím a jedním řádkem. Blok YAML musí mít podobu platné sady YAML mezi trojitými přerušovanými čárami. Podporuje všechny základní datové typy, seznam, objekt jako hodnotu. Syntaxe je podporovaná ve wikiwebu a náhledu souboru kódu.

Příklad značek YAML:

---
tag: post
title: Hello world
---

Příklad značek YAML se seznamem:

---
tags:
- post
- code
- web
title: Hello world
---

Publikování kódu jako wikiwebu s oprávněními k přispívání

Dříve mohli jako wiki publikovat kód jenom uživatelé s oprávněním k vytvoření úložiště Git. Správci nebo tvůrci úložiště tak vytvořili kritický bod pro všechny požadavky na publikování souborů Markdownu hostovaných v úložištích Git jako wikiwebů. Teď můžete publikovat kód jako wikiweb , pokud máte jenom oprávnění k přispívání v úložišti kódu.

Generování sestav

Teď je k dispozici rozšíření Analytics Marketplace pro vytváření sestav.

Rozšíření Analytics Marketplace je teď k dispozici pro Azure DevOps Server. Analýza představuje budoucnost generování sestav pro Azure DevOps a Azure DevOps Server. Instalace rozšíření Analytics poskytuje pokročilé widgety, integraci Power BI a přístup k datům OData.

Další informace najdete v tématu Co je analýza a Přehled sestav. Analýza je ve verzi Public Preview. V současné době obsahuje data pro panely a výsledky automatizovaných testů prostřednictvím kanálů. Viz Data dostupná ve službě Analytics.

Prozkoumání historie sestavení pomocí nového widgetu řídicího panelu sestavení

Máme nový a vylepšený widget historie sestavení, který můžete přidat na řídicí panely. Pomocí tohoto widgetu teď můžete zobrazit historii buildů z konkrétní větve na řídicím panelu a nakonfigurovat ji ve veřejném projektu pro anonymní návštěvníky.

Důležité

Pokud hledáte přehledy o buildech XAML, pokračujte v používání staršího widgetu a přečtěte si o migraci ze sestavení XAML na nová sestavení. V opačném případě doporučujeme přejít na novější widget.

---

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