Github Actions入門その1-概要と用語の整理
はじめに
今の組織で CICD のプラットフォームとして Github Actions メインに切り替えています。
今後更にこの流れが進みそうなので Github Actions について一から学びなおしてみようと思いました。
Github Actions とは
Github が提供している CI ( continuous integration ) と CD ( continuous delivery ) を実現するためのプラットフォームです。
CI/CD パイプラインとは
CI とはビルド、テスト、静的解析などの開発パイプラインを示します。
過去には各作業者の PC 内で実行していましたが、環境差異による実行結果の違いや実行忘れなどの問題があることから、現在のほぼすべての開発組織で導入されている仕組みです。
CD とは CI に加えてアプリケーションのデプロイの流れまでを含めた用語となっています。
Github Actions が実行されるタイミング ( イベント )
実行のトリガは「Git ブランチに対して push されたタイミング」「プルリクが作成されたタイミング」「プルリクが main ブランチにマージされたタイミング」など任意のタイミングが指定できます。
具体的な例として、「誰かが Github リポジトリに新しい Issue を作成したタイミングで、ラベルを付与する」ことができます。
実行環境
Linxu、Windows、macOS の仮想マシンが用意されています。
Github 上のマネージド環境だけでなく、オンプレ環境や他のクラウドを実行環境とすることもできます。
また、仮想マシンではなくコンテナ環境を利用することもできます。
概要
Github Actions の構成要素について、概要を掴んでおきます。
「ワークフロー」と呼ばれるものを設定します。
ワークフローは Github リポジトリの中で何らかの「イベント」が発生 ( トリガー ) したときに実行されます。
例えば「プルリクエストの作成」や「Issue の作成」といったイベントがあります。
「ワークフロー」は 1 つの「実行環境」を割り当てるように設定されます。
「ワークフロー」は 1 つ以上の「ジョブ」を含みます。
ジョブ同士は設定次第で直列、並列いずれの方法でも実行可能です。
ジョブは仮想マシンやコンテナで実行されます。
更に、「ジョブ」は 1 つ以上の「ステップ」を含みます。
ステップが実行の単位となり、ユーザーが設定した「スクリプト」や「アクション」と呼ばれるものを実行します。
「アクション」はライブラリのように再利用可能なステップの束となっています。
用語を改めて整理すると以下のようになります。
- イベント
- 1 つのワークフロー ( Workflows )
- 1 つの実行環境 ( Runners )
- 1 つ以上のジョブ ( Jobs )
- 1 つ以上のステップ ( Steps )
- 1 つのスクリプト ( Scripts ) または アクション ( Actions )
ワークフロー ( Workflows )
ワークフローは自動的に実行される処理の「設定」情報です。
先に見てきたように、1 つ以上のジョブを実行します。
ワークフローの「設定」は YAML ファイルで定義します。
この設定ファイルはワークフローを実行させたい Github リポジトリ内に配置 ( コミット＆プッシュ ) しておきます。
そして、リポジトリ内で「イベント」が発生したことをトリガーに実行されます。
少し変わった起動方法として 手動実行 や スケジューラによる時間指定起動 も可能です。
ワークフローの設定ファイルは Git リポジトリ内に .github/workflows というディレクトリを作成し、その中に配置します。
YAML 設定ファイルは 複数用意することができます。
.github/workflows ディレクトリに配置する YAML 設定ファイルの例をあげましょう。
ある YAML 設定ファイルにはプルリクエスト作成をトリガーにビルド＋テストを実行するジョブを定義し、また別の YAML 設定ファイルには「リリース」作成をトリガーにアプリケーションをデプロイするジョブを定義します、といったような具合です。
更に別の YAML 設定ファイルには、Issue が作成されたことをトリガーに Issue にラベルを付与するジョブを定義します。
あるワークフロー ( =YAML ファイル ) から別のワークフロー ( =YAML ファイル ) を参照することも可能です。
ジョブ ( Jobs )
ワークフローの中の「ステップ」の集合です。
単一の仮想マシンで実行されます。
1 つ 1 つのステップはシェルスクリプトかアクションを指定します。
ステップは直列に実行されます。
ジョブ同士は依存関係を設定することができます。
デフォルトでは、ジョブ同士は依存関係がないため、すべてのジョブが並列で実行されます。
あるジョブが別のジョブに依存していると、依存先のジョブが完了するまで実行開始を待ちます。
具体的な例をあげます。
異なった CPU アーキテクチャ向けの複数のビルドジョブがあるとします。
これらには依存関係がありません。
最後にビルドで生成されたファイルをひとまとめにアップロードするジョブが必要です。
この場合、ビルドジョブは並列で実行させ、アップロードジョブはすべてのビルドジョブの終了を待ってから実効す料に設定します。
アクション ( Actions )
アクションは Github Actions 上で実行可能な自作アプリケーションと考えるとよいでしょう。
何度も記述しているステップをアクションにすることで、コードの重複を避けたり再利用できます。
アクションは実行時に Git リポジトリから pull されます。.github/workflows ディレクトリに配置し、これを別のワークフローから参照することもできます。
この場合は pull されません。
実行環境 ( Runners )
イベントが発生すると、ワークフローを実行するためのサーバが割り当てられます。
それぞれの実行環境は、一度に 1 つのジョブだけを実行します。
Github は 以下のような環境を提供しています。
- Unbutu
- Windows
- macOS
ワークフローの実行には上記の環境が利用できます。
ワークフローの実行の際には、毎回まっさらな実行環境 ( 仮想マシン ) が割り当てられます。
ビルドに CPU、メモリなどのリソースが必要な場合、設定により要求できます。
ひとこと
次回は実際にサンプルコードを触ってみます。