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

| Licenční podmínky licenčních podmínek | pro požadavky na | systém vývojářů DevOps Blog | SHA-1

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

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

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

---

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

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

Azure DevOps Server 2020 zpracovává uchovávání sestavení odlišně na základě zásad uchovávání na úrovni kanálu. Některé konfigurace zásad vedou k odstranění spuštění kanálu po upgradu. Po upgradu se neodstraní spuštění kanálu, která byla ručně zachována nebo jsou zachovaná verzí.

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

Datum vydání 16 opravy Azure DevOps Serveru 2019.0.1: 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 ověření parametrů argumentů Povolit úlohy prostředí.

Poznámka:

Pokud chcete implementovat opravy této opravy, budete muset ručně aktualizovat úlohy pomocí řady kroků.

Instalace oprav

Důležité

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

Soubor	Hodnota hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Požadavky na kanál

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

• V klasickém prostředí:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Datum vydání 15 opravy Azure DevOps Serveru 2019.0.1: 12. září 2023

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

• CVE-2023-33136: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu serveru Azure DevOps
• CVE-2023-38155: Ohrožení zabezpečení spočívající ve zvýšení oprávnění serveru Azure DevOps a Team Foundation Serveru

Důležité

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

Poznámka:

Pokud chcete implementovat opravy této opravy, budete muset ručně aktualizovat agenta a úlohy pomocí řady kroků.

Instalace oprav

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

Aktualizace agenta Azure Pipelines

1. Stáhnout agenta z: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. K nasazení agenta použijte kroky popsané v dokumentaci k místním agentům Windows.  

Poznámka:

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

Konfigurace TFX

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

Aktualizace úloh pomocí TFX

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

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

Požadavky na kanál

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

• V klasickém prostředí:

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

• Příklad YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Datum vydání 14 opravy Azure DevOps Serveru 2019.0.1: 8. srpna 2022

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

• CVE-2023-36869: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps

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

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

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

Datum vydání 12 opravy Azure DevOps Serveru 2019.0.1: 26. ledna 2022

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

• Vyřešili jsme chybu zabezpečení Elasticsearch odebráním třídy jndilookup z binárních souborů log4j.

Instalační kroky

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

Poznámka:

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

1. Upgradujte server pomocí opravy 12.
2. Zkontrolujte hodnotu registru na adrese HKLM:\Software\Elasticsearch\Version. Pokud tam hodnota registru není, přidejte řetězcovou hodnotu a nastavte verzi na 5.4.1 (Název = Verze, hodnota = 5.4.1).
3. Zkopírujte obsah složky s názvem zip umístěný ve C:\Program Files\{TFS Version Folder}\Search\zip vzdálené složce Elasticsearch.
4. Spusťte Configure-TFSSearch.ps1 -Operation update na počítači serveru Elasticsearch.

Hash SHA-256: 96C7AF3E3ED67C76451BA28427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Datum vydání 11 opravy Azure DevOps Serveru 2019.0.1: 10. srpna 2021

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

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

Datum vydání 10 opravy 10 Azure DevOps Serveru 2019.0.1: 13. dubna 2021

Vydali jsme opravu pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy.

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

Chcete-li použít opravu Patch 10, budete muset nainstalovat AzureResourceGroupDeploymentV2 úlohu.

Instalace úlohy AzureResourceGroupDeploymentV2

Poznámka:

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

Instalace

1. Extrahujte balíček AzureResourceGroupDeploymentV2.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 vašeho 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. Na příkazovém řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a token pat.

~$ 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 extrahovaného souboru .zip z kroku 1.

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

Datum vydání 9 opravy Azure DevOps Serveru 2019.0.1: 8. prosince 2020

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

• CVE-2020-1325: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• CVE-2020-17135: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• CVE-2020-17145: Ohrožení zabezpečení z hlediska falšování identity v Azure DevOps Serveru a Team Foundation Serveru
• Oprava problému s nezpracování všech výsledků TFVC

Důležité

Před instalací této opravy si 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 Azure DevOps Server 2019.0.1 Patch 9.

Ověření instalace

• Možnost 1: Spuštění devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe je soubor stažený z výše uvedeného odkazu. Výstup příkazu buď řekne, že byla nainstalována oprava, nebo že není nainstalovaná.

• 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ý c:\Program Files\Azure DevOps Server 2019 . Po instalaci Azure DevOps Serveru 2019.0.1 Patch 9 bude verze 17.143.30723.4 .

Instalace úlohy AzurePowerShellV4

Poznámka:

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

Požadavky

1. Nainstalujte azure PowerShell Az module Azure PowerShell na privátní počítač agenta.

2. Vytvořte kanál pomocí úlohy AzurePowerShellV4 . V úloze se zobrazí pouze jedna chyba selhání .

Instalace

1. Extrahujte balíček AzurePowerShellV4.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 vašeho 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. Na příkazovém řádku spusťte následující příkaz. Po zobrazení výzvy zadejte adresu URL služby a token pat.

~$ 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í 8 Pro Azure DevOps Server 2019.0.1 Patch 8: 8. září 2020

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy. 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 do oprávnění zabezpečení

Datum vydání 7 opravy Azure DevOps Serveru 2019.0.1: 14. července 2020

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

• CVE-2020-1326: Ohrožení zabezpečení skriptování mezi weby
• Kanál buildu zobrazuje nesprávné připojení neoprávněných uživatelů při výběru jiného zdroje Gitu.
• Opravte chybu při změně dědičnosti na Zapnuto nebo Vypnuto v definici sestavení XAML.

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

Vydali jsme opravu zabezpečení pro Azure DevOps Server 2019.0.1, která odstraňuje následující opravy. 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 SHA2 v SSH v Azure DevOps

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

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

• CVE-2020-0700: Ohrožení zabezpečení skriptování mezi weby
• CVE-2020-0758: Ohrožení zabezpečení spočívající v zvýšení oprávnění
• CVE 2020-0815: Ohrožení zabezpečení spočívající v zvýšení oprávnění

Datum vydání 3 opravy Azure DevOps Serveru 2019.0.1: 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í spočívající ve skriptování mezi weby (XSS) v úložištích
• CVE-2019-1306: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu na Wiki

---

Datum vydání 2 opravy Azure DevOps Serveru 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.

---

Datum vydání 1 opravy Azure DevOps Serveru 2019.0.1: 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í při vzdáleném spuštění kódu při sledování pracovních položek
• CVE-2019-1076: Ohrožení zabezpečení skriptování mezi weby (XSS) v žádostech o přijetí změn

