Skip to main content

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

Azure PipelinesからGitHub Actionsへの移行

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

注: 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 GitHub Actions
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"
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 として指定することでこれを実行できます。

以下が、それぞれのシステ� の構文の例です。

Azure Pipelines GitHub Actions
jobs:
  - job: run_command
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in CMD on Windows by default"
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 GitHub Actions
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))
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 GitHub Actions
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."
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 GitHub Actions
jobs:
  - job: run_python
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - task: UsePythonVersion@0
        inputs:
          versionSpec: '3.7'
          architecture: 'x64'
      - script: python script.py
jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v2
        with:
          python-version: '3.7'
          architecture: 'x64'
      - run: python script.py

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