Jenkins から Azure Pipelines への移行

Azure DevOps サービス

オープンソースの自動化サーバーである Jenkins は、従来、企業が独自のデータ センターにインストールし、オンプレミスで管理します。 多くのプロバイダーは、マネージド Jenkins ホスティングも提供しています。

または、Azure Pipelines はクラウド ネイティブの継続的インテグレーション パイプラインです。 クラウドでホストされているマルチステージ パイプラインとビルド エージェント Azure Virtual Machines の管理を提供します。

また、Azure Pipelines には、コードを保持し、エンタープライズ データ センター内でビルドする必要があるコンプライアンスやセキュリティに関する懸念があるお客様向けに、 Azure DevOps Server で完全にオンプレミスのオプションが用意されています。

さらに、Azure Pipelines では、ハイブリッド クラウドモデルとオンプレミス モデルがサポートされています。 Azure Pipelines では、ビルドとリリースのオーケストレーションを管理し、クラウドとオンプレミスの両方でビルド エージェントを有効にすることができます。

この記事では、Jenkins パイプライン構成を Azure Pipelines に変換するためのガイドを提供します。 コンテナー ベースのビルドの移動とビルド エージェントの選択、環境変数のマッピング、ビルド パイプラインの成功と失敗の処理方法に関する情報が含まれています。

コンフィギュレーション

Jenkins 宣言型パイプラインから Azure Pipelines YAML 構成への使い慣れた移行が見つかります。 この 2 つは概念的に似ています。"コードとしての構成" をサポートし、バージョン管理システムに構成を確認できます。 ただし、Jenkins とは異なり、Azure Pipelines は業界標準の YAML を使用してビルド パイプラインを構成します。

Jenkins と Azure Pipelines の概念と構成方法は似ています。 Jenkinsfile にはビルド プロセスの 1 つ以上の ステージ が一覧表示され、それぞれに順番に実行される 1 つ以上の ステップ が含まれています。 たとえば、"ビルド" ステージでは、タスクを実行してビルド時の依存関係をインストールし、コンパイル手順を実行できます。 "テスト" ステージでは、ビルド ステージで生成されたバイナリに対してテスト ハーネスを呼び出すことができます。

例えば次が挙げられます。

Jenkinsfile