---

Datum vydání Azure DevOps Serveru 2019.0.1: 21. května 2019

Azure DevOps Server 2019.0.1 představuje opravy chyb. Zahrnuje všechny opravy v dříve vydaných opravách Azure DevOps Serveru 2019. Azure DevOps Server 2019.0.1 můžete nainstalovat přímo nebo upgradovat z Azure DevOps Serveru 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 po tomto vydání. Náš seznam aktuálně podporovaných verzí pro import najdete tady.

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

Azure Boards

• "Kritéria polí pro tento plán mají chybu" při konfiguraci plánu. Nahlášeno prostřednictvím komunity vývojářů.
• Apiwitcontroller.executequery vyvolá výjimku, pokud dotaz má vícekrát stejný sloupec.
• V klientském objektovém modelu pomocí oboru vso.work_full oauth workItemServer.DownloadFile() selže.
• 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 Analýza testů má hvězdičku (*), která označuje náhled, i když tato funkce není ve verzi Preview.
• Na kartě Vydané verze se teď akce pro správu zabezpečení zobrazí všem uživatelům bez ohledu na to, jestli můžou oprávnění změnit, nebo ne.
• Na cílových stránkách Vydané verze byla akce spuštění konceptu vytvoření nové verze, ale nyní spustí koncept vydání.

Azure Test Plans

• Filtr 1 hodiny pro TestRuns a TestResults CompletedDate je příliš podrobný.
• V typu pracovní položky testovacího případu by neměl být typ Testovací případ 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 vydaných verzí v přidruženém kanálu verze. Nahlášeno prostřednictvím komunity vývojářů.
• 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 komunity vývojářů.
• Kliknutím na odkaz na pracovní položku ve Spouštěči testů se otevře adresa URL pracovní položky v nástroji Test Runner místo výchozího prohlížeče.
• 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 v rozevíracím seznamu uživatele v Test Runneru nezobrazují.

Azure Artifacts

• Přesunutí nahoru a dolů není lokalizováno v upstreamech.

Analýzy

• Analytické sestavy můžou zobrazovat neúplná data, protože model je před dokončením označený jako připravený.
• Widgety pro zrychlení, burndown a burnup zobrazují různé plánované práce pro uživatele v různých časových pásmech.
• Blokování může být umístěné na příjmu dat Analytics při údržbě, což může způsobit zastaralé sestavy.

OBECNÉ

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

Správa

• Do upgradu kolekce jsme přidali další protokolování, které pomáhá ladit problémy.
• Pokud tfsConfig offlineDetach selže, chybová zpráva není použitelná.
• Služba TfsJobAgent se chybově ukončí.
• Rozšíření vyhledávání se po dokončení konfigurace nenainstaluje.
• Konzola pro správu přestane reagovat, když je poškozena konfigurační databáze.
• Volání služeb 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 vyhledávacích stránek existují nelokalizované řetězce.

Tato verze obsahuje následující aktualizaci:

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

Do úlohy Visual Studio Test v kanálech jsme přidali podporu sady Visual Studio 2019. Pokud chcete spouštět testy pomocí testovací platformy pro Visual Studio 2019, vyberte v rozevíracím seznamu Verze testovací platformy nejnovější nebo Visual Studio 2019 .

---

Datum vydání 2 opravy Azure DevOps Serveru 2019: 14. května 2019

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

• CVE-2019-0872: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v testovacích plánech
• CVE-2019-0971: Ohrožení zabezpečení spočívající ve zpřístupnění informací v rozhraní API pro úložiště
• CVE-2019-0979: Ohrožení zabezpečení skriptování mezi weby (XSS) v Centru uživatelů

---

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

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

• CVE-2019-0857: Ohrožení zabezpečení z hlediska falšování identity na wikiwebu
• CVE-2019-0866: Ohrožení zabezpečení spočívající v možnosti vzdáleného spuštění kódu v Pipelines
• CVE-2019-0867: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v Pipelines
• CVE-2019-0868: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v Pipelines
• CVE-2019-0869: Ohrožení zabezpečení injektáže HTML v Pipelines
• CVE-2019-0870: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v Pipelines
• CVE-2019-0871: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v Pipelines
• CVE-2019-0874: Ohrožení zabezpečení spočívající ve skriptování mezi weby (XSS) v Pipelines
• CVE-2019-0875: Ohrožení zabezpečení spočívající v zvýšení oprávnění v panelech

---

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

Poznámka:

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

---

Datum vydání RC2: 22. ledna 2019

Shrnutí novinek v Azure DevOps Serveru 2019 RC2

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

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

---

Datum vydání RC1: 19. listopadu 2018

Shrnutí novinek v Azure DevOps Serveru 2019 RC1

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

• Nové navigační prostředí
• Rozšíření Analytics Marketplace pro vytváření sestav je teď k dispozici.
• Podpora služby Azure SQL Database
• Dědičnost procesů u nových kolekcí
• Centrum Nové pracovní položky
• Nové panely, backlogy a centra Sprints
• 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ů buildu pomocí nové stránky Builds (Builds)
• Správa kanálů verzí pomocí nové stránky Vydaných verzí
• Vizualizace průběhu vydávání verzí
• Místní aktualizace agenta
• Progresivní 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é části a podívat se na nové funkce:

• Obecné
• Panely
• Repos
• Pipelines
• Testovací plány
• Artefakty
• Wiki
• Sestavy

---

OBECNÉ

Oznámení Azure DevOps Serveru

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 pro modernizaci uživatelského prostředí. Tato nová navigace se zavedla do služby Azure DevOps a je teď dostupná v Azure DevOps Serveru 2019. Další informace najdete na našem blogu .

Změny licencování kanálu nasazení Artifacts a Release Management

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

Podpora služby Azure SQL Database

Abychom zjednodušili spouštění Azure DevOps 2019 v Azure, povolili jsme podporu pro 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 při provozování služby. Mějte na paměti, že virtuální počítač hostitele musí být umístěný ve stejné oblasti Azure jako vaše databáze, aby byla latence nízká. Další informace najdete v dokumentaci.

Pracovní položka a testování rozhraní API SOAP klientského objektového modelu v budoucích verzích

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

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

Dědičnost procesů je nyní k dispozici v nových kolekcích. Uživatelé budou muset při vytváření nové kolekce rozhodnout o modelu procesu. Podívejte se na naši dokumentaci k tomu, co je model dědičnosti a jak se liší od XML.

