Poznámky k vydání pro Azure DevOps Server 2019

Komunita vývojářůLicenční podmínkySystémové požadavkyDevOps BlogSHA-1 Hashy

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

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

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

---

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

Azure DevOps Server 2020 zavádí nový model uchovávání běhu kanálu (sestavení), který funguje na základě projektových nastavení.

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

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ů pro úlohy v PowerShellu pro parametr validace argumentů při povolení úloh 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 zahrnující opravu Patch 15, která byla vydána 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 o nahrání úkolů do kolekce projektů nainstalujte tfx-cli a přihlaste se.

Aktualizace úloh pomocí TFX

Soubor	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Požadavky na kanál

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

• Na klasiku:

  Definujte proměnnou na kartě proměnné v potrubí.

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

• 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 úpravy této aktualizace, budete muset podle několika kroků 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á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 degradaci agenta, musí být AZP_AGENT_DOWNGRADE_DISABLED nastaveno 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 o nahrání úkolů do kolekce projektů nainstalujte tfx-cli a přihlaste se.

Aktualizace úloh pomocí TFX

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

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

Požadavky na kanál

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

• Na klasiku:

  Definujte proměnnou na kartě proměnné v potrubí.

• 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á opravuje následující problémy.

• 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á opravuje následující problémy.

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

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á opravuje následující problémy.

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

Hash SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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á opravuje následující problémy.

• Oprava chyby v uživatelském rozhraní definice sestavení

Azure DevOps Server 2019.0.1 Záplata 10 Datum vydání: 13. dubna 2021

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

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

Chcete-li použít opravu 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.

Instalovat

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 (který je součástí stažení Node.js) podle parametrů 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 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 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á opravuje následující problémy. 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
• Opravit problém s neprovedením všech výsledků v 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 nainstalován ve výchozím nastavení 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 Fail on Standard Error.

Instalovat

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 (který je součástí stažení Node.js) podle parametrů 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 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>*

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

Vydali jsme záplatu zabezpečení pro Azure DevOps Server 2019.0.1, která řeší následující problémy. 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 záplatu zabezpečení pro Azure DevOps Server 2019.0.1, která řeší následující problémy. Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-1326: Zranitelnost typu cross-site scripting
• Kanál buildu zobrazuje nesprávné připojení neoprávněných uživatelů při výběru jiného zdroje Gitu.
• Opravit chybu při změně nastavení dědičnosti na Zapnuto nebo Vypnuto v definici sestavení XAML.

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

Vydali jsme záplatu zabezpečení pro Azure DevOps Server 2019.0.1, která řeší následující problémy. 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 záplatu zabezpečení pro Azure DevOps Server 2019.0.1, která řeší následující problémy. Další informace najdete v tomto blogovém příspěvku.

• CVE-2020-0700: Zranitelnost 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 repozitáří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í ke službám jsme přidali informace, které objasňují, že jsou ve výchozím nastavení autorizované pro všechna potrubí.

---

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 pull requestech

---

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

• "Položka pole pro tento plán má 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 metoda 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í v náhledu.
• 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 vstupních stránkách vydání byla akce zahájení konceptu vydání původně vytvářet nové vydání, ale nyní zahajuje koncept vydání.

Plány testů Azure

• Jednohodinový filtr pro TestRuns a TestResults CompletedDate je příliš podrobný.
• Typ pracovní položky Test Case by neměl být lokalizován jako "Test Case".
• Testovací případy se nezobrazují v MTM ani v prohlížeči.
• Při ověřovací fázi: Nemáte oprávnění ke spouštění vydání v přidruženém vydávacím kanálu, když spouštíte automatizované testy z testovacího plánu. 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 rychlost, burndown a burnup zobrazují různé naplánované úkoly pro uživatele v různých časových pásmech.
• Může být zavedeno blokování příjmu dat Analytics během údržby, což může způsobit zpožděné sestavy.

Obecné

• Levé navigační položky se v prohlížeči Internet Explorer zmáčknou, pokud není dostatek místa.

Správa

