Travis から Azure Pipelines への移行

Azure DevOps サービス

このガイドは、 Travis から Azure Pipelines への移行に役立ちます。 Travis 構成を Azure Pipelines 構成に変換する方法を示します。

主な相違点

Travis と Azure Pipelines は、次のようなさまざまな点で異なります。

• Travis ビルドには ステージ、 ジョブ、 フェーズがあります。一方、Azure Pipelines には、任意の順序またはグループ化で配置および実行する手順があります。

• Azure Pipelines を使用すると、ジョブ定義とステップを同じリポジトリまたは別のリポジトリ内の個別の YAML ファイルに格納できます。 この方法を使用すると、複数のパイプライン間でステップを共有できます。

• Azure Pipelines は、Microsoft 管理の Linux、Windows、macOS イメージでのビルドとテストを完全にサポートします。 ホストされるエージェントの詳細については、「Microsoft によってホストされるエージェント」を参照してください。

[前提条件]

• リポジトリを作成できる GitHub アカウント。 無料で作成できます。
• Azure DevOps 組織。 無料で作成できます。 チームに既に Azure DevOps 組織がある場合は、使用する Azure DevOps プロジェクトの管理者であることを確認してください。
• Microsoft がホストするエージェントでパイプラインを実行する機能。 並列ジョブを購入するか、無料サービス レベルを要求してください。
• Azure Pipelines の基本的な知識。 Azure Pipelines を初めて使用する場合は、移行を開始する前に、Azure Pipelines とそのしくみについて詳しくは、次の記事をご覧ください。
  • 最初のパイプラインを作成する
  • 新しい Azure Pipelines ユーザー向けの主要な概念

Language

Travis では、language キーワードを使用して、ビルドに応じて設定する前提条件のビルド環境を特定します。 たとえば、Node.js 16.x を選択するには、次のようにします。

.travis.yml

language: node_js
node_js:
  - 22

Microsoft がホストするエージェント には、既定で多くの言語の SDK が含まれています。 特定の言語バージョンを使用するには、 言語選択タスク を使用して環境を設定する必要がある場合があります。

たとえば、Node.js 16.x を選択するには、次のようにします。

azure-pipelines.yml

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

言語の対応付け

Travis CI の language キーワードは、使用する言語ツールのバージョンと、多くのビルド ステップが実行される暗黙的なシグナルの両方として機能します。 Azure Pipelines では、実行するコマンドを指定します。

次に、最もよく使用される言語について、自動的に実行される language キーワードからコマンドへの翻訳ガイドを示します。

あまり一般的でない言語を有効にできますが、Docker コンテナー内で別の依存関係のインストール手順または実行が必要です。

複数の言語の選択

複数の言語で異なるアプリケーションのビルドをサポートする環境を構成することもできます。 たとえば、次のようにすると、ビルド環境は Node.JS 16.x と Ruby 3.2 以降の両方をターゲットにするようになります。

azure-pipelines.yml

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

フェーズ

Travis では、ステップは before_install や before_script のような名前付きフェーズの固定されたセットで定義されます。 Azure Pipelines には名前付きフェーズがありません。ステップは、パイプラインにとって意味のある方法であれば、どのようにもグループ化、名前付け、編成できます。

次に例を示します。

.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

または、ステップをグループ化し、必要に応じて前を付けることもできます。

azure-pipelines.yml

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

並列ジョブ

Travis は、並列で実行されるジョブのグループであるステージを定義することで並列処理を実現します。 Travis ビルドには、複数のステージを含めることができます。ステージ内のすべてのジョブが完了すると、次のステージが開始されます。

Azure Pipelines では、各ステップまたはステージを別のステップに依存させることができます。 この方法では、順次実行するステップと、並列で実行できるステップを指定します。 そのため、1 つのステップが完了した後に、並列での複数のステップ実行にファン アウトし、その後実行される 1 つのステップにファン インできます。 このモデルには、複雑なワークフローを必要に応じて定義するオプションがあります。 ここでは、簡単な例を示します。

たとえば、次に示すように、ビルド スクリプトを実行し、その完了時に単体テストと統合テストの両方を並列で実行し、すべてのテストが完了したら成果物をパッケージ化し、実稼働前環境へのデプロイを実行します。

.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

高度な並列実行

Azure Pipelines には、多くのオプションがあり、パイプラインの編成方法を制御できます。

たとえば、あるチームには一連の高速実行単体テストと、別の一連の低速な統合テストがあるとします。 そのチームは、ビルドが良好なパッケージを提供するという高い信頼度を示しているため、ユニットの完了直後にリリース用の .ZIP ファイルの作成を開始したいと考えています。 ただし、実稼働前環境にデプロイする前に、すべてのテストに合格するまで待つ必要があります。

Azure Pipelines では、これを次のように実行できます。

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

ステップの再利用

Travis では、マトリックスを使用すると、複数の実行を 1 つの構成で実行できます。 Azure Pipelines では、同じようにマトリックスを使用できますが、テンプレートを使用して構成の再利用を実装することもできます。

