Eseguire la migrazione da Travis ad Azure Pipelines

Servizi di Azure DevOps

Questa guida consente di eseguire la migrazione da Travis ad Azure Pipelines. Illustra come convertire una configurazione Travis in una configurazione di Azure Pipelines.

Differenze principali

Travis e Azure Pipelines differiscono in molti modi, tra cui:

• Le compilazioni travis hanno fasi, processi e fasi, mentre Azure Pipelines prevede passaggi disposti ed eseguiti in qualsiasi ordine o raggruppamento scelto.

• Azure Pipelines consente di archiviare le definizioni e i passaggi dei processi in file YAML separati nello stesso repository o in un repository diverso. Questo approccio consente di condividere i passaggi tra più pipeline.

• Azure Pipelines offre pieno supporto alla costruzione e sperimentazione sui sistemi operativi Linux, Windows e macOS gestiti da Microsoft. Per altre informazioni sugli agenti ospitati, vedere Agenti ospitati da Microsoft.

Prerequisiti

• Un account GitHub in cui è possibile creare un repository. Crearne una gratuitamente.
• Un'organizzazione di Azure DevOps. Crearne una gratuitamente. Se il team ha già un'organizzazione di Azure DevOps, assicurarsi di essere un amministratore del progetto Azure DevOps che si vuole usare.
• Possibilità di eseguire pipeline negli agenti ospitati da Microsoft. È possibile acquistare un job parallelo oppure richiedere un livello gratuito.
• Conoscenza di base di Azure Pipelines. Se non si ha familiarità con Azure Pipelines, vedere gli articoli seguenti per altre informazioni su Azure Pipelines e su come funziona prima di avviare la migrazione:
  • Crea la tua prima pipeline
  • Concetti chiave per i nuovi utenti di Azure Pipelines

Lingua

Travis usa la language parola chiave per identificare l'ambiente di compilazione prerequisito da configurare per il tuo progetto. Ad esempio, per selezionare Node.js 16.x:

.travis.yml

language: node_js
node_js:
  - 22

Gli agenti ospitati da Microsoft includono gli SDK per molte lingue per impostazione predefinita. Per usare una versione specifica della lingua, potrebbe essere necessario usare un'attività di selezione della lingua per configurare l'ambiente.

Ad esempio, per selezionare Node.js 16.x:

azure-pipelines.yml

steps:
- task: UseNode@1
  inputs:
    version: '22.x'

Associazioni linguistiche

La language parola chiave in Travis CI funziona sia come versione degli strumenti di linguaggio da usare che come segnale implicito che vengono eseguiti molti passaggi di compilazione. In Azure Pipelines specificare i comandi da eseguire.

Ecco una guida alla traduzione dalla language parola chiave ai comandi eseguiti automaticamente per le lingue più usate:

È possibile abilitare linguaggi meno comuni, ma richiedono un altro passaggio di installazione delle dipendenze o un'esecuzione all'interno di un contenitore Docker:

Selezioni di più lingue

È anche possibile configurare un ambiente che supporta la creazione di applicazioni diverse in più lingue. Ad esempio, per garantire che l'ambiente di compilazione sia destinato a sia Node.JS 16.x, che Ruby 3.2 o versione superiore.

azure-pipelines.yml

steps:
- task: UseNode@1
  inputs:
    version: '8.x'
- task: UseRubyVersion@0
  inputs:
    versionSpec: '>= 3.2'

Fasi

In Travis i passaggi vengono definiti in un set fisso di fasi denominate, ad before_install esempio o before_script. Azure Pipelines non ha fasi predefinite e i passaggi possono essere raggruppati, nominati e organizzati in qualsiasi modo che abbia senso per la pipeline.

Ad esempio:

.travis.yml

before_install:
    - npm install -g bower
install:
    - npm install
    - bower install
script:
    - npm run build
    - npm test

azure-pipelines.yml

steps:
- script: npm install -g bower
- script: npm install
- script: bower install
- script: npm run build
- script: npm test

In alternativa, i passaggi possono essere raggruppati e facoltativamente denominati:

azure-pipelines.yml

steps:
- script: |
    npm install -g bower
    npm install
    bower install
  displayName: 'Install dependencies'
- script: npm run build
- script: npm test

Attività in parallelo

Travis fornisce il parallelismo consentendo di definire una fase, ovvero un gruppo di processi eseguiti in parallelo. Una costruzione Travis può avere più fasi; una volta completati tutti i processi in una fase, viene avviata la fase successiva.

Con Azure Pipelines è possibile rendere ogni passaggio o fase dipendente da qualsiasi altro passaggio. In questo modo, è possibile specificare i passaggi eseguiti in modo seriale e quali possono essere eseguiti in parallelo. Quindi è possibile aprire un ventaglio con più passaggi eseguiti in parallelo dopo il completamento di un passaggio, per poi richiudere il ventaglio con un singolo passaggio che viene eseguito successivamente. Questo modello offre opzioni per definire flussi di lavoro complessi, se necessario. Per il momento, ecco un semplice esempio:

