Udostępnij za pośrednictwem

Migrowanie z usługi Travis do usługi Azure Pipelines

Azure DevOps Services

Ten przewodnik ułatwia migrację z usługi Travis do usługi Azure Pipelines. Pokazano w nim, jak przetłumaczyć konfigurację usługi Travis na konfigurację usługi Azure Pipelines.

Podstawowe różnice

Usługi Travis i Azure Pipelines różnią się na wiele sposobów, w tym:

  • Kompilacje Travis mają etapy, zadania i fazy, podczas gdy usługa Azure Pipelines zawiera kroki rozmieszczania i wykonywania w dowolnej kolejności lub grupowaniu.

  • Usługa Azure Pipelines umożliwia przechowywanie definicji zadań i kroków w oddzielnych plikach YAML w tym samym lub innym repozytorium. Takie podejście umożliwia udostępnianie kroków w wielu potokach.

  • Usługa Azure Pipelines zapewnia pełną obsługę kompilowania i testowania obrazów zarządzanych przez firmę Microsoft w systemach Linux, Windows i macOS. Aby uzyskać więcej informacji na temat hostowanych agentów, zobacz Agenci hostowani przez firmę Microsoft.

Wymagania wstępne

Język

Travis używa słowa kluczowego language , aby zidentyfikować wstępne środowisko kompilacji do skonfigurowania dla kompilacji. Aby na przykład wybrać Node.js 16.x:

.travis.yml

language: node_js
node_js:
  - 22

Agenci hostowani przez firmę Microsoft domyślnie zawierają zestawy SDK dla wielu języków. Aby użyć określonej wersji językowej, może być konieczne użycie zadania wyboru języka w celu skonfigurowania środowiska.

Aby na przykład wybrać Node.js 16.x:

azure-pipelines.yml

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

Mapowania języków

Słowo kluczowe language w Travis CI działa zarówno jako wersja używanych narzędzi językowych, jak i ukryty sygnał, że wiele kroków kompilacji jest wykonywanych. W usłudze Azure Pipelines określ polecenia, które chcesz uruchomić.

Oto przewodnik tłumaczenia ze słowa kluczowego language do poleceń wykonywanych automatycznie dla najczęściej używanych języków:

Język Polecenia
c
cpp		 ./configure
make
make install
csharp nuget restore [solution.sln]
msbuild /p:Configuration=Release [solution.sln]
clojure lein deps
lein test
go go get -t -v ./...
make lubgo test
java
groovy		 Gradle:
gradle assemble
gradle check

Maven:
mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V
mvn test -B

Ant:
ant test
node_js npm install lubnpm cilubyarn
npm test
objective-c
swift		 pod install lubbundle exec pod install
xcodebuild -scheme [scheme] build test \| xcpretty
perl cpanm --quiet --installdeps --notest .

Build.PL:
perl ./Build.pl
./Build test

Makefile.PL:
perl Makefile.PL
make test

Plik programu Make:
make test
php phpunit
python pip install -r requirements.txt
ruby bundle install --jobs=3 --retry=3
rake

Możesz włączyć mniej typowe języki, ale wymagają innego kroku instalacji zależności lub wykonania wewnątrz kontenera platformy Docker:

Język Polecenia
crystal docker run -v $(pwd):/src -w /src crystallang/crystal shards install
docker run -v $(pwd):/src -w /src crystallang/crystal crystal spec
d sudo wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list
sudo apt-get update
sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring
sudo apt-get update
sudo apt-get install dmd-compiler dub
dub test --compiler=dmd
dart wget https://dl-ssl.google.com/linux/linux_signing_key.pub -O - \| sudo apt-key add -
wget https://storage.googleapis.com/download.dartlang.org/linux/debian/dart_stable.list -O /etc/apt/sources.list.d/dart_stable.list
sudo apt-get update
sudo apt-get install dart
/usr/lib/dart/bin/pub get
/usr/lib/dart/bin/pub run test
erlang sudo apt-get install rebar
rebar get-deps
rebar compile
rebar skip_deps=true eunit
elixir sudo apt-get install elixir
mix local.rebar --force
mix local.hex --force
mix deps.get
mix test
haskell sudo apt-get install cabal-install
cabal install --only-dependencies --enable-tests
cabal configure --enable-tests
cabal build
cabal test
haxe sudo apt-get install haxe
yes \| haxelib install [hxml]
haxe [hxml]
julia sudo apt-get install julia
julia -e "using Pkg; Pkg.build(); end"
julia --check-bounds=yes -e "Pkg; Pkg.test(coverage=true); end"
nix docker run -v $(pwd):/src -w /src nixos/nix nix-build
perl6 sudo apt-get install rakudo
PERL6LIB=lib prove -v -r --exec=perl6 t/
rust curl -sSf https://sh.rustup.rs | sh -s -- -y
cargo build --verbose
cargo test --verbose
scala echo "deb https://repo.scala-sbt.org/scalasbt/debian /" | /etc/apt/sources.list.d/sbt.list
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
sudo apt-get update
sudo apt-get install sbt
sbt ++2.11.6 test
smalltalk docker run -v $(pwd):/src -w /src hpiswa/smalltalkci smalltalkci

Wybór wielu języków

Można również skonfigurować środowisko, które obsługuje tworzenie różnych aplikacji w wielu językach. Aby na przykład upewnić się, że środowisko kompilacji jest przeznaczone zarówno Node.JS 16.x, jak i Ruby 3.2 lub nowsze:

azure-pipelines.yml

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

Fazy

W usłudze Travis kroki są definiowane w stałym zestawie nazwanych faz, takich jak before_install lub before_script. Usługa Azure Pipelines nie ma nazwanych faz i kroków można grupować, nazwać i organizować w dowolny sposób dla potoku.

Na przykład:

.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

Alternatywnie kroki można grupować i opcjonalnie nazwać:

azure-pipelines.yml

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

Zadania równoległe

Travis zapewnia równoległość, umożliwiając definiowanie etapu, który jest grupą zadań wykonywanych równolegle. Kompilacja Travis może mieć wiele etapów; po zakończeniu wszystkich zadań na etapie rozpoczyna się następny etap.

Za pomocą usługi Azure Pipelines można wykonać każdy krok lub etap zależny od dowolnego innego kroku. W ten sposób można określić, które kroki są uruchamiane szeregowo i które mogą być uruchamiane równolegle. Dzięki temu można uruchamiać wiele kroków równolegle po zakończeniu jednego kroku, a następnie z powrotem do wentylatora za pomocą jednego kroku, który zostanie uruchomiony później. Ten model udostępnia opcje definiowania złożonych przepływów pracy w razie potrzeby. Na razie oto prosty przykład:

Ilustracja prostego wykonywania równoległego

Na przykład, aby uruchomić skrypt kompilacji, po zakończeniu uruchom testy jednostkowe i testy integracji równolegle, a po zakończeniu wszystkich testów spakuj artefakty, a następnie uruchom wdrożenie w środowisku przedprodukcyjnym:

.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

Zaawansowane wykonywanie równoległe

W usłudze Azure Pipelines masz więcej opcji i kontrolę nad sposobem organizowania potoku.

Na przykład zespół ma zestaw szybkich testów jednostkowych oraz inny zestaw i wolniejsze testy integracji. Zespół chce rozpocząć tworzenie pliku .ZIP dla wydania zaraz po zakończeniu lekcji, ponieważ zapewniają wysoką pewność, że kompilacja zapewnia dobry pakiet. Jednak przed wdrożeniem w środowisku przedprodukcyjnym chcą poczekać na zakończenie wszystkich testów:

Ilustracja zaawansowanego wykonywania równoległego

W usłudze Azure Pipelines mogą to zrobić w następujący sposób:

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

Ponowne użycie kroków

