Condividi tramite

Supporto per le distribuzioni sequenziali quando si usano controlli di blocco esclusivi

In questo sprint è stata estesa la funzionalità dei controlli di blocco esclusivi in Azure Pipelines per supportare le distribuzioni sequenziali. È ora possibile accodare più esecuzioni in un ambiente per consentire l'esecuzione di una sola di esse alla volta.

Per informazioni dettagliate, vedere le descrizioni delle funzionalità seguenti.

Azure Boards (Pannelli di Azure)

Azure Pipelines

Azure Boards (Pannelli di Azure)

La sezione sviluppo in un elemento di lavoro mostra l'elenco dei commit e delle richieste pull pertinenti. È possibile visualizzare l'autore del commit o della richiesta pull insieme all'ora associata. Con questo aggiornamento è stato risolto un problema relativo all'avatar dell'autore visualizzato in modo non corretto nella visualizzazione.

Azure Pipelines

Supporto per distribuzioni sequenziali anziché più recenti solo quando si usano controlli di blocco esclusivi

Nelle pipeline YAML i controlli vengono usati per controllare l'esecuzione delle fasi sulle risorse protette. Uno dei controlli comuni che è possibile usare è un controllo di blocco esclusivo. Questo controllo consente solo un'esecuzione singola dalla pipeline. Quando più esecuzioni tentano di eseguire la distribuzione in un ambiente contemporaneamente, il controllo annulla tutte le esecuzioni precedenti e consente la distribuzione dell'esecuzione più recente.

L'annullamento delle esecuzioni precedenti è un buon approccio quando le versioni sono cumulative e contengono tutte le modifiche al codice delle esecuzioni precedenti. Esistono tuttavia alcune pipeline in cui le modifiche al codice non sono cumulative. Con questa nuova funzionalità, è possibile scegliere di consentire a tutte le esecuzioni di procedere e distribuirlo in sequenza in un ambiente oppure mantenere il comportamento precedente di annullare le esecuzioni precedenti e consentire solo l'ultima versione. È possibile specificare questo comportamento usando una nuova proprietà denominata lockBehavior nel file YAML della pipeline. Il valore sequential implica che tutte le esecuzioni acquisiscono il blocco in modo sequenziale alla risorsa protetta. Un valore di runLatest implica che solo l'esecuzione più recente acquisisce il blocco della risorsa.

Per verificare i blocchi esclusivi con le distribuzioni sequential o runLatest, seguire questa procedura:

  1. Abilitare il controllo di blocco esclusivo nell'ambiente (o in un'altra risorsa protetta).
  2. Nel file YAML per la pipeline specificare una nuova proprietà denominata lockBehavior. Questa opzione può essere specificata per l'intera pipeline o per una determinata fase:

Impostata su una fase:

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

Impostare nella pipeline:

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

Se non si specifica un lockBehavior, si presuppone che sia runLatest.

Supporto per la versione di Quebec di ServiceNow

Azure Pipelines ha un'integrazione esistente con ServiceNow. L'integrazione si basa su un'app in ServiceNow e un'estensione in Azure DevOps. L'app è stata aggiornata per lavorare con la versione di Quebec di ServiceNow. Le pipeline classiche e YAML ora funzionano con Quebec. Per assicurarsi che questa integrazione funzioni, eseguire l'aggiornamento alla nuova versione dell'app (4.188.0) dall'archivio di Service Now. Per altre informazioni, vedere Integrare con ServiceNow Change Management.

Modifica dei criteri di preinstallazione di .NET SDK negli agenti Windows e macOS ospitati da Microsoft

Recentemente è stata annunciata una modifica dei criteri di preinstallazione di .NET SDK negli agenti Ubuntu ospitati da Microsoft. Ora stiamo apportando la stessa modifica per gli agenti Windows e macOS ospitati da Microsoft.

Attualmente, vengono installate tutte le versioni disponibili e supportate di .NET SDK (2.1.x, 3.1.x, 5.0.x) negli agenti Windows e macOS ospitati da Microsoft. Questo approccio verrà modificato a favore dell'installazione della versione patch più recente per ogni versione delle funzionalità. Questa modifica viene apportata per fornire più spazio libero e per le nuove richieste di strumenti.