• Do upgradu kolekce jsme přidali protokolování, které pomůže s laděním problémů.
• Pokud tfsConfig offlineDetach selže, chybová zpráva není použitelná.
• Služba TfsJobAgent selže.
• 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.
• Háčky služby nemusí správně zpracovávat oznámení.
• Indexování kódu se po nastavení 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 potrubích jsme přidali podporu pro 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í commitů a žádostí o přijetí změn v GitHub Enterprise s pracovními položkami v Azure Boards
• Konfigurace sestavení pomocí YAML
• Anotace karet zahrnují chyby a vlastní typy pracovních položek.
• Vylepšený výběr větví
• Změny licencování nasazovacího kanálu pro 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 nyní k dispozici.
• Podpora služby Azure SQL Database
• Dědičnost procesů u nových kolekcí
• Rozhraní pro nové pracovní položky
• 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 pull requestu
• 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
• Postupně odhalovat a fázovat nasazení pomocí vydávacích bran
• Upstreamové zdroje
• Vytvořit obsah pro stránky wiki

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

• Obecné
• Tabule
• Repos
• Potrubí
• Testovací plány
• Artefakty
• Wiki
• Reportování

---

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 nakupovat nasazovací kanály v rámci 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.

Položka práce a testovací klientský objektový model SOAP API 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 moje práce rozbalovací nabídka. 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 jste s tímto novým rozbalovacím panelem ponořeni do kódu v Repos, ale chcete rychle zkontrolovat, na které pracovní položce byste měli pracovat dál, jednoduše klikněte na rozbalovací panel a uvidíte pracovní položky přiřazené vám, ze kterých si můžete vybrat další položku.

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

Zde můžete vidět druhý pivot, který zobrazuje PR přiřazené mně. Ve vyskakovacím okně máte také možnost jedním kliknutím zobrazit více pull requests.

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

Desky

Propojte commity a pull requesty GitHub Enterprise 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í commitů a pull requestů 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 slova "fix", "opraví" nebo "opraveno" předchází zmínění pracovní položky (jak je uvedeno výše), pracovní položka se přesune do dokončeného stavu při sloučení commitu 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 pro 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. Můžete zobrazit Přiřazeno mně, abyste rychle získali přehled o veškeré práci, která vám byla přiřazena, nebo Nedávno aktualizované, která vám ukáže všechny pracovní položky ve vašem projektu, jež byly nejnověji 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í. Tyto zážitky se dají zobrazit níže:

Nové panely, backlogy a rozhraní sprintů

Centrum Backlogů bylo rozděleno do tří samostatných sekcí, aby se zlepšil uživatelský zážitek. Ačkoliv je starý uzel Backlog silný, byl 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ů nyní obsahuje pouze backlogy pro daný projekt. Backlog je seřazený 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ý hub Boards je domovem všech Kanban Boardů 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
• Drobečková navigace s jedinečnými adresami URL 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 deaktivován, 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řazeného, Typ pracovního úkolu, Stav a Značky si můžete přizpůsobit zobrazení podle svých potřeb.

Nové stránky adresáře

Všechny nové uzly, včetně seznamů nevyřízených položek, panelů a sprintů, teď mají nové adresářové stránky rozdělené do následujících sekcí:

• Pokračujte tam, kde jste skončili. Tato nová sekce obsahuje rychlý odkaz přímo na poslední (Panel | Backlog | Sprint), na kterém jste byli.
• Oblíbené Všechny vaše 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 nových možností 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ách jsou oblíbené pro jejich intuitivní zobrazení kontrolního seznamu a interakci. V minulosti byly poznámky karty omezené na výchozí typy na úrovni backlogu a nepodporovaly 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í umožněných typů pracovních položek je také dostupné prostřednictvím kontextové 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 cest oblasti a Iterace teď obsahují seznam naposledy použitých hodnot jako Návrhy, takže máte rychlý přístup k nastavení a pokračování.

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á vašemu týmu sledovat práci na základě plánu iterace, nyní podporuje celočíselné posuny. Snadno udržujte přehled o práci, která nebyla dokončena pomocí @CurrentIteration - 1, nebo se podívejte na práci plánovanou pro budoucí iterace pomocí @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.

