「GitHub Actions」は、開発者に直接パワーを与える自動化ツール：ちょっとした面倒を解決

GitHubが2018年10月中旬に発表した「GitHub Actions」は、一言で言えば「開発者のワークフローを自動化するサービス」。だが、一般的な自動化ツールではなく、開発者がそのパワーを直接、自身の問題を解決するために構成し、利用し、共有できるものだという。

[三木泉，＠IT]

　GitHubが2018年10月中旬に「GitHub Universe」で発表したGitHub Actionsは、瓶に入れる砂のようなものだと、同社のエコシステムエンジニアリング担当ディレクター、カイル・ダイグル氏は表現する。

GitHubのエコシステムエンジニアリング担当ディレクター、カイル・ダイグル氏

　「瓶の中には、幾つかの大きな石が入っている。石の一つ一つは開発者ツール、CIツール、クラウドなどだ。このビンに入れる砂の役割をするのがGitHub Actionsだ。さまざまなツール間の隙間を埋め、ビンを完全に満たすことができる」（ダイグル氏）

　GitHub Actionsは、一言でいえば「開発者のワークフローを自動化するサービス」。だが、既存の各種自動化ツールを置き換えることを目指しているものではない。むしろ、開発者や開発チームのワークフロー全体を自動化する観点から、単一のツールでは足りない部分を補ったり、複数のツール間をつないだりすることで、日常生じている一手間、二手間をなくそうとしている。

　ダイグル氏は、GitHub Actionsについて、2つの意味で重要な発表だと考えているという。

　「第1に、GitHubでは、開発者がいつでも自分たちに適した最善のツールを選んで使ってもらえるように努力してきた。一方で、CIツール、プロジェクトマネジメントツール、クラウドなどのツールは、それぞれがGitHubとは連携していても、相互を簡単に連携させることはできなかった。私たちは、この問題を解決する方法を幾つか検討したが、開発者自身がworkflowファイルに書く簡単なコードで、複数のツールを結び付ける方法を採用した」

　つまりGitHub Actionsは、GitHubの機能に加え、自動化ツールを含めた各種の外部ツールをつなげることで、開発者のワークフローを起点として考えた場合の死角を埋める働きをする。

　「第2に、私たちはソフトウェアをオープンソースで共有し合う世界を目指してきた。社会貢献ができるソフトウェアも多数開発されている。しかし、こうしたソフトウェアが実際に世の中の役に立つためには、最後に誰かがどこかで稼働しなければならない。このプロセスはまだまだとても面倒だ。GitHub Actionsを使えば、新しいシステムをデプロイする際に、構成を一からやらなくて済む」

　例えばパブリッククラウドにコードをデプロイする作業では、既に提供されているActionを、自身のWorkflowファイルに組み込むことで、デプロイが半自動的に行えるようになる。これにより、利用者の層を広げるのにも貢献できるとする。

　ダイグル氏はGitHub Actionsを発表したイベント「GitHub Universe 2018」の基調講演で、次のようにも語っている。

　「開発の過程で、私たちがこれ（GitHub Actions）を実現する唯一のやり方は、自動化のパワーを私たちのユーザー、およびオープンソースコミュニティに直接届けることだと認識していた。あなた（開発者）たちがActionを作り、お互いに共有してほしい。そしてActionを、自分の好きなやり方でつなげてほしい。（GitHub Actionsの）運用、仮想マシンの取り扱い、実行、APIなど、面倒な部分は私たちが担う。あなたたちは自身にとって重要な問題を解決し、これをオープンソースリポジトリで共有し、他の開発者がこれを活用してフォークし、それぞれに適したワークフローを構築できるようにしてほしい。画一的なワークフローではなく、それぞれにとってベストな、コンポーザブルなワークフローが求められている」

あらためて、GitHub Actionsとは

　GitHubが限定パブリックβ提供を開始したGitHub Actionsは、GitHubや外部ツールのAPIを活用するコード（「Action」と呼ぶ）を、実行順序を指定して実行するという簡単な仕組みだ。これはソフトウェアツールではなく、サービスとして提供される。このため前述の通り、ユーザーは、GitHub Actionsの運用に関与せず、利用に徹すればいい。