W usłudze Travis można użyć macierzy do uruchamiania wielu wykonań w ramach jednej konfiguracji. W usłudze Azure Pipelines można używać macierzy w taki sam sposób, ale można również zaimplementować ponowne użycie konfiguracji za pomocą szablonów.

Przykład: zmienna środowiskowa w macierzy

Jednym z najpopularniejszych sposobów uruchamiania kilku kompilacji z niewielkimi odchyleniami jest zmiana wykonywania przy użyciu zmiennych środowiskowych. Na przykład skrypt kompilacji może wyszukać obecność zmiennej środowiskowej i zmienić sposób kompilowania oprogramowania lub sposobu testowania oprogramowania.

Użyj macierzy, aby uruchomić konfigurację kompilacji kilka razy, raz dla każdej wartości w zmiennej środowiskowej. Na przykład uruchom dany skrypt trzy razy, za każdym razem z innym ustawieniem zmiennej środowiskowej:

.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)

Przykład: wersje językowe w macierzy

Innym typowym scenariuszem jest uruchomienie w kilku różnych środowiskach językowych. Funkcja Travis obsługuje niejawną definicję przy użyciu słowa kluczowego language , podczas gdy usługa Azure Pipelines oczekuje jawnego zadania definiującego sposób konfigurowania tej wersji językowej.

Możesz użyć opcji macierzy zmiennych środowiskowych w usłudze Azure Pipelines, aby włączyć macierz dla różnych wersji językowych. Można na przykład ustawić zmienną środowiskową w każdej zmiennej macierzy odpowiadającej wersji języka, której chcesz użyć, a następnie w pierwszym kroku użyć tej zmiennej środowiskowej, aby uruchomić zadanie konfiguracji języka:

.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

Przykład: Systemy operacyjne w macierzy

Często można również uruchamiać kompilacje w wielu systemach operacyjnych. Funkcja Travis obsługuje tę definicję przy użyciu słowa kluczowego os , a usługa Azure Pipelines umożliwia skonfigurowanie systemu operacyjnego przez wybranie puli do uruchomienia przy użyciu słowa kluczowego vmImage .

Można na przykład ustawić zmienną środowiskową w każdej zmiennej macierzy odpowiadającej obrazowi systemu operacyjnego, który ma być używany. Następnie należy ustawić pulę maszyn na ustawioną zmienną:

.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!

Obsługa powodzenia i niepowodzeń

Funkcja Travis umożliwia określenie kroków, które są uruchamiane w przypadku pomyślnego zakończenia kompilacji, za pomocą fazy after_success, lub gdy kompilacja kończy się niepowodzeniem, za pomocą fazy after_failure. Korzystając z usługi Azure Pipelines, można zdefiniować warunki powodzenia i niepowodzenia w oparciu o wynik dowolnego kroku, co umożliwia bardziej elastyczne i zaawansowane potoki.

.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()

Zaawansowana obsługa sukcesów i niepowodzeń

W usłudze Azure Pipelines można programować elastyczny zestaw zależności i warunków sterowania przepływem między zadaniami.
Zadania można skonfigurować tak, aby były uruchamiane na podstawie powodzenia lub niepowodzenia poprzednich zadań lub na podstawie zmiennych środowiskowych. Można nawet skonfigurować zadania tak, aby zawsze działały, niezależnie od powodzenia innych zadań.

Jeśli na przykład chcesz uruchomić skrypt, gdy kompilacja zakończy się niepowodzeniem, ale tylko wtedy, gdy jest uruchomiona jako kompilacja w gałęzi głównej:

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

Wstępnie zdefiniowane zmienne

Zarówno Travis, jak i Azure Pipelines ustawiają wiele zmiennych środowiskowych, aby ułatwić inspekcję i interakcję ze środowiskiem wykonawczym systemu CI.

W większości przypadków zmienna usługi Azure Pipelines jest zgodna ze zmienną środowiskową w usłudze Travis. Oto lista często używanych zmiennych środowiskowych w usłudze Travis i ich analogia w usłudze Azure Pipelines:

Travis Azure Pipelines opis
CI=true lub TRAVIS=true TF_BUILD=True Wskazuje, że kompilacja jest uruchomiona w systemie ciągłej integracji; przydatne w przypadku skryptów, które są również przeznaczone do uruchamiania lokalnego podczas programowania.
TRAVIS_BRANCH Kompilacje ciągłej integracji:
BUILD_SOURCEBRANCH

Kompilacje żądań ściągnięcia:
SYSTEM_PULLREQUEST_TARGETBRANCH		 Nazwa gałęzi, dla którego jest kolejkowana kompilacja, lub nazwa gałęzi, dla którego jest kierowane żądanie ściągnięcia.
TRAVIS_BUILD_DIR BUILD_SOURCESDIRECTORY Lokalizacja wyewidencjonowane źródło i domyślny katalog roboczy.
TRAVIS_BUILD_NUMBER BUILD_BUILDID Unikatowy identyfikator liczbowy dla wywołania bieżącej kompilacji.
TRAVIS_COMMIT Kompilacje ciągłej integracji:
BUILD_SOURCEVERSION		 Identyfikator zatwierdzenia, który jest obecnie kompilowany.
TRAVIS_COMMIT Kompilacje żądań ściągnięcia:
git rev-parse HEAD^2		 W przypadku kompilacji weryfikacji żądań ściągnięcia usługa Azure Pipelines ustawia BUILD_SOURCEVERSION na wynikowe zatwierdzenie scalania żądania ściągnięcia do głównego. To polecenie identyfikuje samo zatwierdzenie żądania ściągnięcia.
TRAVIS_COMMIT_MESSAGE BUILD_SOURCEVERSIONMESSAGE Komunikat dziennika tworzonego zatwierdzenia.
TRAVIS_EVENT_TYPE BUILD_REASON Przyczyna, dla której kompilacja jest w kolejce; mapa wartości znajduje się w poniższej tabeli "przyczyny kompilacji".
TRAVIS_JOB_NAME AGENT_JOBNAME Nazwa bieżącego zadania, jeśli zostanie określona.
TRAVIS_OS_NAME AGENT_OS System operacyjny, na którym działa zadanie; mapa wartości znajduje się w poniższej tabeli "systemy operacyjne".
TRAVIS_PULL_REQUEST Azure Repos:
SYSTEM_PULLREQUEST_PULLREQUESTID

GitHub:
SYSTEM_PULLREQUEST_PULLREQUESTNUMBER		 Numer żądania ściągnięcia, który wyzwolił tę kompilację. (W przypadku kompilacji usługi GitHub jest to unikatowy identyfikator, który nie jest numerem żądania ściągnięcia).
TRAVIS_PULL_REQUEST_BRANCH SYSTEM_PULLREQUEST_SOURCEBRANCH Nazwa gałęzi, z której pochodzi żądanie ściągnięcia.
TRAVIS_PULL_REQUEST_SHA Kompilacje żądań ściągnięcia:
git rev-parse HEAD^2		 W przypadku kompilacji weryfikacji żądań ściągnięcia usługa Azure Pipelines ustawia BUILD_SOURCEVERSION na wynikowe zatwierdzenie scalania żądania ściągnięcia do głównego. To polecenie identyfikuje samo zatwierdzenie żądania ściągnięcia.
TRAVIS_PULL_REQUEST_SLUG Nazwa rozwidlenia repozytorium, jeśli żądanie ściągnięcia pochodzi z rozwidlenia. W usłudze Azure Pipelines nie ma tego odpowiednika.
TRAVIS_REPO_SLUG BUILD_REPOSITORY_NAME Nazwa repozytorium, dla którego skonfigurowano tę kompilację.
TRAVIS_TEST_RESULT AGENT_JOBSTATUS Funkcja Travis ustawia tę wartość na 0 , jeśli wszystkie poprzednie kroki kończą się powodzeniem (zwróć wartość 0). W przypadku usługi Azure Pipelines sprawdź, czy AGENT_JOBSTATUS=Succeeded.
TRAVIS_TAG BUILD_SOURCEBRANCH Jeśli ta kompilacja jest umieszczana w kolejce w wyniku utworzenia tagu, ta wartość jest nazwą tego tagu. W przypadku usługi Azure Pipelines parametr BUILD_SOURCEBRANCH jest ustawiony na pełną nazwę odwołania usługi Git, na przykład refs/tags/tag_name.
TRAVIS_BUILD_STAGE_NAME Nazwa etapu w travisie. Jak widzieliśmy wcześniej, usługa Azure Pipelines obsługuje sterowanie przepływem przy użyciu zadań. Możesz odwołać się do .AGENT_JOBNAME

