1.1　GitHub Actions とは

　GitHub Actions は、一言で表すと GitHub 組み込みの CI/CD システムです¹。例えば、あなたがGitHubのリポジトリーにコードの変更をプッシュしたタイミングで、ビルド、テスト、デプロイといった一連のフローを自動実行させるようなことができます。

　しかし、GitHub Actionsの用途はCI/CDだけではありません。後述するように、GitHubの様々なイベントにフックして、自動で処理を実行できます。これにより、issueが登録されたときに担当者を自動で割り当てたり、PR（プルリクエスト）が作成されたときにSlackに通知を飛ばしたりといったこともできます。GitHub Actionsは、ソフトウェア開発におけるあらゆるワークフローの自動化に使えるのです。

1.1.1　歴史

　2018年のGitHub Universe（GitHub最大のコミュニティイベント）で、GitHub Actionsがベータとして限定公開されました²。この時点ではGitHubはActionsをCI/CDのためのものとは位置づけておらず、あくまでもワークフローの自動化のためのシステムとしていました。

　しかし、2019年8月の時点でGitHub Actionsの大幅なリニューアルが発表されました³。コンセプト面ではCI/CDを前面に押し出すようになり、LinuxだけでなくWindowsやmacOS環境も利用できるようになり、ワークフローの設定ファイルの記述方法もHCL⁴からYAMLに変わりました。この変更の背景として、GitHub社がMicrosoftに買収されたことが挙げられます。GitHub ActionsのバックエンドとしてAzure Pipelinesに変更を加えたfork版が使われるようになりました。このため、GitHub Actionsについて調べるときは、2019年8月以前に書かれた情報については基本的にもう参考にならないと覚えておいてください。

　そして、2019年のGitHub Universeで、GitHub ActionsはGA（Generally Available）になり⁵、現在に至ります。GA後も継続的に機能改善がリリースされており、今後もより便利になっていくことが期待されます。

CI/CDとは

　CI（継続的インテグレーション）とは、技術的プラクティスのひとつです。チームのメンバーは一日に何回もバージョン管理システムのリポジトリーに変更をマージし、そのたびにテストを含む自動ビルドが毎回実行されるようにします。

　CIを行う目的は、問題を早期発見できるように高速なフィードバックをシステム化することです。また、変更が頻繁にマージされるようになれば、一回の変更ごとの差分が小さくなります。これによって問題が発生するリスクが減りますし、万が一なにか発生したとしても差分が小さいので調査が簡単になります。また、CIが成功しているか失敗しているかといった状態が可視化されることによって、開発が順調に進んでいるかチーム内のコミュニケーションが活発になります。開発者にとっては、変更ごとにCIで保証されることによる心理的安心感も重要です。

　CD（継続的デリバリー）は、CIをさらに発展させた技術的プラクティスです。コードが変更されるたびに自動でテストなどが実行されるのはCIと同じです。CDでは、さらにソフトウェアがいつでもリリースできる状態であるところまで毎回保証できるようにします。具体的になにを自動化するかはソフトウェアの性質によりますが、例えばE2Eテスト、性能検証、脆弱性検証、アーカイブ作成といったことも含めます。そして、コードを変更してからリリースするまでのこれらの検証を複数のステージに分けてパイプラインとして表現したものを、デプロイメントパイプラインと呼びます。

　CDを行うことによってリリースのコストやリスクを大幅に抑えられます。いつでもリリースできる状態を保つことによって、リリース直前に行う作業がほとんどなくなるためです。理想的なCDを実践できれば、リリースはボタンひとつでできるようになります。また、デプロイメントパイプラインによってコード変更からリリースまでのフローが可視化されるので、どの部分で問題が起きているか、ボトルネックになっているかといったことが可視化されます。これによって、リリースまでのフローの改善にもつながりやすいです。

　世の中にはCI/CDを実現するためのツールがいくつも存在します。代表的なのは Jenkins⁶ です。JenkinsはOSSで手軽に各自の環境に構築することが可能で、かなり長い期間に渡ってCI/CD界隈のデファクトツールとして存在し続けています。その後、Travis CI⁷やCircleCI⁸などの登場によって、CI/CDのクラウドサービス化が進みました。開発者は、それまでよりも素早くお手軽にCI/CDを導入できるようになったのです。そして、継続的デリバリーの普及に伴い、デプロイメントパイプラインのような複数のジョブによるフローがワークフローとして表現されるようになりました。さらに、Dockerによりコンテナ技術が一般的になり、CI/CDツールでもコンテナ技術が取り入れられました。