　Actionsの実行順序は、引数や認証情報などとともに、スクリプトとしてWorkflowファイルに記述しておく。あるいはビジュアルなワークフロー設計画面で、Action間を線でつなぐことにより、スクリプトレスでWorkflowファイルを生成することもできる。

Workflowファイルの例

ビジュアルにワークフローを構成することもできる

　こうして作成されたWorkflowファイルの内容は、GitHubにおけるプルリクエストをはじめとしたイベントや、外部のイベントをトリガーとして、自動実行できる。

　トリガーの例として、GitHubはAmazonのDash ButtonのようなIoTボタン、「flic」を来場者に配り、これを使って1ボタンクリックでワークフローを実行するデモを見せた。

　「GitHub社内ではかなり昔から、チャットを通じてGitHubの機能を実行してきた。（ボタンをトリガーとして利用するのはこれと似ているが、）今度はGitHubの特定機能だけでなく、ワークフロー全体であっても1ボタンプッシュで実行できるようになる。IoTボタンとGitHub Actionsの連携で、あなたは自身にとってベストなボタンを設計できる。いろいろ試しながら、最適な利用方法を探すことだってできる」（ダイグル氏）

　GitHubは、約450のActionを既に用意したという。既に用意されたActionで最も多いのは、パブリッククラウドに対する、デプロイメントなどの操作を自動化するもの。当然GitHubとの連携を行うActionも豊富に用意されている。他にも開発者は、好きなActionを自由に作ることができる。

ワークフローのトリガーとして、26のイベントが使える。その1つであるrepository_dispatchを通じ、外部イベントをトリガーとして取り込むこともできる

　一方ワークフローは、少なくとも現時点では複雑なものを定義できるようにはなっていない。例えば条件分岐はできない。Actionを単純にシーケンシャルに単一パスで実行していくか、あるActionに続き、複数のActionを同時実行するかしかない（複数の実行を受けて、単一のパスに戻ることはできる）。ただし、2つのActionをそれぞれルールに基づいて同時実行することで、疑似的に条件分岐のようなことを実行できるとダイグル氏は話す。

GitHub Actionsのユースケースは？

　GitHub Actionsを何に使うかは、開発者の想像力次第だ。

　「限定パブリックβという形にしているのは、ユーザーが何に使いたいのかをもっと知りたいからでもある」（ダイグル氏）

　とはいえ、当初はデプロイメント関連が多いのではないかと、ダイグル氏は予想する。

　「成熟したソフトウェア開発を行っている組織は、CI（Continuous Integration）に関しては何らかのツールを使っている。だが、デプロイメントは話が違う。単一のクラウド事業者のみを使っているとしても、その事業者のツールを使いたいとは限らない。さらに複数のクラウドを使いたい場合はどうだろう。それぞれのクラウドのツールを並行して使うのか。それともサードパーティーのツールを使うべきだろうか。このようにデプロイメント関連で使い始める人は多いだろう。また、オープンソースプロジェクトや小規模なプロジェクトでは、テストツールとしての使い方があると思う」

　GitHub Universe 2018の基調講演で、HashiCorpの創業者で共同CTOのミッチェル・ハシモト氏は、GitHub Actionを使ってインフラプロビジョニング自動化ツールであるTerraformのワークフローを統合するデモを見せた。GitHubにおけるプルリクエストをトリガーとして自動的に「formatting」「validate」「plan」のチェックを行い、プルリクエストへのレビューとしてチェックの結果と提案を表示できる。修正後のプルリクエストが「plan」を含めた全てのチェックで問題がないことを確認すると自動的にマージし、実際のインフラへの変更を行った。

　一方、ペット用品オンラインサイトのChewyは、コードのブランチ名やコミットメッセージに、Jira SoftwareのIssue Numberを自動的に追加するワークフローを自作したといい、GitHub Universeの基調講演で見せた。

　「大企業では、コンプライアンスへの活用が重要な用途になることも考えられる。コードを誰がいつ、どこで動かしたのか、特定のファイルに誰がいつ修正を加えたかを監査できるようにしたい、といったことだ。こうした用途に向けた機能を追加することも考えている」とダイグル氏は話している。

（取材協力：GitHub）