Rozbalené vyhledávací pole

Chápeme důležitost hledání a vracíme rozšířené vyhledávací pole v záhlaví produktu. Kromě toho teď můžete vyhledávací pole vyvolat 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:

Informační nabídka Moje práce

Nová funkce, kterou jsme velmi rádi představili, je můj informační kanál práce. Slyšeli jsme zpětnou vazbu, že když jste v jedné části produktu a chcete nějaké informace z jiné části, nechcete svůj kontext ztratit. Díky této nové funkci budete mít k tomuto informačnímu rámečku přístup odkudkoli v produktu. Díky tomu budete mít 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 se v tomto novém informačním rámečku nacházíte v Repos , v kódu se dostanete dolů, ale pak chcete rychle zkontrolovat, na které pracovní položce byste měli pracovat, můžete jednoduše kliknout na rozevírací nabídku a zobrazit pracovní položky přiřazené vám a vyzvednout další položku.

Níže vidíte rozevírací seznam Moje práce s pracovními položkami přiřazenými ke mně:

Tady uvidíte druhý pivot, který zobrazuje žádosti o přijetí změn přiřazené mně. V informačním rámečku máte také jeden přístup kliknutím, abyste zobrazili více žádostí o přijetí změn:

Tady vidíte poslední pivot, který je všechno, co jste si oblínili. To zahrnuje 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 pracovními položkami Azure Boards

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 pracovní postup, který se integruje s vývojářskými pracovními postupy na 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 ve zprávě potvrzení, 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í 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 části Vývoj pracovní položky. ​

Pokud se slova "fix", "opravy" nebo "pevné" před zmínkou pracovní položky (jak je uvedeno výše), pracovní položka se přesune do dokončeného stavu při sloučení potvrzení do výchozí větve.

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

Centrum Nové pracovní položky

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 vymezeny. Pokud chcete rychle získat přehled o všech úkolech přiřazených vám nebo nedávno aktualizovaným, zobrazí se vám všechny pracovní položky v projektu, které byly naposledy aktualizovány. Všechny možnosti seznamu můžete vidět níže:

Pokud chcete omezit rozsah seznamů ještě dál, můžete filtrovat podle typu, přiřazeného, 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ý, abyste mohli zobrazit celý obsah sloupce, můžete snadno změnit velikost sloupce v oblasti záhlaví. Tato prostředí se dají zobrazit níže:

Nové panely, backlogy a centra Sprints

Centrum backlogů bylo rozděleno do tří různých center, aby se zlepšilo uživatelské prostředí. I když je staré backlogy moc výkonné, staré centrum backlogů bylo domovem příliš mnoha funkcí. To často ztěžovalo nalezení funkce nebo možností, které uživatelé hledali. Abychom tento problém vyřešili, rozdělili jsme centrum backlogů na:

• Centrum backlogů je teď domovem jenom backlogů projektu. Backlog je seznam práce pro tým podle priority. Backlogy poskytují nástroje pro plánování, jako je hierarchie pracovních položek, prognózování a nové prostředí plánování sprintů.
• Nové centrum Boards je domovem všech Kanban Boards pro projekt. Panely slouží ke komunikaci stavu a toku. Karty (pracovní položky) se přesouvají zleva doprava přes panel prostřednictvím sloupců definovaných týmem.
• Nové centrum Sprints je domovem funkcí, které slouží k plánování a provádění přírůstku práce. Každý sprint obsahuje backlog sprintu, panel úkolů 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é funkce, které usnadňují přístup k dotazům, které jsou pro vás důležité. Mezi nejdůležitější novinky patří:

• Adresářové stránky s naposledy upravenými informacemi a schopností vyhledávat dotazy
• Popis cesty s jedinečnými adresami URL pro složky pro záložky důležitých skupin dotazů
• Rychlý přístup k vašim 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 kolekci projektů. Tyto funkce vyžadují, aby byl datový sklad zakázaný. Když je datový sklad zakázaný, můžete pomocí analytické služby podporovat potřeby vytváření sestav. 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 další sprint nebo se přihlaste k odběru existujícího plánu sprintu přímo z centra Sprints .
• Pomocí nového podokna Plánování v backlogu přetáhněte pracovní položky do budoucích sprintů. Podokno Plánování obsahuje data sprintu, počty pracovních položek a plánované úsilí.
• Přidejte požadavky na začátek panelu úloh nebo použijte rychlé vytvoření a přidejte je do horního, dolního nebo libovolného řádku v backlogu sprintu.
• Pomocí filtrů pro přiřazování, typ pracovní položky, stav a značky můžete přizpůsobit zobrazení vašim potřebám.

Nové stránky adresáře

Všechna nová centra, včetně backlogů, panelů a sprintů, teď mají nové adresářové stránky uspořádané s následujícími oddíly:

• Pokračujte tam, kde jste skončili – Tento nový oddíl obsahuje rychlý odkaz přímo na poslední (Panel | Backlog | Sprint), na které jste byli.
• Oblíbené jsou všechny oblíbené panely, sprinty a backlogy napříč všemi týmy.
• Moje všechny panely, backlogy a sprinty pro týmy, do nichž patříte.
• Úplný seznam všech vašich panelů, backlogů a sprintů

Nabídka Možnosti nového 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 pro přizpůsobení rozložení a obsahu stránky. Pomocí možností zobrazení můžete povolit další zobrazení, například zobrazit hierarchii v backlogech nebo změnit možnost Seskupit podle na panelu úloh, zapnout boční panel pro mapování a plánování sprintů nebo prozkoumat grafy podrobností práce.

Další informace o těchto zajímavých aktualizacích, novém podokně profilu týmu a oblíbených najdete na našem blogu DevOps.

Poznámky karet zahrnují chyby a vlastní typy pracovních položek.

Poznámky na kartě jsou oblíbené pro intuitivní zobrazení seznamu a interakci se seznamem. Dříve byly poznámky na kartě omezené na výchozí typy na úrovni backlogu a nepodporují 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ýkoli vlastní typ pracovní položky jako poznámku karty.

Nastavení panelu pro poznámky karet bylo rozšířeno tak, aby zahrnovalo všechny typy pracovních položek dostupné pro danou úroveň backlogu.

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

Rychlé vytvář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í

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

Kromě toho jsou data iterace zahrnuta napravo od jména, abyste mohli rychle posoudit, kdy má být pracovní položka doručena.

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