Przyczyny kompilacji:

Zmienna TRAVIS_EVENT_TYPE zawiera wartości mapowane na wartości udostępniane przez zmienną usługi Azure Pipelines BUILD_REASON :

Travis Azure Pipelines opis
push IndividualCI Kompilacja to ciągła kompilacja integracji z wypychania.
pull_request PullRequest Kompilacja została utworzona w kolejce w celu zweryfikowania żądania ściągnięcia.
api Manual Kompilacja została utworzona w kolejce przez interfejs API REST lub żądanie ręczne na stronie internetowej.
cron Schedule Zaplanowano kompilację.

Systemy operacyjne:

Zmienna TRAVIS_OS_NAME zawiera wartości mapowane na wartości udostępniane przez zmienną usługi Azure Pipelines AGENT_OS :

Travis Azure Pipelines opis
linux Linux Kompilacja jest uruchomiona w systemie Linux.
osx Darwin Kompilacja jest uruchomiona w systemie macOS.
windows Windows_NT Kompilacja jest uruchomiona w systemie Windows.

Aby uzyskać więcej informacji, zobacz wstępnie zdefiniowane zmienne środowiskowe.

Jeśli nie ma zmiennej dla potrzebnych danych, użyj komendy powłoki, aby je uzyskać. Na przykład dobrym zamiennikiem zmiennej środowiskowej zawierającej identyfikator zatwierdzenia skompilowanych żądań ściągnięcia jest uruchomienie polecenia git: git rev-parse HEAD^2.

Kompilowanie określonych gałęzi

Domyślnie zarówno Travis, jak i Azure Pipelines wykonują kompilacje ciągłej integracji we wszystkich gałęziach. Podobnie oba systemy umożliwiają ograniczenie tych kompilacji do określonych gałęzi. W usłudze Azure Pipelines lista gałęzi do kompilacji powinna znajdować się na include liście, a gałęzie , które nie mają być kompilowane, powinny znajdować się na liście wykluczania. Obsługiwane są symbole wieloznaczne.

Aby na przykład utworzyć tylko gałąź główną i te, które zaczynają się od słowa "releases":

.travis.yml

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

azure-pipelines.yml

trigger:
  branches:
    include:
    - main
    - releases*

Buforowanie danych wyjściowych

Usługa Travis obsługuje buforowanie zależności i pośrednie dane wyjściowe kompilacji, aby poprawić czas kompilacji. Usługa Azure Pipelines nie obsługuje buforowania danych wyjściowych kompilacji pośredniej, ale oferuje integrację z usługą Azure Artifacts na potrzeby magazynu zależności.

Moduły podrzędne Git

Travis i Azure Pipelines domyślnie rekursywnie klonują repozytoria git. To ustawienie domyślne oznacza, że agent klonuje podmoduły, co jest przydatne, ponieważ moduły podrzędne zwykle zawierają zależności. Jednak dodatkowe klonowanie zajmuje dodatkowy czas. Jeśli nie potrzebujesz zależności, wyłącz podmoduły klonowania:

.travis.yml

git:
  submodules: false

azure-pipelines.yml

checkout:
  submodules: false
  • Last updated on