Ad esempio, per eseguire uno script di compilazione, al termine dell'esecuzione degli unit test e dei test di integrazione in parallelo e al termine di tutti i test, creare un pacchetto degli artefatti e quindi eseguire la distribuzione in fase di pre-produzione:

.travis.yml

jobs:
  include:
  - stage: build
    script: ./build.sh
  - stage: test
    script: ./test.sh unit_tests
  - script: ./test.sh integration_tests
  - stage: package
    script: ./package.sh
  - stage: deploy
    script: ./deploy.sh pre_prod

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: test1
  dependsOn: build
  steps:
  - script: ./test.sh unit_tests
- job: test2
  dependsOn: build
  steps:
  - script: ./test.sh integration_tests
- job: package
  dependsOn:
  - test1
  - test2
  script: ./package.sh
- job: deploy
  dependsOn: package
  steps:
  - script: ./deploy.sh pre_prod

Esecuzione parallela avanzata

In Azure Pipelines sono disponibili altre opzioni e si controlla il modo in cui si orchestra la pipeline.

Ad esempio, un team ha un set di test unitari a esecuzione rapida e un altro set di test di integrazione più lenti. Il team vuole iniziare a creare il file .ZIP per un rilascio non appena le unità sono completate perché forniscono un'elevata certezza che il build offra un buon pacchetto. Ma prima di eseguire la distribuzione in fase di pre-produzione, vogliono attendere il superamento di tutti i test:

In Azure Pipelines è possibile farlo in questo modo:

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: test1
  dependsOn: build
  steps:
  - script: ./test.sh unit_tests
- job: test2
  dependsOn: build
  steps:
  - script: ./test.sh integration_tests
- job: package
  dependsOn: test1
  script: ./package.sh
- job: deploy
  dependsOn:
  - test1
  - test2
  - package
  steps:
  - script: ./deploy.sh pre_prod

Riutilizzo dei passaggi

In Travis è possibile usare matrici per eseguire più esecuzioni in una singola configurazione. In Azure Pipelines è possibile usare matrici nello stesso modo, ma è anche possibile implementare il riutilizzo della configurazione con i modelli.

Esempio: Variabile di ambiente in una matrice

Uno dei modi più comuni per eseguire diverse compilazioni con una leggera variazione consiste nel modificare l'esecuzione usando le variabili di ambiente. Ad esempio, lo script di compilazione può cercare la presenza di una variabile di ambiente e modificare la modalità di compilazione del software o il modo in cui testa il software.

Usare una matrice per eseguire una configurazione di compilazione più volte, una volta per ogni valore nella variabile di ambiente. Ad esempio, eseguire uno script specificato tre volte, ogni volta con un'impostazione diversa per una variabile di ambiente:

.travis.yml

os: osx
env:
  jobs:
  - MY_ENVIRONMENT_VARIABLE: 'one'
  - MY_ENVIRONMENT_VARIABLE: 'two'
  - MY_ENVIRONMENT_VARIABLE: 'three'
script: echo $MY_ENVIRONMENT_VARIABLE

azure-pipelines.yml

pool:
  vmImage: 'macOS-latest'
strategy:
  matrix:
    set_env_to_one:
      MY_ENVIRONMENT_VARIABLE: 'one'
    set_env_to_two:
      MY_ENVIRONMENT_VARIABLE: 'two'
    set_env_to_three:
      MY_ENVIRONMENT_VARIABLE: 'three'
steps:
- script: echo $(MY_ENVIRONMENT_VARIABLE)

Esempio: Versioni del linguaggio in una matrice

Un altro scenario comune consiste nello svolgere operazioni in diversi ambienti linguistici. Travis supporta una definizione implicita usando la language parola chiave , mentre Azure Pipelines prevede un'attività esplicita per definire come configurare tale versione del linguaggio.

È possibile usare le opzioni della matrice di variabili di ambiente in Azure Pipelines per abilitare una matrice per versioni diverse del linguaggio. Ad esempio, è possibile impostare una variabile di ambiente in ogni variabile matrice corrispondente alla versione del linguaggio che si vuole usare, quindi nel primo passaggio usare tale variabile di ambiente per eseguire l'attività di configurazione della lingua:

.travis.yml

os: linux
jobs:
  include:
  - rvm: 2.3.7
  - rvm: 2.4.4
  - rvm: 2.5.1
script: ruby --version

azure-pipelines.yml

vmImage: 'ubuntu-latest'
strategy:
  matrix:
    ruby 2.3:
      ruby_version: '2.3.7'
    ruby 2.4:
      ruby_version: '2.4.4'
    ruby 2.5:
      ruby_version: '2.5.1'
steps:
- task: UseRubyVersion@0
  inputs:
    versionSpec: $(ruby_version)
- script: ruby --version