例: マトリックスの環境変数

複数のビルドをわずかなバリエーションで実行する最も一般的な方法の 1 つは、環境変数を使用して実行を変更することです。 たとえば、ビルド スクリプトでは、環境変数の存在を検索し、ソフトウェアのビルド方法やソフトウェアのテスト方法を変更できます。

マトリックスを使用して、環境変数の値ごとに 1 回、ビルド構成を複数回実行します。 たとえば、特定のスクリプトを 3 回実行し、そのたびに環境変数に対して異なる設定を行います。

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

例: マトリックスの言語バージョン

もう 1 つの一般的なシナリオは、異なる複数の言語環境に対する実行です。 Travis では、language キーワードを使用した暗黙的な定義がサポートされていますが、Azure Pipelines では、その言語バージョンの構成方法を定義する明示的なタスクが必要です。

Azure Pipelines の環境変数マトリックス オプションを使用すると、さまざまな言語バージョンのマトリックスを有効にできます。 たとえば、使用する言語バージョンに対応する環境変数を各マトリックス変数に設定して、最初の手順で言語構成タスクを実行するために、その環境変数を使用できます。

.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

例: マトリックス内のオペレーティング システム

複数のオペレーティング システムでビルドを実行することも一般的です。 Travis では、この定義は os キーワードの使用によってサポートされますが、Azure Pipelines では、vmImage キーワードを使用して実行するプールを選択することでオペレーティング システムを構成できます。

たとえば、各マトリックス変数に使用するオペレーティング システム イメージに対応する環境変数を設定できます。 次に、設定した変数にマシン プールを設定します。

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

成功と失敗の処理

Travis では、after_success フェーズを使用して、ビルドが成功したとき、after_failure フェーズを使用して、またはビルドが失敗したときに実行する手順を指定できます。 Azure Pipelines を使用すると、任意の手順の結果に基づいて成功と失敗の条件を定義できます。これにより、より柔軟で強力なパイプラインが可能になります。

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

高度な成功と失敗の処理

Azure Pipelines では、ジョブ間のフロー制御のために柔軟な依存関係と条件のセットをプログラミングできます。
ジョブは、前のジョブの成功または失敗に基づいて実行するように構成することも、環境変数に基づいて実行するように構成することもできます。 別のジョブの成否に関係なく、常に実行されるようにジョブを構成することもできます。

たとえば、ビルドが失敗したときにスクリプトを実行する必要があるが、メイン ブランチでビルドとして実行されている場合に限定するには、次のようにします。

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

事前定義済み変数

Travis と Azure Pipelines の両方で、CI システムの実行環境の検査と操作に役立つ複数の環境変数を設定します。

ほとんどの場合、Azure Pipelines 変数は Travis の環境変数と一致します。 次に、Travis でよく使用される環境変数と、Azure Pipelines で類似するもののリストを示します。

ビルドの理由:

TRAVIS_EVENT_TYPE 変数には、Azure Pipelines の BUILD_REASON 変数によって提供される値にマップされる値が含まれています。

オペレーティング システム:

TRAVIS_OS_NAME 変数には、Azure Pipelines の AGENT_OS 変数によって提供される値にマップされる値が含まれています。

詳細については、「 Predefined 環境変数を参照してください。

必要なデータの変数がない場合は、シェル コマンドを使用して取得します。 たとえば、ビルド中の pull request のコミット ID を含む環境変数の代わりに、git コマンド ( git rev-parse HEAD^2) を実行することをお勧めします。

特定のブランチのビルド

既定では、Travis と Azure Pipelines は、どちらもすべてのブランチで CI ビルドを実行します。 同様に、どちらのシステムでも、そうしたビルドを特定のブランチに制限できます。 Azure Pipelines では、ビルドするブランチのリストを include リストにリストする必要があり、ビルドしないブランチを `exclude リストにストする必要があります。 ワイルドカードを利用できます。

たとえば、メイン ブランチと "releases" という単語で始まるブランチのみをビルドする場合は、次のようにします。

.travis.yml

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

azure-pipelines.yml

trigger:
  branches:
    include:
    - main
    - releases*

出力キャッシュ

Travis では、ビルド時間を短縮するために、依存関係と中間ビルド出力のキャッシュがサポートされています。 Azure Pipelines では中間ビルド出力のキャッシュはサポートされていませんが、依存関係ストレージのために Azure Artifacts との統合を提供しています。

Git サブモジュール

Travis と Azure Pipelines の両方で、Git リポジトリが既定で再帰的に複製されます。 この既定の設定は、エージェントがサブモジュールを複製することを意味します。サブモジュールには通常、依存関係が含まれているので便利です。 ただし、余分な複製には時間がかかります。 依存関係が不要な場合は、サブモジュールの複製を無効にします。

.travis.yml

git:
  submodules: false

azure-pipelines.yml

checkout:
  submodules: false