Dotazování v oblasti cest týmu pomocí nového @TeamAreas makra

V nastavení pro tým můžete přidružit jednu nebo více oblastí, což vám pomůže soustředit backlogy, tabule, plány, nebo dokonce řídicí panely jenom na práci pro daný tým. Pokud byste ale chtěli napsat dotaz pro tým, museli jste v dotazových klauzulích vypsat konkrétní oblasti cesty pro tento tým. Nyní je k dispozici nové makro @TeamAreas, které vám umožní snadno odkazovat na oblastní cesty spravované 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é 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. Selektor dotazu byl nahrazen vloženými návrhy, které vycházejí z vašich nedávno přístupných pracovních položek, a možností vyhledat konkrétní pracovní položku 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í této zkušenosti pro organizace s velkým počtem poboček zavádíme nový nástroj pro výběr poboček. Nástroj pro výběr nyní umožňuje zvolit oblíbené větve nebo rychle vyhledat větev.

Dostávejte oznámení, pokud jsou pravidla pull requestu obejita

Pro týmy, které používají žádosti o přijetí změn (PR) a zásady větví, mohou nastat situace, kdy lidé potřebují tyto zásady přepsat a obejít – například při zavádění opravy hotfix do produkčního prostředí uprostřed noci. Dává smysl důvěřovat vývojářům, že udě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 tyto výjimky 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 se šablonou vytvoření nebo aktualizace žádosti o přijetí změn a v seznamu filtrů vyberte Obcházení zásad. Vyberte Překročení zásad jako hodnotu a budete upozorněni vždy, když je žádost o přijetí změn dokončena a dojde k obejití zásad.

Povolit obejití zásad větve bez ztráty ochrany proti pushům

Existuje mnoho scénářů, kdy máte občas potřebu obejít zásadu větve – například při vrácení změny, která způsobila přerušení sestavení, nebo při aplikaci opravy hotfix uprostřed noci. Dříve jsme nabízeli oprávnění ("Vyloučení z vynucování zásad"), které týmům pomáhalo spravovat, kterým uživatelům byla udělena možnost obejít zásady větve při dokončování pull requestu. Toto oprávnění ale také poskytlo možnost pushovat přímo do větve a zcela obejít proces žádosti o přijetí změn.

Abychom tuto zkušenost zlepšili, rozdělili jsme staré oprávnění, abychom týmům, které udělují oprávnění k obejití, poskytli 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í pull requestů obejít zásady. Uživatelé s tímto oprávněním budou moct pro pull requesty používat režim Přepsání.
2. Vynechat zásady při provádění push. Uživatelé s tímto oprávněním budou moct odesílat změny přímo do větví, 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 pushováním do větve s politikami.

Poznámka:

Tato změna nezavádí žádné změny chování. Uživatelům, kterým bylo dříve uděleno Povolit jako výjimka z vynucování zásad, bude uděleno Povolit u obou nových oprávnění, takže budou moci jak přepisovat dokončování u žádostí o přijetí změn (PR), tak přímo provádět zápisy do větví s nastavenými zásadami.

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

Rychle popište pull requesty pomocí zpráv o potvrzení změn

Psaní popisných zpráv ke commitům přidává hodnotu k historii libovolného Git úložiště. Aby se podpořily kvalitní zprávy o commitech, nové žádosti o pull requesty, které mají více commitů, budou vyžadovat, aby přispěvatelé zadali název ručně.

Popisy pull requestů budou ve výchozím nastavení prázdné, ale nová funkce usnadní začlenění zpráv z potvrzení commitů do popisu pull requestu. Pokud chcete přidat zprávy potvrzení, jednoduše klikněte na Přidat zprávy potvrzení, čímž se zprávy potvrzení přidají na konec textu popisu PR.