pipeline {
    agent none
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

jenkinsfile は、各ステージに対応するジョブと、各 ジョブ で実行する手順を含む Azure Pipelines YAML 構成に簡単に変換できます。

azure-pipelines.yml

jobs:
- job: Build
  steps:
  - script: npm install
  - script: npm run build
- job: Test
  steps:
  - script: npm test

コンテナベースのビルド

ビルド パイプラインでコンテナーを使用すると、パイプラインに必要な正確な依存関係が既に構成されている Docker イメージ内でビルドおよびテストできます。 これにより、より多くのソフトウェアをインストールしたり、環境を構成したりするビルド手順を含める必要ができなくなります。 Jenkins と Azure Pipelines の両方で、コンテナー ベースのビルドがサポートされています。

さらに、Jenkins と Azure Pipelines の両方で、docker に対する -v フラグを使用して、ホスト エージェント上のビルド ディレクトリをコンテナー ボリュームと共有できます。 これにより、同じソースを使用して同じ出力ディレクトリに書き込むことができる複数のビルド ジョブを連結できます。 これは、スタックでさまざまなテクノロジを使用する場合に特に便利です。.NET Core コンテナーと TypeScript コンテナーを使用してフロントエンドを使用してバックエンドを構築できます。

たとえば、Ubuntu 22.04 ("Jammy") コンテナーでビルドを実行するには、Ubuntu 24.04 ("Noble") コンテナーでテストを実行します。

Jenkinsfile

pipeline {
    agent none
    stages {
        stage('Build') {
            agent {
                docker {
                    image 'ubuntu:jammy'
                    args '-v $HOME:/build -w /build'
                }
            }
            steps {
                sh 'make'
            }
        }
        stage('Test') {
            agent {
                docker {
                    image 'ubuntu:noble'
                    args '-v $HOME:/build -w /build'
                }
            }
            steps {
                sh 'make test'
            }
        }
    }
}

Azure Pipelines には、コンテナー内でビルドを実行するためのコンテナー ジョブ が用意されています。

azure-pipelines.yml

resources:
  containers:
  - container: jammy
    image: ubuntu:jammy
  - container: noble
    image: ubuntu:noble

jobs:
- job: build
  container: jammy
  steps:
  - script: make
- job: test
  dependsOn: build
  container: noble
  steps:
  - script: make test

さらに、Azure Pipelines には、イメージを実行、ビルド、またはプッシュできる Docker タスク が用意されています。

エージェントの選択

Jenkins では、ビルド パイプライン (またはパイプラインの特定のステージ) が特定のビルド エージェント マシンで確実に実行されるように、 agent オプションを使用してビルド エージェントを選択できます。 同様に、Azure Pipelines には、ビルド環境の実行場所を構成するための多くのオプションが用意されています。

ホストエージェントの選択

Azure Pipelines には、Linux、Windows、macOS ビルド用のクラウドでホストされるビルド エージェントが用意されています。 ビルド環境を選択するには、使用できます vmimageキーワード (keyword)。 たとえば、macOS ビルドを選択するには、次のようにします。

pool:
  vmimage: macOS-latest

さらに、 container を指定し、ビルドの実行方法をきめ細かく制御するための Docker イメージを指定することもできます。

オンプレミス エージェントの選択

オンプレミスでビルド エージェントをホストする場合は、マシンのアーキテクチャまたはインストールしたソフトウェアに基づいて ビルド エージェントの "機能" を定義できます。 たとえば、 java 機能を使用してオンプレミスのビルド エージェントを設定した場合は、 demands キーワードを使用してジョブを確実に実行できます。

pool:
  demands: java

環境変数

Jenkins では、通常、パイプライン全体の環境変数を定義します。 たとえば、 CONFIGURATION=debug と PLATFORM=x86の 2 つの環境変数を設定するには、

Jenkinsfile

pipeline {
    agent any
    environment {
        CONFIGURATION = 'debug'
        PLATFORM      = 'x64'
    }
    stages {
        stage('Build') {
            steps {
                sh 'echo $CONFIGURATION $PLATFORM'
            }
        }
    }
}

同様に、Azure Pipelines では、YAML 構成内で使用され、ジョブの実行中に環境変数として設定される変数を構成できます。

azure-pipelines.yml

variables:
  configuration: debug
  platform: x64

さらに、Azure Pipelines では、特定のジョブ中にのみ設定される変数を定義できます。

azure-pipelines.yml

jobs:
- job: debug build
  variables:
    configuration: debug
  steps:
  - script: ./build.sh $(configuration)
- job: release build
  variables:
    configuration: release
  steps:
  - script: ./build.sh $(configuration)

定義済みの変数

Jenkins と Azure Pipelines の両方で、継続的インテグレーション システムの実行環境の検査と操作に役立つ 環境変数が多数 設定されています。

¹ Azure Pipelines でビルド ログを表示する URL を派生するには、次の環境変数をこの形式で結合します。

${SYSTEM_TEAMFOUNDATIONCOLLECTIONURI}/${SYSTEM_TEAMPROJECT}/_build/results?buildId=${BUILD_BUILDID}

成功と失敗の処理

Jenkins では、パイプラインの post セクションを使用して、ビルドが完了したときにコマンドを実行できます。 ビルドが成功した場合 ( success セクションを使用)、ビルドが失敗した場合 ( failure セクションを使用)、または常に ( always セクションを使用して) 実行するコマンドを指定できます。 例えば次が挙げられます。

Jenkinsfile

post {
    always {
        echo "The build has finished"
    }
    success {
        echo "The build succeeded"
    }
    failure {
        echo "The build failed"
    }
}

同様に、Azure Pipelines には、パイプラインの成功や失敗などの多くの条件に基づいて、ジョブまたはジョブのステップを実行できる豊富な条件付き実行フレームワークがあります。

Jenkins postビルド条件をエミュレートするには、 always()、 succeeded() 、または failed() 条件に基づいて実行するジョブを定義できます。

azure-pipelines.yml

jobs:
- job: always
  steps:
  - script: echo "The build has finished"
    condition: always()

- job: success
  steps:
  - script: echo "The build succeeded"
    condition: succeeded()

- job: failed
  steps:
  - script: echo "The build failed"
    condition: failed()

さらに、個々のタスク、環境変数、または実行環境の成功または失敗に基づいてタスクを実行する機能など、 他の条件を組み合わせて、豊富な実行パイプラインを構築できます。

資格情報の処理

Jenkins には、パイプラインに資格情報を安全に挿入するためのcredentials() ディレクティブ内のenvironment ヘルパーが用意されています。 Jenkins では、シークレット テキスト、ユーザー名とパスワードのペア、シークレット ファイルなど、いくつかの資格情報の種類がサポートされています。

Jenkinsfile

pipeline {
    agent any
    environment {
        AWS_ACCESS_KEY_ID     = credentials('aws-access-key-id')
        AWS_SECRET_ACCESS_KEY = credentials('aws-secret-access-key')
    }
    stages {
        stage('Deploy') {
            steps {
                sh 'aws s3 ls'
            }
        }
    }
}

Azure Pipelines では、 変数グループ、 Azure Key Vault 統合、またはパイプラインでシークレット変数を直接定義することで、シークレットを管理できます。

azure-pipelines.yml

variables:
- group: my-aws-credentials  # Variable group linked to Azure Key Vault or containing secrets

jobs:
- job: Deploy
  steps:
  - script: aws s3 ls
    env:
      AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
      AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)

AzureKeyVault@2 タスクを使用して、Azure Key Vault からシークレットを直接参照することもできます。

steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'my-azure-subscription'
    KeyVaultName: 'my-key-vault'
    SecretsFilter: 'AWS-ACCESS-KEY-ID,AWS-SECRET-ACCESS-KEY'
- script: aws s3 ls
  env:
    AWS_ACCESS_KEY_ID: $(AWS-ACCESS-KEY-ID)
    AWS_SECRET_ACCESS_KEY: $(AWS-SECRET-ACCESS-KEY)