Azureを使ったCI/CD構成ってあまり構築したことないな~(CI/CD構成だとAWSのコードシリーズを使うことが多い)、てかそもそもCI/CD周りの案件にあまり関与したことないな~など考えていたら、先日のJAZUGイベントで皆さん当たり前のようにAzure×CI/CD周りを話されており危機感を感じております。そんな私がそもそもGitHub Actionsってなんぞや?美味しいの?レベルのため、ワードの意味や何となくのイメージを本記事にまとめようと思います。
よく聞く"GitHub Actions"って何?
GitHubのリポジトリ上(貯蔵庫)でソフトウェア開発のワークフローを自動化するサービスです。
具体的には、CI/CD(継続的インテグレーション/継続的デリバリー)プロセスを自動化し、ビルド、テスト、デプロイなどのタスクを自動的に実行する仕組みを提供します。
GitHubは"バージョン管理ツール"(変更履歴を記録し、管理するシステム)であり、GitHub Actionsとは大きく異なる。
ブランチとは、プログラムのコード開発において、主要な開発ラインから一時的に分岐した作業の流れのことを指します。例えば、ある機能の開発中に別の修正が必要になったとき、ブランチを切って修正作業を行うことで、並行して複数のタスクを進めることができる。これにより、チーム内での作業の衝突を避けたり、特定のバージョンのコードを保存しておくことも可能となる。
主要コンポーネント

- イベント:push、pull、requestなどのアクション(トリガー)
- ワークフロー:自動化プロセスの定義であり、指定場所にYAMLファイルを作成する
- ジョブ:ワークフロー内で実行される一連のステップ
- ステップ:ジョブ内で実行される単一タスク
- ランナー:ワークフローの実行環境
- アクション:特定タスクを実行できる再利用可能な単位であり、GitHub Marketplaceで共有可能
種類
GitHub Actionsにも種類があるらしい。
- GitHub hosted Runner:GitHub管理サーバ下でワークフローを実現できる。すぐに使えるのが特徴。
- Self-hosted Runner:ユーザ所有の環境下でGitHub Actionsを実行する。自由度と柔軟性が非常に高い。
Actions Runner Controller(ARC)
Kubernetes上でSelf-hosted Runnerの調整、スケーリングを行うKubernetes Operatorです。
主に以下3つの役割を持っています。
- Controller-Manager:Kubetnetes連携の要(Pod生成、GitHub実行)
- Listener:イベント駆動型スケールを支える中核(GitHubからジョブが発行されたかチェックする)
- Runner Scale Set:Listenerと連携してスケールイン/スケールアウトを制御
Runnerは、GitHub Actionsのワークフローを実行する実体です。YAMLで定義された処理内容(ジョブやステップ)を、このRunnerがローカルで処理します。
Podは、Kubernetesにおける最小のデプロイ単位で、1つまたは複数のコンテナをまとめて動かす論理ユニットです。
用語
- Kubernetes:コンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェア。
- Helm:Kubernetesのパッケージマネージャー。アプリケーションのクラスタへのデプロイに必要なすべてのコードとリソースが含まれ、アプリの配信を自動化します。
- クラスタ:複数のコンピューターやサーバーを組み合わせて1つのシステムのように動作させる仕組み。
関連記事
そもそもGitとは何か?初心者向けにまとめた記事になります。
GitHub CodeSpacesについてまとめた記事になります。