Vytvořit pull requesty bez výchozího týmu jako recenzent.

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 zdrojem frustrace, protože mnoho lidí si nevšimlo spojení mezi týmovým kontextem a přiřazením pull requestu.

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í recenzenti. Seznam posuzovatelů má funkci, která usnadňuje přidávání jednotlivců a skupin, jež byly nedávno přidány do pull requestů. Zásady požadovaných kontrolorů mohou také pomoci týmům, které chtějí zajistit, aby byli ke kontrole jejich kódu přidáni konkrétní recenzenti.
2. Rozhraní Pull Requests má novou přizpůsobitelnou sekci. Ve výchozím nastavení se v této části zobrazují pull requesty přiřazené mým týmům, čímž poskytují ekvivalentní funkčnost jako v předchozí verzi. Pokud ale patříte do více týmů, zobrazí se v této části pull requesty 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, vybrat libovolnou šablonu v úložišti a připojit ji k popisu PR.

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

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

Změna cílové větve pull requestu

U většiny týmů téměř všechny žádosti o přijetí změn cílí 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 pro změnu cílové větve aktivní žádosti o přijetí změn je nyní tento úkon snadný. 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 funkce pro změnu cílových větví také usnadňuje změnu cílové větve žádosti o přijetí změn, pokud byla cílová větev sloučena nebo odstraněna. Představte si scénář, ve kterém máte pull request zaměřený na funkční větev, 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 funkcionality, takže jste původně cílili na 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 funkční větev měla také aktivní pull request a byla sloučena do main před vašimi změnami? Dříve byste museli své změny opustit a vytvořit novou žádost o přijetí změn do main, nebo svou žádost sloučit do features/new-feature, a pak vytvořit další žádost z features/new-feature do main. S touto novou akcí pro aktualizaci cílové větve můžete jednoduše změnit cílovou větev PR z features/new-feature do main, a zároveň zachovat veškerý kontext a komentáře. Změna cílové větve vede dokonce k vytvoření nové aktualizace pull requestu, a tím usnadňuje zpětné nahlédnutí na předchozí rozdíly před změnou cílové větve.

Autoři rozšíření se mohou 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, 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á.

Potrubí

Spravujte buildové pipeline 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ů 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. Nyní řádek předmětu na první pohled zahrnuje více relevantních informací, text obsahuje více podrobností a jejich styl byl modernizován podle nejnovější značky.

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

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 hostovaný uživatelem	Agent pro sestavení/vydání, který běží na počítači 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 pro agenty	Fond agentů	Sada agentních strojů na úrovni projektu, které mohou spouštět sestavení nebo verze. Je propojený s fondem agentů na úrovni organizace.
Konfigurace sestavení	Potrubí sestavení	Kompletní sada kroků sestavení pro aplikaci.
Sestavení	Sestavení	Instance sestavovacího kanálu, který běží nebo již proběhl.
Fáze	Práce	Řada úloh, které se spouštějí postupně nebo paralelně na agentu. Kanál buildu nebo verze může obsahovat jednu úlohu nebo graf více úloh.
Definice vydání	Nástroj pro vydání	Kompletní sada kroků vydání pro aplikaci, která se má nasadit v různých fázích.
Vydání	Vydání	Instance vydávacího kanálu, který je spuštěný nebo běžel.
Prostředí	Pódium	Logická a nezávislá entita, která představuje místo, kam chcete nasadit verzi vygenerovanou z vydávacího kanálu.
Souběžná úloha/kanál	Paralelní úloha	Paralelní úloha umožňuje spustit jednu úlohu sestavení nebo distribuční úlohu 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 vydavatelských kanálů pomocí nové stránky vydání

Pro cílovou stránku vydané verze je k dispozici nové a plně přepracované uživatelské prostředí. Podívejte se na seznam vývojových kanálů, které často uvolňujete, nalevo. Také můžete prohledávat své pipelines 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 nasazovací kanál, což usnadňuje pochopení toho, co se děje, a zobrazuje příslušné podrobnosti a akce v různých fázích nasazení.

Pipelina, podrobnosti vydání a prostředí

Zobrazení pipeline ukazuje artefakty verze a prostředí, ve kterých budou nasazeny. Oblast Vydání poskytuje podrobnosti o vydání, jako je spouštěč vydání, 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 stavu prostředí, která visí z pravé nebo levé strany prostředí.