Esempio: Sistemi operativi all'interno di una matrice

È anche comune eseguire compilazioni in più sistemi operativi. Travis supporta questa definizione usando la os parola chiave , mentre Azure Pipelines consente di configurare il sistema operativo selezionando il pool in cui eseguire usando la vmImage parola chiave .

Ad esempio, è possibile impostare una variabile di ambiente in ogni variabile di matrice che corrisponde all'immagine del sistema operativo che si vuole usare. Imposta quindi il pool di macchine sulla variabile impostata:

.travis.yml

jobs:
  include:
  - os: linux
  - os: windows
  - os: osx
script: echo Hello, world!

azure-pipelines.yml

strategy:
  matrix:
    linux:
      imageName: 'ubuntu-latest'
    mac:
      imageName: 'macOS-latest'
    windows:
      imageName: 'windows-latest'

pool:
  vmImage: $(imageName)

steps:
- script: echo Hello, world!

Gestione del successo e del fallimento

Travis consente di specificare i passaggi eseguiti quando la compilazione ha esito positivo, usando la after_success fase o quando la compilazione ha esito negativo, usando la after_failure fase . Usando Azure Pipelines, è possibile definire condizioni di esito positivo e negativo in base al risultato di qualsiasi passaggio, che consente pipeline più flessibili e potenti.

.travis.yml

build: ./build.sh
after_success: echo Success 
after_failure: echo Failed 

azure-pipelines.yml

steps:
- script: ./build.sh
- script: echo Success
  condition: succeeded()
- script: echo Failed
  condition: failed()

Gestione avanzata degli errori e delle operazioni riuscite

In Azure Pipelines è possibile programmare un set flessibile di dipendenze e condizioni per il controllo del flusso tra processi.
È possibile configurare i processi per l'esecuzione in base all'esito positivo o negativo dei processi precedenti o in base alle variabili di ambiente. È anche possibile configurare i processi per l'esecuzione sempre, indipendentemente dall'esito positivo di altri processi.

Ad esempio, se si vuole eseguire uno script quando la compilazione ha esito negativo, ma solo se è in esecuzione come compilazione nel ramo principale:

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: alert
  dependsOn: build
  condition: and(failed(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  steps:
  - script: ./sound_the_alarms.sh

Variabili predefinite

Sia Travis che Azure Pipelines impostano più variabili di ambiente per facilitare l'ispezione e l'interazione con l'ambiente di esecuzione del sistema CI.

Nella maggior parte dei casi, una variabile di Azure Pipelines corrisponde alla variabile di ambiente in Travis. Di seguito è riportato un elenco delle variabili di ambiente comunemente usate in Travis e delle relative analogie in Azure Pipelines:

Motivi di compilazione:

La TRAVIS_EVENT_TYPE variabile contiene valori che eseguono il mapping ai valori forniti dalla variabile Azure Pipelines BUILD_REASON :

Sistemi operativi:

La TRAVIS_OS_NAME variabile contiene valori che eseguono il mapping ai valori forniti dalla variabile Azure Pipelines AGENT_OS :

Per altre informazioni, vedere Variabili di ambiente predefinite.

Se non è disponibile alcuna variabile per i dati necessari, usare un comando shell per ottenerlo. Ad esempio, un buon sostituto di una variabile di ambiente contenente l'ID commit della richiesta pull compilata consiste nell'eseguire un comando Git: git rev-parse HEAD^2.

Creazione di rami specifici

Per impostazione predefinita, travis e Azure Pipelines eseguono compilazioni CI in tutti i rami. Analogamente, entrambi i sistemi consentono di limitare queste compilazioni a rami specifici. In Azure Pipelines l'elenco dei rami da compilare deve essere elencato nell'elenco include e i rami da non compilare devono essere elencati nell'elenco di esclusione. Sono supportati caratteri jolly.

Ad esempio, per creare solo il ramo principale e quelli che iniziano con la parola «releases»:

.travis.yml

branches:
  only:
  - main
  - /^releases.*/

azure-pipelines.yml

trigger:
  branches:
    include:
    - main
    - releases*

Caching dell'output

Travis supporta la memorizzazione nella cache delle dipendenze e dell'output di compilazione intermedio per migliorare i tempi di costruzione. Azure Pipelines non supporta la memorizzazione nella cache dell'output intermedio della compilazione, ma offre l'integrazione con Azure Artifacts per l'archiviazione delle dipendenze.

Moduli secondari Git

Travis e Azure Pipelines clonano entrambi i repository Git in modo ricorsivo per impostazione predefinita. Questa impostazione predefinita indica che l'agente clona i moduli secondari, utile perché i moduli secondari in genere contengono dipendenze. Tuttavia, la clonazione aggiuntiva richiede tempo aggiuntivo. Se non sono necessarie le dipendenze, disabilitare la clonazione dei moduli secondari:

.travis.yml

git:
  submodules: false

azure-pipelines.yml

checkout:
  submodules: false