はじめに

先日、少人数でスピード感を持って開発するためにGitHub Actionsを導入したため、
技術選定の際に、考慮した点をメモりました。

始めやすい

GUIでぽちぽちつくれる

GitHubリポジトリ上からActionsタブを開き、New workflowをクリックすると、テンプレートを選ぶ画面になります
最低限のパラメータを記入すればすぐに使えます。

テンプレートが豊富に揃っている

各種言語・フレームワークにおけるCI、各プラットフォームへのCDのテンプレートがデフォルトで揃っているため、
採用する技術に応じてテンプレートを選択するだけで使えます。
また、テンプレートがないものについても、公式ドキュメントも豊富なため、ベースとなるテンプレートを選んで編集することも容易です。

Codeシリーズと比べて

普段業務でCI/CDを構築する際はAWSのCodeシリーズを使うことが多いので比較しました。

Pros

インフラにはねない

GitHub Actionsでは、workflowの定義ファイルをアプリのコードと一緒に管理できます。
SRE部隊がいる組織であればいいのですが、アプリとインフラでチームが分かれている組織はまだまだあります。
CodeシリーズはAWSリソースになるので、インフラチームの管理下になりますが、CI/CDはアプリチームで管理したいことが多いと思います。

GitHub内でSecrets管理できる

Secretsも同様に、Codeシリーズでは、AWS Secret Managerを使うのが一般的ですが、
GitHub Actions ではリポジトリのSecretsにそのまま登録できます。

Cons

特定のジョブを再実行できない

GitHub Actionsでは、Workflowを定義する際に複数のジョブを組み込めますが、
Workflowがこけた際に、特定のジョブのみを再実行することができません。。。

サブルーチン的な使い方ができない

Workflowの中では別の定義を呼び出すことができません。
次にこのWorkflowを実行する、みたいな定義はできますが、あくまで別Workflow扱いになります。
そのため、開発ブランチではCIだけ、masterブランチはCI+CDの構成な時、それぞれ定義する必要があります。

GHEだとランナーを自前で用意する必要がある

GitHub Enterpriseでは、ランナーを時前で用意する必要があります。
そのため、CI/CD用のEC2やらコンテナをたてないといけないので、少人数開発にはオーバースペックなところがあります。

総評

スピード重視なら良い選択肢
なにより無料なのが熱い
ナウい技術なので使っていてたのしい