Commity a pracovní úkoly

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ý, použijte filtry k vyhledání commitu nebo pracovního úkolu, který vás zajímá.

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ů je dokončeno, a doba 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 soustředěné zobrazení.

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

Skupiny počítačů v testovacím centru byly v TFS 2017 RTM nepodporované. 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 potrubí nadále fungovaly,

• Musíte použít úlohu "Kopírování souborů počítače s Windows" verze 2.* a místo názvu počítače zadat úplný název počítače (FQDN) pro cílový počítač.
• A přepněte na úlohu PowerShellu na cílovém počítači verze 2.* a zadejte plně kvalifikovaný doménový název (FQDN) nebo název počítače, následovaný síťovými 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 .

Konfigurujte 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 zaznamenaného 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ž tak učiníte, osoba s oprávněními k použití prostředku musí výpočetní tok explicitně uložit ve webovém editoru poté, co je do souboru YAML přidán odkaz na prostředek.

Zřetězujte související sestavení pomocí spouštěčů 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 spustit 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. Pro více informací se podívejte do dokumentace ke spouštěčů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. Spouštěč 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ý spravuje závislý proces.

Místní aktualizace agenta

Úlohy, které si instalujete z galerie, někdy vyžadují novější verzi agenta pipeline. 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 pro stavový odznak nového buildu

Odznaky pro sestavení vložené na domovskou stránku úložiště jsou běžným způsobem, jak ukázat stav úložiště. 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 stavového odznáčku můžete získat výběrem akce "Odznáček stavu" v nabídce na nové stránce "Builds".

Kvůli zpětné kompatibilitě budeme nadále uznávat i adresy URL starších odznáček buildu.

Přidejte vlastní čítače k vašim sestavám

Čítače sestavení poskytují možnost, jak jedinečně očíslovat a označovat sestavení. Dříve byste k tomu mohli použít speciální proměnnou $(rev:r). Teď můžete definovat vlastní čítačové proměnné ve své definici sestavení, které se automaticky navyšují při každém spuštění sestavení. Provedete to na kartě proměnných jedné 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. Nyní selhává úloha nasazení skupiny prostředků Azure kvůli chybám souvisejícím se zásadami v případě jakéhokoli 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 platformách Linux/ARM a 32bitových Windows

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 nyní nabízí moderní zážitek, který poskytuje bohaté, kontextové informace o testech pro Pipelines. Nové prostředí poskytuje zobrazení testu během provádění, prostředí ladění na celé stránce, historii kontextových testů, hlášení přerušeného provádění testu a souhrn na úrovni provádě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í, nahlásit chybu nebo zrušit 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í běhu testu v režimu celé stránky

Chybové zprávy a zásobníková trasování jsou zdlouhavé a potřebují dostatek prostoru na obrazovce k zobrazení podrobností při ladění. Pokud chcete mít pohlcující prostředí ladění, můžete nyní zvětšit zobrazení testu nebo spuštění testu na celou stránku a přitom stále provádět potřebné operace v rámci kontextu, jako je vytvoření chyby nebo přiřazení požadavků k aktuálnímu výsledku testu.

Zobrazení historie testů v kontextu

V minulosti by týmy musely přejít do hubu Spuštění aby si mohly zobrazit historii výsledků testu. S novou zkušeností zpřístupňujeme 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á jak pro build, tak pro uvolňovací pipeline s využitím Testovací úlohy VS ve fázi s více agenty nebo pro publikování výsledků testů pomocí 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 produkční prostředí jako kanály uvolňování verzí nebo testovací prostředí a spouštíte testy napříč těmito prostředími, můžete zjistit, zda test prochází v dev prostředí, ale v integračním prostředí selhává. Můžete zjistit, jestli funguje v anglickém locale, ale selhává v tureckém locale. 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 VS Test úloze. 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 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 zdokonalení materiálů pro testování je klíčem k udržování zdravého procesu. Funkce analýzy testů poskytuje téměř v reálném čase přehled o testovacích datech pro buildy a release pipeline. Pomáhá zlepšit efektivitu vašeho procesu tím, že identifikuje opakující se problémy s vysokým dopadem na kvalitu.