　GitHub Actionsは、こういったCI/CDツールの長い歴史の流れを汲む、最新のCI/CDツールなのです。

1.2　主な特徴

　GitHub Actionsは、既存のCI/CDツールとどういった点が異なるのでしょうか？

　まず、GitHubのファーストパーティ製のサービスであるということが挙げられます。このため、GitHubの権限を外に持ち出すことなくCI/CDを実現することができます。

　また、GitHubのさまざまなWebhook⁹のイベントに対応しているというのも、これまでのCI/CDツールとは大きく異なる点です。従来のCI/CDツールはpushイベントによるCI/CDがメインで、それ以外のイベントはほとんどサポートされていませんでした。そのため、例えばissueが登録されたときになにかしらの処理を自動で実行したい場合、これまでは自前でAWS上にAPI Gateway + Lambdaを構築したりするなど、どうにかしてイベント発生時に処理を実行する仕組みを作るしかありませんでした。しかし、GitHub Actionsではpush以外の様々なイベント発生時にもワークフローを自動で実行できるので、イベントにフックするワークフローもGitHub内で完結して実行できるようになりました。つまり、GitHub ActionsはCI/CD用途に限らず、開発における様々な場面におけるワークフローを自動化できるということです。GitHub Actionsが対応しているイベントについては「2.7 イベントとアクティビティ」で解説します。

　そして、パブリックリポジトリーは完全無料というのも大きな特徴です。既存の CI/CDサービスでもOSS向けに無料プランはこれまでもあったのですが、実行時間や並列実行数などの制限があり、ある程度の規模になってくると物足りない面がありました。しかし、GitHub Actionsはパブリックリポジトリーならどれだけの時間使っても完全に無料で、さらに最大20並列まで実行できるので、かなりの規模のOSS開発でも実用的です。

　さらに、GitHub Actionsにはセルフホストランナーという、独自の環境でワークフローを実行するための仕組みがあります。GitHub Actionsが管理する環境でも、Linux、Windows、macOSと多様な環境でのワークフロー実行が可能です。しかし、より強いマシンリソースを利用したいとか、独自にカスタマイズした環境でビルドしたいとか、外部から接続できないネットワーク内にデプロイしたいといった要求がある場合には、用意された環境だけでは実現できないことがあります。セルフホストランナーの仕組みは、そういったユースケースを可能にしてくれます。セルフホストランナーの詳細については、「2.12 ランナーのセルフホスティング」で解説します。

　もちろん、これまでのCI/CDツールが持っていた機能についても、GitHub Actionsは大部分をサポートしています。公開後もどんどん改善が進んでおり、GitHubの大きなコミュニティが GitHub Actionsのエコシステムにも影響を与えることも予想され、今後の発展性も期待できます。

1.3　料金体系

　前の節でも少し触れましたが、GitHub Actionsの料金体系についてもう少し詳しく見ておきます。

1.3.1　パブリックリポジトリー

　GitHub Actionsは、パブリックリポジトリーでの利用は完全に無料です。

1.3.2　プライベートリポジトリー

　プライベートリポジトリーでGitHub Actionsを利用する場合は、GitHubのプランによって決まった量の無料利用できるビルド時間とストレージが提供されます。無料分を超えた分については料金がかかります。

無料で利用できるビルド時間とストレージ

表1.1: 無料で利用できるビルド時間とストレージ

プラン	ビルド時間	ストレージ
Free	2,000	500 MB
Pro	3,000	1 GB
Team	10,000	2 GB
Enterprise Cloud	50,000	50 GB

　表1.1の通りです。ビルド時間は毎月リセットされますが、ストレージは月をまたいでもファイルが保存されたままである限り、そのまま使用中として計算されます。

ビルド時間

　ビルド時間にかかる料金は、ビルドに使用するOSによって変わります。Linuxで1分ビルドしたときはそのまま1分として計算されますが、Windowsは2倍、macOSは10倍の実行時間として計算されます。無料分のビルド時間を超えると、ビルド1分につき $0.008 のレートで料金がかかります。ちなみに、セルフホストランナーを利用する場合は無料です。

表1.2: ビルド時間でかかる料金

OS	料金
Linux	$0.008 / 分
Windows	$0.016 / 分
macOS	$0.08 / 分

