注: 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
キーを指定します。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。
以下は、それぞれのシステムにおける構文の例です。
スクリプト ステップの 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ではエラーの際に即座に終了させるためには、明示的に設定しなければなりません。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。
Windows上でのデフォルトシェルの差異
Azure Pipelines では、Windows プラットフォーム上のスクリプトのための既定シェルはコマンドシェル (cmd.exe) です。 GitHub Actionsでは、Windowsプラットフォーム上のスクリプトのためのデフォルトシェルはPowerShellです。 PowerShellは、組み込みコマンド、変数の展開、フロー制御で多少の差異があります。
シンプルなコマンドを実行するなら、コマンドシェルのスクリプトを変更なしにPowerShellで実行できるかもしれません。 しかしほとんどの場合は、PowerShellの構文でスクリプトをアップデートするか、GitHub Actionsに対してスクリプトをPowerShellではなくコマンドシェルで実行するように指定することになります。 shell
を cmd
として指定することでこれを実行できます。
以下は、それぞれのシステムにおける構文の例です。
既定で 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
詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。
条件と式の構文の移行
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
という名前の最初のジョブを開始し、そのジョブが完了すると fanout1
と fanout2
という名前の 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."
詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。
タスクのアクションへの移行
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 にあります。または、独自のアクションを作成することもできます。 詳しくは、「アクションの作成」を参照してください。