Výsledky testů můžete seskupit podle různých prvků, identifikovat klíčové testy pro vaši větev nebo testovací soubory, nebo prozkoumat podrobnosti konkrétního testu, sledovat trendy a pochopit problémy s kvalitou, jako je nestabilita testu.

Podívejte se na testovací analýzy pro sestavení a verze, viz náhled 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 existovala více než jedna úloha bez agentů, takže definice byla objemná. 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ě vystavujte a fázujte nasazení pomocí vydávacích bran.

Pomocí kontrolních bran vydání můžete zadat kritéria stavu aplikace, která musí být splněna před povýšením verze do dalšího prostředí. Všechna určená hradla jsou pravidelně hodnocena před nebo po jakémkoli nasazení, dokud nejsou všechna ú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 o kontrolních bodech ve vydávacím procesu najdete v dokumentaci.

Pozastavte nasazení, dokud nebudou kontroly probíhat konzistentně úspěšně.

Brány nasazení umožňují automatické vyhodnocení zdravotních kritérií před nasazením verze do dalšího prostředí. Ve výchozím nastavení postupuje vydání po přijetí jednoho úspěšného testu u všech bran. I když je brána nestálá a úspěšný vzorek přijatý je šum, postup uvolňování pokračuje. Abyste se těmto typům problémů vyhnuli, můžete teď nakonfigurovat verzi tak, aby ověřila konzistenci zdravotního stavu po minimální dobu před pokračováním. Během běhu by uvolně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 naleznete v dokumentaci Řízení nasazení pomocí bran.

Automatické nasazení na nové cíle ve skupině nasazení

Dříve se při přidání nové cíle do skupiny nasazení vyžadovalo ruční nasazení, aby se zajistilo, že všechny cíle mají stejný release. 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í

Spouštěče průběžného nasazování vytvoří vydání po dokončení sestavení. Někdy jsou však sestavení dodatečně zpracovány a měly by se vydat až po dokončení tohoto zpracování. Teď můžete využít značky sestavení, které se přiřadí během následného zpracování, ve filtrech spouštění verze.

Nastavte proměnnou v čase 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 při vytváření v návrhu, aktualizovat proměnné v návrhu a spustit vydání s použitím proměnné.

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

Ignorovat bránu vydání pro nasazení

Brány nasazení umožňují automatické vyhodnocení zdravotních kritérií před nasazením verze do dalšího prostředí. Vydávací kanál ve výchozím nastavení postupuje jen, když jsou všechny brány současně v pořádku. V některých situacích, například při urychlení vydání nebo po ruční kontrole zdraví, může schvalovatel chtít ignorovat bránu a umožnit, aby vydání pokračovalo, i když tato brána ještě nebyla vyhodnocena jako v pořádku. Dokumentace k release gates poskytuje více informací.

Provedení dalšího testování pomocí spouštěče vydání pull requestu

Mohli jste už nějakou dobu aktivovat sestavení na základě žádosti o přijetí změn a získat tak rychlou zpětnou vazbu před sloučením. Nyní můžete také nastavit spouštěcí událost pull requestu pro nové vydání. Stav vydání bude publikován zpět do úložiště kódu a lze jej přímo zobrazit na stránce PR. Je to užitečné při provádění dalších funkčních nebo manuálních testů jako součást vašeho PR workflowu.

Vytvořte připojení služby Azure pomocí služebního principálu, který se ověřuje certifikátem

Nyní můžete definovat připojení služby Azure s principálem služby a certifikátem pro autentizaci. S nyní podporovaným připojením ke službě Azure, které umožňuje principálu služby ověřovat se pomocí certifikátu, můžete nasadit do Azure Stack nakonfigurovaného 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 podporováno při nasazeních v 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.