Makro @CurrentIteration , které pomáhá týmu sledovat práci na základě plánu iterace, teď podporuje celočíselné posuny. Snadno udržujte přehled o práci, která se nezavřela – @CurrentIteration 1, nebo se podívejte na práci plánovanou pro budoucí iterace s @CurrentIteration + 1. Další informace najdete v příspěvku @CurrentIteration 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 Teams změ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í. Pomocí parametru Tým 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 různými názvy iterací a dokonce plány. To znamená, že už nemusíte aktualizovat dotazy, protože se sprinty mění. Další informace najdete v příspěvku @CurrentIteration na blogu Microsoft DevOps.

Práce s dotazy v oblastech cesty týmu pomocí nového @TeamAreas makra

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

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

Pomocí nového operátoru dotazu IsEmpty vyhledejte pracovní položky, které mají prázdné textové pole s prázdným formátem, 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. Selektor dotazu byl nahrazen vloženými návrhy na základě naposledy použitých pracovních položek a vstupního bodu pro hledání konkrétní pracovní položky podle ID nebo názvu.

Otevření pracovních položek z výsledků hledání

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

Repos

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

Většina prostředí v Azure Repos vyžaduje, abyste vybrali úložiště a pak větev v daném úložišti. Pro zlepšení tohoto prostředí 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řijímání 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 (žádosti o přijetí změn) a zásady větví, mohou nastává 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. Dává smysl důvěřovat vývojářům, aby udělali správnou věc a použili možnost přepsání střídmě. Týmy zároveň potřebují způsob, jak ověřit, že se tato 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 obejití zásad. Začněte vytvořením nebo aktualizací žádosti o přijetí změn a v seznamu filtrů vyberte Vynechat zásady. Výběr zásad byl vynechán jako hodnota a budete upozorněni při každém dokončení žádosti o přijetí změn a zásady se obejití.

Povolení obejití zásad větví bez nutnosti ochrany nabízených oznámení

Existuje mnoho scénářů, kdy občas potřebujete obejít zásadu 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 vynucení zásad") a pomohli týmům spravovat uživatele, kterým uživatelům byla udělena možnost obejít zásady větve při dokončování žádosti o přijetí změn. Toto oprávnění ale také udělilo možnost nasdílení změn přímo do větve a zcela obejití procesu žádosti o přijetí změn.

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

1. Při dokončování žádostí o přijetí změn zásady obejití. Uživatelé s tímto oprávněním budou moct pro žádosti o přijetí změn používat prostředí Přepsání.
2. Vynechat zásady při nabízení Uživatelé s tímto oprávněním budou moct odesílat přímo větve, které mají nakonfigurované požadované zásady.

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

Poznámka:

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

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

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

Zápis popisných zpráv potvrzení přidává hodnotu do historie libovolného úložiště Git. Aby se podpořily zprávy o potvrzení kvality, nové žádosti o přijetí změn, které mají více potvrzení, budou vyžadovat, aby přispěvatelé zadali název ručně.

Popisy žádostí o přijetí změn budou ve výchozím nastavení prázdné, ale nová funkce usnadňuje začlenění zpráv 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 potvrzovací zprávy , aby se zprávy potvrzení připojily 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ích

Při prvním spuštění prostředí žádosti o přijetí změn (PR) jsme si mysleli, že by mělo smysl přiřazovat všechny žádosti o přijetí změn do týmového kontextu, který jste vybrali při vytváření žádosti o přijetí změn. Toto chování je frustrační bod, 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 nejsou ve výchozím nastavení přidáni žádní revidujícím. 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 kontrolorů můžou také pomoct týmům, které chtějí zajistit, aby si konkrétní revidoři přidali ke kontrole kódu.
2. Centrum Žádosti o přijetí změn má nový přizpůsobitelný oddíl. Ve výchozím nastavení se v této části zobrazují žádosti o přijetí změn přiřazené mým týmům, které 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é některému z vašich týmů. Oddíl je také přizpůsobitelný – stačí kliknout na akci Přizpůsobit toto zobrazení poblíž záhlaví oddílu.

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

Psaní vhodných popisů žádostí o přijetí změn je skvělý způsob, jak revidujícím pomoct zjistit, co očekávat při kontrole kódu. Představují také skvělý způsob, jak sledovat, co je potřeba 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, abychom týmům usnadnili psaní skvělých popisů a přidali jsme tuto funkci.

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

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

Další informace o vytváření a používání šablon najdete v dokumentaci k šabloně žá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í hodnoty. Díky nové funkci, která změní cílovou větev aktivní žádosti o přijetí změn, je to teď jednoduchá akce. Stačí kliknout na ikonu tužky u názvu cílové větve v hlavičce žádosti o přijetí změn.

Kromě pouhé opravy chyb usnadňuje funkce změny cílových větví také možnost "retarget" žádosti o přijetí změn v případě, že cílová větev byla sloučena nebo odstraněna. Představte si scénář, ve kterém máte žádost o přijetí změn zaměřenou na větev funkcí, která obsahuje některé funkce, na které jsou vaše změny závislé. Chcete zkontrolovat závislé změny v izolaci od ostatních změn ve větvi funkcí, takže jste původně cílili features/new-feature. Revidujícím se pak můžou zobrazit jenom vaše změny a nechat příslušné komentáře.

