Podpora sekvenčních nasazení při použití výhradních kontrol uzamčení

V tomto sprintu jsme rozšířili možnost výhradních kontrol zámků v Azure Pipelines tak, aby podporovala sekvenční nasazení. Teď můžete v prostředí zařadit více spuštění do fronty, aby se najednou spustilo jenom jedno z nich.

Podrobnosti najdete v následujících popisech funkcí.

Azure Boards

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

Azure Pipelines

• Podpora sekvenčních nasazení místo nejnovějších pouze při použití výhradních kontrol uzamčení
• Podpora pro quebecovou verzi ServiceNow
• Změna zásad předinstalace sady .NET SDK u agentů hostovaných pro Windows a macOS hostovaných Microsoftem
• Změny úloh PublishBuildArtifacts a DownloadBuildArtifacts

Azure Boards

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

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

Azure Pipelines

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

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

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

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

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

Nastavení na ploše:

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

Nastavte v kanálu:

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

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

Podpora pro quebecovou verzi ServiceNow

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

Změna zásad předinstalace sady .NET SDK v agentech pro Windows a macOS hostovaných Microsoftem

Nedávno jsme oznámili změnu zásad předinstalace sady .NET SDK u agentů Ubuntu hostovaných Microsoftem. Teď provádíme stejnou změnu pro agenty pro Windows a macOS hostované Microsoftem.

V současné době instalujeme všechny dostupné a podporované verze sady .NET SDK (2.1.x, 3.1.x, 5.0.x) na agenty pro Windows a macOS hostované Microsoftem. Tento přístup se změní ve prospěch instalace nejnovější verze oprav pro každou verzi funkce. Tato změna se provádí, aby vám poskytla více volného místa a pro žádosti o nové nástroje.

Co to znamená?

Verze sady SDK se skládá z následujících částí: x.y.znn. z je verze funkce a nn je verze opravy. Například pro verzi 2.1.302 je verze funkce 3 a verze 02 je verze opravy. Podle nového přístupu nainstalujeme pouze nejnovější verzi opravy pro každou verzi funkce, tj. pro verzi 2.1.302 se nainstaluje pouze verze 2.1.302, pro verzi 2.1.403 a tak dále. Všechny verze sady .NET SDK, které nejsou nejnovějšími verzemi oprav, budou 6. září odebrány z imagí windows a macOS. Tato změna se týká všech verzí Windows a macOS na agentech hostovaných Microsoftem.

Cílové datum

Nasazení aktualizovaných imagí začne 6. září a bude trvat 3 až 4 dny.

Možný dopad

Pokud použijete soubor global.json, bude sestavení ovlivněno v následujících případech:

Sestavení selže, pokud soubor global.json obsahuje rollForward: disable vlastnost a verzi sady SDK, která není nejnovější verzí opravy. Příklad:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

Pokud soubor global.json obsahuje rollForward: patch vlastnost, verze sady .NET SDK se automaticky změní na nejnovější opravu. Příklad:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

rollForward Pokud pole není zadané v souboru global.json, nedojde k žádné změně. Používá se nejnovější úroveň nainstalovaných oprav.

Pokud potřebujete použít přesnou verzi sady .NET SDK, která není nejnovější opravou, nainstalujte UseDotNet ji jako součást sestavení pomocí úlohy:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Změny úloh PublishBuildArtifacts a DownloadBuildArtifacts

Azure Pipelines podporuje dvě sady úloh pro publikování a stahování artefaktů. PublishPipelineArtifact a DownloadPipelineArtifact jsou novější a doporučené úlohy pro provedení těchto kroků.

PublishBuildArtifacts a DownloadBuildArtifacts jsou starší úlohy a nemají stejné optimalizace výkonu a úložiště, které jsou k dispozici v odpovídajících úlohách PipelineArtifact. Tyto starší úlohy měly také omezení škálování, pokud jde o způsob jejich implementace. Někteří z našich větších zákazníků na tato omezení narazí.

I když bychom chtěli, aby všichni zákazníci přešli na úlohy PipelineArtifact, museli jsme také provést několik kroků, abychom vyřešili škálovatelnost starších úloh BuildArtifact. V rámci nedávné aktualizace za účelem zlepšení škálovatelnosti teď agenti Azure Pipelines budou přímo pracovat s artefakty sestavení prostřednictvím domén blobstore (místo směrování přes domény tfs). Tyto kanály začnou přistupovat k IP adresám a doménám, které jsou už dlouho na seznamu povolených pro Azure DevOps, ale konkrétní kanály je ještě nemusely používat.

Aktualizovaná implementace úloh BuildArtifact vyžaduje upgrade agenta, který by měl proběhnout automaticky, pokud nebyly výslovně zakázány automatické upgrady nebo nejsou nesprávně nakonfigurované brány firewall.

Pokud jsou vaši agenti spuštěni v prostředích s bránou firewall, která nedodržovala propojené pokyny, můžou se při aktualizaci agenta nebo v úlohách PublishBuildArtifacts nebo DownloadBuildArtifacts zobrazovat chyby, dokud se neopraví konfigurace brány firewall.

Běžným příznakem tohoto problému jsou náhlé chyby související s metodou handshakes protokolu SSL nebo selháním stahování artefaktů, obecně u fondů nasazení, na které cílí definice Release Management. Případně, pokud byly upgrady agentů zablokované, můžete si všimnout, že vydané verze čekají na agenta ve fondu, který nikdy nepřijde, nebo že agenti přejdou do offline režimu v polovině své aktualizace (to souvisí s prostředími, která chybně blokují agenta CDN).

Další kroky

Poznámka

Tyto funkce budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se.

Přejít na Azure DevOps

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

Můžete také získat rady a odpovědi na vaše otázky od komunity na Webu Stack Overflow.

Díky,

Aaron Hallberg