Significato

La versione dell'SDK è costituita dalle parti seguenti: x.y.znn. z è la versione della funzionalità ed nn è la versione patch. Ad esempio, per la versione 2.1.302, la versione della funzionalità è 3 e 02 è la versione patch. In base al nuovo approccio, verrà installata solo la versione patch più recente per ogni versione delle funzionalità, ad esempio solo 2.1.302 verrà installata per la versione 2.1.3x, solo 2.1.403 per 2.1.4x e così via. Tutte le versioni di .NET SDK che non sono le versioni più recenti delle patch verranno rimosse dalle immagini di Windows e macOS il 6 settembre. Questa modifica influisce su tutte le versioni di Windows e macOS negli agenti ospitati da Microsoft.

Data di destinazione

La distribuzione delle immagini aggiornate inizierà il 6 settembre e richiederà 3-4 giorni.

Possibile impatto

Se si utilizza un file global.json, la compilazione sarà influenzata nei seguenti casi:

La compilazione avrà esito negativo se il file global.json contiene la rollForward: disable proprietà e una versione dell'SDK che non è la versione più recente della patch. Per esempio:

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

La versione di .NET SDK verrà modificata automaticamente alla patch più recente se il file global.json contiene la rollForward: patch proprietà . Per esempio:

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

Se il rollForward campo non è specificato nel file global.json, non verrà apportata alcuna modifica. Viene usato il livello di patch installato più recente.

Se è necessario usare una versione esatta di .NET SDK che non è la patch più recente, usare l'attivitàUseDotNet per installarla come parte della compilazione:

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

Modifiche alle attività PublishBuildArtifacts e DownloadBuildArtifacts

Azure Pipelines supporta due set di attività per la pubblicazione o il download di artefatti. PublishPipelineArtifact e DownloadPipelineArtifact sono le attività più recenti e consigliate per eseguire questi passaggi.

PublishBuildArtifacts e DownloadBuildArtifacts sono le attività precedenti e non hanno le stesse ottimizzazioni di prestazioni e archiviazione presenti nelle attività PipelineArtifact corrispondenti. Queste attività meno recenti presentavano anche limitazioni di scalabilità in termini di modalità di implementazione. Alcuni dei nostri clienti più grandi hanno superato questi limiti.

Anche se si vuole che tutti i clienti passino alle attività PipelineArtifact, è stato necessario eseguire alcuni passaggi per affrontare la scalabilità delle attività BuildArtifact meno recenti. Nell'ambito di un aggiornamento recente per migliorare la scalabilità, gli agenti di Azure Pipelines ora interagiranno direttamente con gli artefatti di compilazione tramite i domini dell'archivio BLOB (anziché il routing tramite domini tfs). Queste pipeline inizieranno ad accedere agli indirizzi IP e ai domini che sono stati a lungo presenti nell'elenco di indirizzi consentiti di Azure DevOps, ma potrebbero non essere stati usati prima da pipeline specifiche.

L'implementazione aggiornata delle attività BuildArtifact richiede un aggiornamento dell'agente, che deve essere eseguito automaticamente a meno che gli aggiornamenti automatici non siano stati disabilitati specificamente o che i firewall non siano configurati correttamente.

Se gli agenti sono in esecuzione in ambienti firewall che non seguono le istruzioni collegate, potrebbero verificarsi errori durante l'aggiornamento dell'agente o nelle attività PublishBuildArtifacts o DownloadBuildArtifacts fino a quando la configurazione del firewall non viene corretta.

Un sintomo comune di questo problema è costituito da errori improvvisi relativi agli handshake ssl o agli errori di download degli artefatti, in genere nei pool di distribuzione destinati alle definizioni di Release Management. In alternativa, se gli aggiornamenti dell'agente sono stati bloccati, è possibile osservare che le versioni sono in attesa di un agente nel pool che non arriva mai o che gli agenti diventano offline a metà del processo di aggiornamento (questo è correlato agli ambienti che bloccano erroneamente il CDN dell'agente).

Passaggi successivi

Annotazioni

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Aaron Hallberg

  • Last updated on