Teď zvažte, co by se stalo, pokud by větev funkcí měla také aktivní žádost o přijetí změn a byla sloučena před main vašimi změnami? Dříve byste museli své změny opustit a vytvořit novou žádost o přijetí změn mainnebo žádost o přijetí změn sloučit do features/new-featurea pak vytvořit další žádost o přijetí změn.features/new-feature main S touto novou akcí, která aktualizuje cílovou větev, můžete jednoduše změnit cílovou větev žádosti o přijetí změn na features/new-feature mainzachování veškerého kontextu a komentářů. Změna cílové větve dokonce vytvoří novou aktualizaci žá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 mohou dotazovat na kontext pro aktuální ú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, například jméno, ID a adresa URL. Abychom vám s tím pomohli, přidali jsme versionControlRepositoryService jako službu přístupnou rozšířením. Pomocí tohoto postupu může autor rozšíření zadat dotaz na informace o aktuálním kontextu úložiště Git v rámci webového uživatelského rozhraní. Aktuálně 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 je služba přístupná 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ů buildu pomocí nové stránky Builds (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ů buildu a seznam aktuálních buildů, abyste mohli rychle přecházet mezi buildy projektu a zobrazit jejich stav. Zahrnuje také náhled analýzy testů pro vybraný kanál.

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

E-maily pro sestavení a dokončení nasazení byly aktualizovány tak, aby byly filtrovatelné podle e-mailových pravidel. Řádek předmětu teď na první pohled obsahuje relevantnější informace, text obsahuje více podrobností a jejich styly byly aktualizovány nejnovější značkou.

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 rámci buildů a verzí se pro podobné koncepty používaly různé termíny. V jiných případech byly významy pojmů vágní. Například sdělování rozdílu mezi fondem agentů a frontou agenta.

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

Předchozí termín	Sjednocený 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 poskytnutém a spravovaném vámi.
Fond agentů	Fond agentů	Sada počítačů agentů na úrovni organizace, které můžou spouštět sestavení nebo vydané verze.
Fronta agenta	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 sestavení	Kompletní sada kroků sestavení pro aplikaci.
Sestavení	Sestavení	Instance kanálu buildu, který je spuštěný nebo spuštěný.
Fáze	Úloha	Řada úloh, které se spouštějí postupně nebo paralelně v agentu. Kanál buildu nebo verze může obsahovat jednu úlohu nebo graf více úloh.
Definice vydané verze	Kanál verze	Kompletní sada kroků vydání pro aplikaci, která se má nasadit v různých fázích.
Verze	Verze	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, kde 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 vydání 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 vydávání.
Koncový bod služby	Připojení služby	Skupina nastavení, jako jsou přihlašovací údaje, sloužící k připojení k externím službám pro provádění úloh v sestavení nebo vydané verzi.

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

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

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

Přejděte do zobrazení složek a vytvořte složky pro organizaci a zabezpečení. Zabezpečení lze nastavit na úrovni složky.

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

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

Kanál, podrobnosti verze a prostředí

Zobrazení kanálu zobrazuje artefakty vydané verze a prostředí, ve kterých se nasadí. Oblast Vydání obsahuje podrobnosti o verzi, jako je trigger verze, verze artefaktů a značky.

Prostředí jsou modelována způsobem, který pomáhá pochopit jejich stav spolu s podrobným průběhem. Kdykoli se k protokolům dostanete kliknutím na odkaz na stav v rámci prostředí.

Před nasazením a po nasazení

Pokud jsou pro prostředí nastaveny podmínky před nasazením nebo po nasazení, je to uvedené v prostředí s přítomností schválení a bran. Průběh schvalování a bran se také zobrazuje ve stavu prostředí. Můžete provést akci nebo zobrazit další podrobnosti kliknutím na ikonu podmínky prostředí, která se předsadí z pravé nebo levé strany prostředí.

Potvrzení a pracovní položky

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

Průběh nasazení a protokoly

V prostředích se zobrazují živé aktualizace probíhajících nasazení, včetně toho, kolik fází a úkolů se dokončí, a dobu běhu. Po kliknutí na stav prostředí se otevře zobrazení obsahující protokoly a fokus na to, co je aktuálně aktivní.

Kliknutím na protokoly můžete zadat 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 testovacím centru byly v TFS 2017 RTM zastaralé . S Azure DevOps Serverem 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 PowerShellu na cílových počítačích verze 1.*. Aby vaše kanály pokračovaly v práci,

• Musíte přepnout na úlohu Kopírování souborů počítače s Windows verze 2.* a místo názvu počítače zadat úplný plně kvalifikovaný název domény pro cílový počítač.
• A přepněte na úlohu PowerShellu na cílovém počítači verze 2.* nebo novější a zadejte úplný plně kvalifikovaný název 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á do procesu přispívají.

Stávající rozšíření fungují v tomto novém zobrazení a navíc existují nové body rozšiřitelnosti, které umožňují rozšířením, aby se v prostředí mohly zobrazovat ještě více informací. 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 na vašem Serveru Azure DevOps. Automatizujte kanál kontinuální integrace pomocí souboru YAML, který je vrácený do úložiště. Kompletní referenční informace o schématu YAML najdete tady.

Aby se kanály sestavení založené na YAML snadněji podporovaly, změnili jsme výchozí chování všech nových prostředků, které vytvoříte (například připojení služeb, skupiny proměnných, fondy agentů a zabezpečené soubory), aby bylo možné použít ve všech kanálech tohoto projektu. Pokud chcete mít u prostředků přísnější kontrolu, můžete výchozí autorizační model zakázat (viz obrázek níže). Když to uděláte, uživatel s oprávněními k použití prostředku musí kanál explicitně uložit ve webovém editoru po přidání odkazu na prostředek do souboru YAML.

Zřetězování souvisejících sestavení pomocí triggerů dokončení sestavení

Velké produkty mají několik komponent, které jsou vzájemně závislé. Tyto komponenty jsou často nezávisle sestaveny. Když se například změní nadřazená komponenta (knihovna), musí se podřízené závislosti znovu vytvořit a znovu aktualizovat. Týmy obvykle tyto závislosti spravují ručně.

Teď můžete aktivovat sestavení po úspěšném dokončení jiného sestavení. Artefakty vytvořené upstreamovým sestavením je možné stáhnout a použít v pozdějším sestavení a 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 jedno vícefázové sestavení vyhovovat vašim potřebám. Aktivační událost dokončení sestavení je ale užitečná v případě, že 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 pipelines. Pokud se váš Azure DevOps Server může připojit k internetu, stáhnou se novější verze automaticky. Pokud ne, musíte ručně upgradovat každého agenta. Počínaje touto verzí můžete nakonfigurovat Azure DevOps Server tak, aby hledal soubory balíčků agentů na místním disku místo z internetu. To vám dává flexibilitu a kontrolu nad tím, jaké verze agenta zpřístupníte, aniž byste museli vystavit Azure DevOps Server na internetu.

Adresa URL nového stavu buildu

Build badges embedded into the homepage of a repository are a common way to show the health of the repository. I když jsme doteď 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 žádný způsob, jak kliknout na odznáček, aby uživatel přešel na nejnovější build této 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ší build vybrané větve. Markdown pro novou adresu URL odznáček stavu můžete získat tak, že na nové stránce Builds (Builds) vyberete akci nabídky odznáček Status (Stav).

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

Přidání vlastních čítačů k vašim sestavením

Čítače sestavení poskytují způsob, jak jedinečně očíslovat a označovat buildy. Dříve byste k tomu mohli použít speciální proměnnou $(rev:r). Teď můžete definovat vlastní proměnné čítačů v definici sestavení, 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 následujícími způsoby:

• Můžete definovat vlastní čítač a nastavit jeho počáteční hodnotu. Například můžete spustit čítač na 100. $(rev:r) vždy začíná na 0.
• K resetování čítače můžete použít vlastní logiku. $(rev:r) je svázaný s generováním čísel sestavení a při každém vytvoření nové předpony v čísle sestavení se automaticky resetuje.
• Pro každou 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živatelsky definovaným proměnným.

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

Chceme zajistit stabilitu a zabezpečení softwaru v rané fázi procesu vývoje a současně seskupovat 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í dodržovali pokyny pro dodržování předpisů a zabezpečení, vylepšili jsme naše prostředí pro nasazení skupin prostředků Azure. Teď selhává úloha nasazení skupiny prostředků Azure s příslušnými chybami souvisejícími se zásadami v případě jakýchkoli porušení při nasazování šablon ARM.

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

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

Open source, multiplatformní agent Azure Pipelines byl vždy podporován v 64bitových (x64) systémech Windows, macOS a Linux. V této verzi představujeme dvě nové podporované platformy: Linux, ARM a Windows/32bitová verze. Díky těmto novým platformám můžete 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 nebo ARM.

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

Karta Testy teď nabízí moderní prostředí, které poskytuje bohaté informace o testech v kontextu pro kanály. Nové prostředí poskytuje probíhající zobrazení testů, prostředí ladění celé stránky, v 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 integrace a funkční testy, můžou běžet dlouho, takže je důležité vidět provádění testů v jakémkoli okamžiku. V zobrazení probíhajícího testu už nemusíte čekat na dokončení provádění testu, abyste znali výsledek testu. Výsledky jsou k dispozici téměř v reálném čase při jejich spuštění a pomáhají vám rychleji provádět akce. Můžete ladit selhání nebo přerušení, zařaďte chybu nebo přerušte kanál. Tato funkce je aktuálně dostupná pro kanál buildu i verze pomocí úlohy testování VS ve fázi více agentů, pomocí úlohy publikování výsledků testu nebo publikování výsledků testů pomocí rozhraní API. V budoucnu plánujeme rozšířit toto prostředí pro spouštění testů pomocí jednoho agenta.

Následující zobrazení ukazuje souhrn probíhajícího testu v zobrazení průběhu nové verze, vykazování celkového počtu testů a počtu selhání testů v daném bodu v čase.

Kliknutím na souhrn probíhajícího testu můžete zobrazit podrobný souhrn testů společně s informacemi o neúspěšných nebo přerušených testech v plánech testů. Souhrn testů se aktualizuje v pravidelných intervalech s možností aktualizovat zobrazení podrobností na vyžádání na základě dostupnosti nových výsledků.

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

Chybové zprávy a trasování zásobníku jsou zdlouhavé a potřebují dostatek nemovitostí k zobrazení podrobností během ladění. Pokud chcete mít imerzivní prostředí ladění, můžete nyní rozbalit zobrazení testovacího nebo testovacího spuštění na zobrazení celé stránky, zatímco stále můžete provádět požadované operace v kontextových operacích, jako je vytvoření chyby nebo přidružení požadavků pro aktuální výsledek testu.

Zobrazení historie testů v kontextu

V minulosti by týmy musely přejít do centra Spuštění , aby si mohli zobrazit historii výsledků testu. S novým prostředím přinášíme historii testů přímo v kontextu na kartě Testovací plány 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 a dalšími větvemi a prostředími pro sestavení a vydané verze.

Zobrazení přerušených testů

Spuštění testu může být přerušeno z několika důvodů, jako je chybný testovací kód, zdroj v rámci testu a 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. Teď můžete zobrazit přerušené testy a testovací běhy společně s dokončenými spuštěními v testovacích plánech. Tato funkce je aktuálně dostupná pro kanál buildu i verze pomocí úlohy testování VS ve fázi více agentů nebo publikování výsledků testů pomocí rozhraní API. V budoucnu plánujeme rozšířit toto prostředí pro spouštění testů pomocí jednoho agenta.

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

Přidáváme podporu pro zobrazení historie automatizovaného testu seskupené podle různých prostředí vydaných verzí, ve kterých se test spouští. Pokud modelujete prostředí vydaných 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 předává vývojové prostředí, ale v prostředí integrace selhává. Můžete zjistit, jestli se předává v anglickém národním prostředí, ale v prostředí, které má turecké národní prostředí, selhává. Pro každé prostředí zjistíte 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 (testů řízených daty). Vzhledem k tomu, že tyto testy souvisejí, musí být hlášeny společně s celkovým výsledkem odvozeným na základě jednotlivých výsledků testu. V této aktualizaci představujeme vylepšenou verzi výsledků testů prezentovaných jako hierarchii na kartě Testy ve vydané verzi. Podívejme se na příklad.

Dříve jsme představili možnost opětovného spuštění neúspěšných testů v úloze testování VS. Nicméně jsme oznámili pouze poslední pokus testu, který poněkud omezil užitečnost této funkce. Tuto funkci jsme teď rozšířili tak, aby ohlásila každou instanci testovacího spuštění jako pokus. Kromě toho rozhraní API pro správu testů teď podporuje možnost publikovat a dotazovat se na hierarchické výsledky testů. Další informace najdete v dokumentaci k rozhraní API výsledků testů.

Poznámka:

Metriky v části souhrnu testu (např. celkové testy, úspěšné atd.) se počítají pomocí kořenové úrovně hierarchie, nikoli každé jednotlivé iterace testů.

Zobrazení analýzy testu v Pipelines

Sledování kvality testů v průběhu času a zlepšení zajištění testů je klíčem k údržbě kanálu, který je v pořádku. 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 vysokou kvalitou dopadu.

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

Podívejte se na testovací analýzy pro buildy a vydání verze Preview níže:

Další informace najdete v naší dokumentaci.

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

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

Progresivní 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šechna zadaná hradla se pravidelně vyhodnocují před nebo po jakémkoli nasazení, dokud nebudou všechny úspěšné. K dispozici jsou čtyři typy bran a můžete přidat další brány z Marketplace. Budete moct auditovat, že byla splněna všechna potřebná kritéria pro nasazení. Další informace najdete v dokumentaci ověřování vydané verze.

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

Brány vydaných verzí umožňují automatické vyhodnocení kritérií stavu před povýšení verze do dalšího prostředí. Ve výchozím nastavení postupuje vydání po přijetí jedné úspěšné ukázky pro všechny brány. I když je brána erratická a úspěšný vzorek přijatý je šum, vydání postupuje. Abyste se těmto typům problémů vyhnuli, můžete teď nakonfigurovat verzi tak, aby ověřila konzistenci stavu po dobu minimální doby trvání před tím, než budete pokračovat. V době 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 opětovným vyhodnocením a obvykle by byla větší než nakonfigurovaná minimální doba trvání. Další informace najdete v ovládacím prvku nasazení vydané verze pomocí dokumentace k branám .

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 mají stejnou verzi. Teď můžete nakonfigurovat prostředí tak, aby automaticky nasadí poslední úspěšnou verzi do nových cílů. Další informace najdete v dokumentaci ke skupinám nasazení.

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

Triggery průběžného nasazování vytvoří vydání po dokončení sestavení. Někdy se ale sestavení po zpracování zpracovávají a sestavení by mělo být vydáno až po dokončení tohoto 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 triggerů 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í vydané 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ání proměnných prostředí úkolům

Autoři úloh CI/CD mohou nastavit novou vlastnost showEnvironmentVariables v task.json pro předávání proměnných prostředí úkolům. Když to uděláte, v editoru sestavení se na úkolu vykreslí 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á úkolu byla "foo" a nikoli "FOO".
• Umožňuje bezpečné předávání hodnot tajných kódů skriptům. Dává se přednost předávání tajných kódů jako argumentů skriptům, protože operační systém agenta 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 jen aktualizovat několik proměnných, nemusíte procházet zdlouhavým procesem přidávání proměnných o jednu po druhé. Teď můžete rychle vytvořit kopii skupiny proměnných, odpovídajícím způsobem aktualizovat hodnoty 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 nekopírují. Musíte aktualizovat šifrované proměnné a pak uložit naklonovanou skupinu proměnných.

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

Brány vydaných verzí umožňují automatické vyhodnocení kritérií stavu před povýšení verze do dalšího prostředí. Kanál verze ve výchozím nastavení postupuje jenom v případě, že jsou všechna brána ve stejnou dobu v pořádku. V některých situacích, například při urychlení vydání nebo po ruční kontrole stavu, může schvalovatel ignorovat bránu a umožnit vydání pokračovat, 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 vydané žádosti o přijetí změn

Mohli jste aktivovat sestavení na základě žádosti o přijetí změn a získat tuto rychlou zpětnou vazbu před sloučením na chvíli. Teď můžete nakonfigurovat i trigger žádosti o přijetí změn pro vydání. Stav vydané verze se publikuje zpět do úložiště kódu a může se zobrazit 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 certifikátem

Teď můžete definovat připojení služby Azure k instančnímu objektu a certifikátu pro ověřování. S připojením ke službě Azure teď podporujete instanční objekt, který se ověřuje pomocí certifikátu, teď můžete nasadit do služby Azure Stack nakonfigurované se službou AD FS. Pokud chcete vytvořit instanční objekt s ověřováním pomocí certifikátu, přečtěte si článek o 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 nasazení služby Aplikace Azure (4.*) teď podporuje RunFromPackage (dříve RunFromZip).

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

V případě balíčku Spustit z již neexistuje krok nasazení, který zkopíruje jednotlivé soubory do souboru wwwroot. Místo toho ho jednoduše nasměrujete na soubor ZIP a zip se připojí na 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 běží ve vaší aplikaci.
• Zlepšuje výkon nasazení služby Aplikace Azure Service.
• Může zkrátit dobu studeného spuštění, zejména pro funkce JavaScriptu s velkými stromy balíčků npm.

Nasazení linuxových kontejnerů s využitím úlohy nasazení aplikačního serveru

Verze 4.* úlohy nasazení služby Aplikace Azure teď podporuje nasazení vlastního kontejneru do azure Functions v Linuxu.

Model hostování Linuxu 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: Kód aplikace funkcí a Azure poskytuje a spravuje kontejner (integrovaný režim imagí), takže se nevyžadují žádné konkrétní znalosti související s Dockerem. To je podporováno ve stávající verzi úlohy nasazení služby App Service.
2. Vlastní image kontejneru: Vylepšili jsme úlohu nasazení služby App Service, která podporuje nasazování vlastních imagí kontejnerů do azure Functions v Linuxu. Pokud vaše funkce potřebují konkrétní jazykovou verzi nebo vyžadují konkrétní závislost nebo konfiguraci, která není součástí integrované image, můžete pomocí Azure Pipelines sestavit a nasadit vlastní image do funkce Azure Functions v Linuxu.

Úloha Xcode podporuje nově vydaný Xcode 10

Spolu s vydáním Xcode 10 od Společnosti Apple teď můžete projekty nastavit tak, aby se sestavovaly nebo testovaly speciálně pomocí Xcode 10. Kanál může také spouštět úlohy paralelně s maticí verzí Xcode. Ke spuštění těchto sestavení můžete použít fond agentů macOS hostovaný Microsoftem. Pokyny k používání Xcode ve službě Azure Pipelines

Zjednodušení nasazení do Kubernetes pomocí Helmu

Helm je nástroj, který zjednodušuje instalaci a správu aplikací Kubernetes. V minulém roce také získala spoustu popularity a podpory komunity. Úloha Helm ve verzi je nyní k dispozici pro balení a nasazování grafů Helm do služby 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 služby Azure Container Service .

Správa verze Helmu použitá ve vydané verzi

Úloha Instalačního programu nástroje Helm získá konkrétní verzi Helmu 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 dalších úlohách, jako je například úloha rozhraní příkazového řádku .NET Core. Přidání této úlohy před úlohu Helm Deploy v definici sestavení nebo verze zajistí, že vytváříte balení a nasazování aplikace se správnou verzí Helmu. Tato úloha také pomáhá při volitelné instalaci nástroje kubectl , což je předpokladem pro fungování Nástroje Helm.

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

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

Použití vylepšených úloh založených na Vzdáleném PowerShellu pro Windows

K dispozici jsou nové a vylepšené úlohy založené na Vzdáleném Prostředí PowerShell pro Windows. Mezi tato vylepšení patří několik oprav výkonu a podpora dynamických protokolů a výstupních příkazů 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ší verzí AzCopy (v7.1.0), která řeší problém GitHubu.

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

Při vydávání z GitHub 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 jenom buildy pocházející z konkrétní větve do produkčního prostředí.

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

Pomocí úlohy Instalační program nástroje Go nainstalujte jednu nebo více verzí nástroje Go za běhu. Tato úloha získá konkrétní verzi nástroje Go, kterou váš projekt potřebuje, a přidá ho do cesty agenta sestavení. Pokud už je v agentu nainstalovaná cílová verze nástroje Go, tato úloha proces stahování a instalace přeskočí.

Úloha Go vám pomůže stáhnout závislosti, sestavit nebo otestovat aplikaci. Tuto úlohu můžete použít také 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 ve vašem kanálu. Úloha spustí skript ze souboru Pythonu (.py) ve vašem úložišti nebo můžete ručně zadat skript 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 sestavení A testovacího výstupu Xcode z xcpretty

xcpretty vylepšuje čitelnost výstupu xcodebuild a generuje výsledky testů ve formátu JUnit. Úloha sestavení Xcode teď automaticky používá xcpretty, když 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 odlišný a méně podrobný než výstup xcodebuild, zpřístupníme úplné protokoly xcodebuild pro každé sestavení.

Test Plans

Klient Test Runneru (Azure Test Plans) pro spouštění ručních testů pro desktopové aplikace

Teď můžete pomocí klienta Test Runner (Azure Test Plans) spouštět ruční testy desktopových aplikací. To vám pomůže přejít z Microsoft Test Manageru na plány Azure Test Plans. Projděte si naše doprovodné materiály. Pomocí klienta Test Runneru 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 jsou snímky obrazovky, protokol akcí obrázku a záznam zvukového videa. Pokud při testování zjistíte problém, pomocí nástroje Test Runner vytvořte chybu s testovacími kroky, snímky obrazovky a komentáři, které se automaticky zahrnou do chyby.

Test Runner (Azure Test Plans) vyžaduje jednorázové stažení a instalaci spouštěče. 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. Další informace včetně změn chování, o které byste měli vědět před upgradem, vyhledejte banner nad balíčky informačního kanálu.
• Do informačního kanálu můžete přidat další informační kanály Azure DevOps Serveru jako nadřazené zdroje, což znamená, že prostřednictvím informačního kanálu můžete použít balíčky NuGet a npm.

Zavedli jsme také novou roli v Azure Artifacts: "Spolupracovníci". Spolupracovník může ukládat balíčky z nadřazeného zdroje, ale nemůže publikovat balíčky přímo do informačního kanálu (např. pomocí publikování NuGet). To vám umožní omezit publikování balíčků důvěryhodnému uživateli nebo systému sestavení a zároveň umožnit technikům používat nové balíčky z upstreamových zdrojů.

Sledování balíčků

Ještě jednodušší je nastavit 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 balíček sledujete při prohlížení zobrazení, získáte jenom aktualizace pro nové verze, které jsou na toto zobrazení povýšené.

Změna nastavení informačního kanálu bez nutnosti ručního uložení

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 teď okamžitě uloží. To znamená, že při přepínání mezi pivoty nastavení nemusíte mít obavy o ztrátu změn.

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ástrojem msbuild, dotnet a nuget(.exe) ve Windows, macOS a Linuxu. Kdykoli budete chtít používat 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 ukládat a spravovat ručně 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 Symboly indexu a publikování 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 vytvářejí dokumentaci pro "rozhraní API", "sady SDK" a "dokumentaci nápovědy vysvětlující kód" v úložištích kódu. Čtenáři pak musí projít kódem, aby našli správnou dokumentaci. Teď můžete jednoduše publikovat soubory Markdownu z úložišť kódu a hostovat je na wikiwebu.

Začněte kliknutím na Publikovat kód jako wikiweb. Dále můžete zadat složku v úložišti Git, které by se měly zvýšit.

Po kliknutí na možnost Publikovat se všechny soubory markdownu ve vybrané složce publikují 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 produktové dokumentace.

Odkaz na nadpisy na stránce

Teď můžete kliknout na ikonu odkazu vedle libovolného nadpisu oddílu na stránce wikiwebu a vygenerovat adresu URL přímo do tohoto oddílu. Pak můžete tuto adresu URL zkopírovat a sdílet ji se členy týmu a propojit je přímo s tímto oddílem.

Připojení souborů a obrázků ve složkách

Při úpravách stránek wikiwebu offline můžete snadněji přidávat 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 ji se stránkou.

Vložení videa na wiki

Videa teď můžete vložit na stránku wikiwebu z online služby, jako je Microsoft Stream a YouTube. Vloženou adresu URL 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 používat 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 myši na stránku wikiwebu a otevřít ji na nové kartě nebo jednoduše stisknout klávesu CTRL a kliknout levým tlačítkem na stránku wikiwebu a otevřít ji na nové kartě.

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

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

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

Zobrazit přerušené odkazy

Všechny odkazy na wikiwebu, které nejsou správně propojené, se zobrazí v odlišné červené barvě a ikoně přerušeného odkazu, takže vám poskytne vizuální povědomí o všech poškozený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. Dříve na wikiwebu, když jste přesunuli stránku ve struktuře stromové struktury nebo přejmenovali stránku, 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, než se přeruší.

Důležité

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

Když stránku přejmenujete nebo přesunete, zobrazí se výzva k vyhledání ovlivněných absolutních nebo relativních odkazů.

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

Vytvoření obsahu pro stránky wikiwebu

Stránky wikiwebu někdy můžou být dlouhé, s obsahem uspořádaným do několika nadpisů. Obsah teď můžete přidat na libovolnou stránku, která má aspoň jeden nadpis, a to pomocí [[_TOC_]] syntaxe.

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 k pokynům 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 smysluplný obsah a zobrazit je. V této aktualizaci se všechny soubory, které obsahují blok YAML na začátku souboru, transformují na tabulku metadat jedné hlavy a jednoho řádku. 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 se podporuje 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 wiki s využitím oprávnění pro přispívání

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

Sestavy

Rozšíření Analytics Marketplace pro vytváření sestav je teď k dispozici.

Rozšíření Analytics Marketplace je teď k dispozici pro Azure DevOps Server. Analýza je 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 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 boards a výsledky automatizovaného testování prostřednictvím kanálů. Viz Data dostupná ve službě Analytics.

Zkoumá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 do řídicích panelů. Pomocí tohoto widgetu teď můžete zobrazit historii buildů z konkrétní větve na řídicím panelu a nakonfigurovat ji na veřejném projektu pro anonymní návštěvníky.

Důležité

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

---

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