Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

Azure PipelinesからGitHub Actionsへの移行

GitHub ActionsとAzure Pipelinesは、いくつかの点で設定が似ており、そのためGitHub Actionsへの移行は比較的単純です。

Note

GitHub ホステッド ランナーは、現在 GitHub Enterprise Server ではサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

Azure PipelinesとGitHub Actionsは、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 Azure PipelinesとGitHub Actionsは、ワークフローの設定において似ているところがあります。

  • ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。
  • ワークフローには1つ以上のジョブが含まれます。
  • ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。
  • ステップもしくはタスクは、再利用とコミュニティとの共有が可能です。

詳しくは、「GitHub Actions を理解する」を参照してください。

主要な相違点

Azure Pipelinesから移行する際には、以下の差異を考慮してください。

  • Azure Pipeline はレガシーの_クラシック エディター_をサポートしています。これは CI の設定を、YAML ファイルでパイプラインの定義を作成する代わりに、GUI のエディタで定義できるようにするものです。 GitHub Actionsはワークフローの定義にYAMLファイルを使い、グラフィカルなエディタはサポートしていません。
  • Azure Pipelinesでは、ジョブの定義中の一部の構造を省略できます。 たとえば、ジョブが1つだけしかないなら、ジョブを定義する必要はなく、ステップだけを定義すれば済みます。 GitHub Actionsは明示的な設定が必要であり、YAMLの構造は省略できません。
  • Azure Pipelines は YAML ファイル中で定義される_ステージ_をサポートしています。ステージは、デプロイのワークフローの作成に利用できます。 GitHub Actionsでは、ステージは個別のYAMLワークフローファイルに分割しなければなりません。
  • オンプレミスのAzure Pipelinesビルドエージェントは、機能で選択できます。 GitHub Actionsのセルフホストランナーは、ラベルで選択できます。

ジョブとステップの移行

Azure Pipelinesのジョブとステップは、GitHub Actionsのジョブとステップによく似ています。 どちらのシステムでも、ジョブは以下の特徴を持ちます。

  • ジョブは、順番に実行される一連のステップを持ちます。
  • ジョブは、個別の仮想マシンまたは個別のコンテナで実行されます。
  • ジョブは、デフォルトでは並列に実行されますが、順次実行するように設定することもできます。

スクリプトのステップの移行

スクリプトやシェルのコマンドを、ワークフロー中のステップとして実行できます。 Azure Pipelines で、スクリプトの手順を script キーを使用して指定するか、bash キーか、powershell キーか、pwsh キーで指定できます。 スクリプトは Bash タスクまたは PowerShell タスクへの入力として指定することもできます。

GitHub Actions では、すべてのスクリプトは run キーを使って指定されます。 特定のシェルを選択するには、スクリプトを提供する際に shell キーを指定します。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。

以下は、それぞれのシステムにおける構文の例です。

スクリプト ステップの Azure Pipelines 構文

jobs:
  - job: scripts
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in the default shell"
      - bash: echo "This step runs in bash"
      - pwsh: Write-Host "This step runs in PowerShell Core"
      - task: PowerShell@2
        inputs:
          script: Write-Host "This step runs in PowerShell"

スクリプト ステップの GitHub Actions 構文

jobs:
  scripts:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in the default shell"
      - run: echo "This step runs in bash"
        shell: bash
      - run: Write-Host "This step runs in PowerShell Core"
        shell: pwsh
      - run: Write-Host "This step runs in PowerShell"
        shell: powershell

スクリプトのエラー処理の差異

Azure Pipelines では、stderr への出力があればスクリプトがエラーとなるように設定できます。 GitHub Actionsはこの設定をサポートしていません。

GitHub Actionsは、可能な場合にはシェルを"fail fast"に設定します。これは、スクリプト中のコマンドの1つがエラーコードで終了した場合に即座にスクリプトを停止させるものです。 これに対し、Azure Pipelinesではエラーの際に即座に終了させるためには、明示的に設定しなければなりません。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。

Windows上でのデフォルトシェルの差異

Azure Pipelines では、Windows プラットフォーム上のスクリプトのための既定シェルはコマンドシェル (cmd.exe) です。 GitHub Actionsでは、Windowsプラットフォーム上のスクリプトのためのデフォルトシェルはPowerShellです。 PowerShellは、組み込みコマンド、変数の展開、フロー制御で多少の差異があります。

