はじめに
先日、少人数でスピード感を持って開発するために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やらコンテナをたてないといけないので、少人数開発にはオーバースペックなところがあります。
総評
- スピード重視なら良い選択肢
- なにより無料なのが熱い
- ナウい技術なので使っていてたのしい