Při použití funkce Run From Package již neexistuje krok nasazení, který by kopíroval jednotlivé soubory do adresáře 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 náběhu, zejména pro funkce JavaScriptu, které využívají rozsáhlé stromové struktury 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. Vestavěný obraz kontejneru: Dodáte kód funkční aplikace a Azure poskytuje a spravuje kontejner (režim vestavěných obrazů), takže nepotřebujete žádné specifické znalosti o Dockeru. 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. Vaše vývojová linka 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. Podívejte se na 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 v Release je nyní k dispozici pro balení a nasazování Helm chartů do Azure Container Service (AKS) nebo jakéhokoli jiného clusteru Kubernetes.

Přidáním této úlohy Helm nyní můžete vytvořit CI/CD kanál 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 .

Kontrola verze Helm používané při vydání.

Ú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 například v úloze příkazového řádku .NET Core. Přidání této úlohy před úlohu Helm Deploy v definici sestavení nebo vydání zajistí, že balíte a nasazujete aplikaci se správnou verzí Helmu. Tato úloha také pomáhá při instalaci volitelného nástroje kubectl, což je předpokladem pro fungování Helm.

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

Nyní můžete průběžně nasazovat do služby Azure Database for MySQL – MySQL databáze 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 ukončit proces 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.

Filtrovat větve pro GitHub Enterprise nebo externí Git artefakty

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 průběžně. Tato úloha získá konkrétní verzi nástroje Go, kterou váš projekt potřebuje, a přidá ho do PATH sestavovacího agenta. 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 datovém toku

Nová úloha Python Skriptu zjednodušuje spouštění Python skriptů ve vašem potrubí. Ú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 použije verzi Pythonu v nastavené cestě, nebo můžete zadat absolutní cestu k interpretu Pythonu.

Využijte vylepšený výstup sestavení a testování z Xcode pomocí 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, pokud je k dispozici na stroji agenta, jak tomu 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í.

Testovací plány

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.

Artefakty

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 vašeho informačního kanálu pro více informací, včetně změn chování, o kterých byste měli vědět před upgradem.
• 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 kanálu (např. použitím příkazu nuget publish). 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 ve výhledu, získáte pouze aktualizace pro nové verze, které jsou povýšené do tohoto výhledu.

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 autentizovanými zdroji NuGet je nyní výrazně 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.

Komprimujte symboly při publikování na sdílené úložiště

Aktualizovali jsme úlohu Index a publikování symbolů tak, aby podporovala komprimování symbolů při jejich exportu do sdílené složky.

Wiki

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

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.

V rámci Wiki začněte kliknutím na Publikovat kód jako wiki. Dále můžete zadat složku v úložišti Git, která by měla být propagována.

Po kliknutí na možnost Publikovat se všechny soubory markdownu ve vybrané složce publikují jako wikiweb. Tím se také namapuje vrchol větve na wiki, takže se všechny změny, které provedete v úložišti Git, okamžitě projeví.

Další informace najdete v příspěvku na blogu 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 ve Wiki, když jste přesunuli stránku ve stromové struktuře nebo přejmenovali stránku, mohlo 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 pro Wiki stránku v pracovních položkách, aby Wiki mohla najít a opravit tyto potenciálně poškozené odkazy. Adresy URL a hypertextové odkazy v pracovních položkách, které jsou ve formátu prostého textu, nebudou touto funkcí rozpoznány.

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 wiki stránky

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.

Podívejte se na dokumentaci k pokynům pro markdown, abyste zjistili více informací o používání markdownu v Azure DevOps.

Metadata pro povrch wiki stránek 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ého YAML bloku mezi trojitými pomlčkami. 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í

Dříve mohli kód jako wiki publikovat jen 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 publikaci souborů Markdown hostovaných v úložištích Git jako wiki. 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.

Výkaznictví

Rozšíření trh Analytics pro přehledy je teď k dispozici.

Rozšíření Analytics Marketplace je teď k dispozici pro Azure DevOps Server. Sada nástrojů Analytics představuje budoucnost reportování 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 Co je Analytika a v Plánu sestav. Analytics je ve veřejné ukázce. V současné době obsahuje data pro desky a výsledky automatizovaných testů prostřednictvím pipeline. Viz Data dostupná ve službě Analytics.

Prozkoumejte historii sestavení pomocí nového widgetu sestavovacího panelu

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