シンプルなコマンドを実行するなら、コマンドシェルのスクリプトを変更なしにPowerShellで実行できるかもしれません。 しかしほとんどの場合は、PowerShellの構文でスクリプトをアップデートするか、GitHub Actionsに対してスクリプトをPowerShellではなくコマンドシェルで実行するように指定することになります。 shellcmd として指定することでこれを実行できます。

以下は、それぞれのシステムにおける構文の例です。

既定で CMD を使う Azure Pipelines 構文

jobs:
  - job: run_command
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in CMD on Windows by default"

CMD を指定するための GitHub Actions 構文

jobs:
  run_command:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in PowerShell on Windows by default"
      - run: echo "This step runs in CMD on Windows explicitly"
        shell: cmd

詳しくは、「GitHub Actions のワークフロー構文」を参照してください。

条件と式の構文の移行

Azure PipelinesとGitHub Actionsは、どちらもステップを条件付きで実行できます。 Azure Pipelines では、条件式は condition キーを使って指定します。 GitHub Actionsでは、条件式は if キーを使って指定します。

Azure Pipelinesは、ステップを条件付きで実行するために、式の中で関数を使います。 それに対し、GitHub Actionsはinfix表記を使います。 たとえば、Azure Pipelines における eq 関数は、GitHub Actions では == 演算子に置き換えなければなりません。

以下は、それぞれのシステムにおける構文の例です。

条件式の Azure Pipelines 構文

jobs:
  - job: conditional
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This step runs with str equals 'ABC' and num equals 123"
        condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))

条件式の GitHub Actions 構文

jobs:
  conditional:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This step runs with str equals 'ABC' and num equals 123"
        if: ${{ env.str == 'ABC' && env.num == 123 }}

詳しくは、「ワークフローとアクションで式を評価する」を参照してください。

ジョブ間の依存関係

Azure PipelinesとGitHub Actionsは、どちらもジョブの依存関係を設定できます。 どちらのシステムでも、デフォルトではジョブは並行に実行されますが、ジョブの依存関係を明示的に指定できます。 Azure Pipelines では、これは dependsOn キーで行われます。 GitHub Actions では、needs キーを使って行います。

以下は、それぞれのシステムにおける構文の例です。 ワークフローは initial という名前の最初のジョブを開始し、そのジョブが完了すると fanout1fanout2 という名前の 2 つのジョブが実行されます。 最後に、これらのジョブが完了すると、ジョブ fanin が実行されます。

ジョブ間の依存関係の Azure Pipelines 構文

jobs:
  - job: initial
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This job will be run first."
  - job: fanout1
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout2."
  - job: fanout2
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout1."
  - job: fanin:
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: [fanout1, fanout2]
    steps:
      - script: echo "This job will run after fanout1 and fanout2 have finished."

ジョブ間の依存関係の GitHub Actions 構文

jobs:
  initial:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."
  fanout1:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout2."
  fanout2:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout1."
  fanin:
    runs-on: ubuntu-latest
    needs: [fanout1, fanout2]
    steps:
      - run: echo "This job will run after fanout1 and fanout2 have finished."

詳しくは、「GitHub Actions のワークフロー構文」を参照してください。

タスクのアクションへの移行

Azure Pipelines は_タスク_を使います。これは、複数のワークフローで再利用できるアプリケーションのコンポーネントです。 GitHub Actions は_アクション_を使います。これは、タスクの実行とワークフローのカスタマイズに利用できます。 どちらのシステムでも、実行するタスクやアクションの名前を、必要な入力のキー/値のペアとともに指定できます。

以下は、それぞれのシステムにおける構文の例です。

タスクの Azure Pipelines 構文

jobs:
  - job: run_python
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - task: UsePythonVersion@0
        inputs:
          versionSpec: '3.7'
          architecture: 'x64'
      - script: python script.py

アクションの GitHub Actions 構文

jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v5
        with:
          python-version: '3.7'
          architecture: 'x64'
      - run: python script.py

ワークフローで使用できるアクションは 、GitHub Marketplace にあります。または、独自のアクションを作成することもできます。 詳しくは、「自動化の共有」を参照してください。