　表1.2がOSごとのビルド時間ごとにかかる費用のまとめです。例えば、1,000分ビルドすると、Linux だと$8、Windowsだと$16、macOSだと$80になります。

ストレージ

　ストレージ料金は、GitHub Actionsのアーティファクト機能¹⁰で利用している容量と、GitHub Packages¹¹で利用している容量の合計で計算されます。GitHub Packages側の料金体系については本書では扱わないので、興味がある場合はGitHub Packagesの公式ドキュメント¹²を参照してください。

　GitHub Actionsでは、無料分のストレージを超えた容量に対して、毎月1GBにつき$0.25の費用8が発生します。月の途中で新しくストレージに追加された場合、この料金は時間単位で計算されます。例えば、合計日数が30日の月に、12GBの容量を10日間保存したとすると、次の計算になります。

　・(12GB × 10日 × 24時間) / (30日 × 24時間) = 4GB 月

　・4GB月 × $0.25 = $1

料金の上限

　意図しない理由によって料金がかかりすぎるのを防げるように、料金には上限が設定できるようになっています。この設定は、GitHub ActionsとPackagesを合計した月額料金の上限です。デフォルトでは、$0が上限として設定されているので、無料分を超えて利用したい場合は料金の上限を変更する必要があります¹³。

　料金の上限の設定方法は、個人アカウントか、organizationか、Enterpriseアカウントかによって変わってきます。参考までに個人アカウントでの設定方法を書きますと、GitHubをブラウザーで開き、右上のヘッダーメニューからSettings → サイドバーのBilling → Cost managementという順で遷移すると、料金の上限を設定できます。

　図1.1は筆者の個人アカウントの料金の上限の設定画面です。

制限事項

　GitHubのレガシーな料金プラン（ユーザー数が無制限でプライベートリポジトリー数で月額料金が決まるプラン）では、GitHub Actionsは利用できません。新しいプランにアップグレードする必要があります。

　また、Enterpriseアカウントで支払いを請求書払いにしている場合、料金の上限をブラウザー上から設定できません。GitHubに問い合わせて、事前に利用分を購入する必要があるようです。

1.4　Hello, World!

　詳細な機能説明に入る前に、実際にGitHub Actionsでワークフローを設定して動かす流れを体験してみましょう。まず、個人アカウント（もしくはorganization）下に新しくリポジトリーを作成し、次の内容で .github/workflows/hello.ymlファイルを作成します。

リスト1.1: .github/workflows/hello.yml

name: Hello, World!
  on: push

  jobs:
    build:
      name: Greeting
      runs-on: ubuntu-latest
      steps:
        - run: echo "Hello, World!"

　リスト1.1は、ワークフローを定義しています。

　最初の name は、ワークフローの名前です。次のon: pushで、リポジトリーへのpushイベント時にこのワークフローが実行されるように定義しています。jobsブロックでは、ワークフロー内で実行されるジョブを定義しています。buildと書かれているところはジョブのIDで、jobsのキーとしてユニークであれば他の文字列でも大丈夫です。nameでジョブ名、runs-onでこのジョブが実行される仮想環境を指定しています。stepsでジョブ内で実行される処理を定義しています。今回のサンプルでは、echoが実行されるだけです。このあたりの設定の詳細については、第2章「GitHub Actions の機能解説」で解説します。

$ git add .github/workflows/hello.yml

$ git commit -m "first commit"

$ git push origin master

　上記のように作成したファイルをpushすると、GitHub Actionsのワークフローが実行されます。GitHubのリポジトリーをブラウザーで開き、Actionsタブをクリックすると図1.2のようにワークフローが実行されている様子を見られます。

　表示されている最新の行をクリックすると、ワークフローの実行ログが確認できるページに遷移します。各ステップが表示され、Runステップをクリックすると、図1.3のように標準出力に Hello, World!と表示されていることが確認できます。

　このサンプルは、次のGitHubリポジトリーでご確認いただけます。

　・https://github.com/github-actions-up-and-running/hello-world

　以上で、リポジトリーにpushされるたびにHello, World!と表示するだけの簡単なワークフローをGitHub Actionsで作成できました。まだ本格的なCI/CDではないですが、GitHub Actionsでワークフローを作成する流れを体験していただけたと思います。

1.5　まとめ

　本章では、GitHub Actionsはどういうものか、どういった特徴があるのかといった話から、実際に簡単なワークフローを動かすところまで説明しました。

　次章では、ワークフローの設定方法やGitHub Actionsが持つ機能について、より詳しく見ていきます。