入門!GitHub Actions〜JavaのGradleプロジェクトをビルドしてAWS Lambdaにアップロードする設定〜

こんにちは!テックリードのなかむらです。最近は某・無人島生活ゲームで儲けるために「カブ カブ あーがれ〜」とカブ価をチェックする毎日を過ごしています。

はじめに

今月5月14日にConfitの新機能リリースがあったのですが、作業中に小さなハプニングがありました。
アトラスのどのサービスでもテストやビルドを同じCI/CDツールで実行しているので、他サービスの開発中のビルドキューが溜まっていて、Confitのリリース用のビルド&デプロイ処理がなかなかはじまらなかったのです。リリース作業はしばらく待って問題なく完了しましたが、今後もこのような待ち時間が発生するのは問題です。

そこで、GitHub Actionsを併用してみることにしました。
CI/CDツールを用途によって使い分けて、作業の待ち時間を少しでも削減して総合的に開発リードタイムの短縮を試みようという作戦です。この作戦の遂行までの道のりは長くまだまだ志半ば・・・なので、本記事ではGitHub Actionsの概要と入門編として導入/手順を紹介します。

GitHub Actionsとは

2018年10月に開催された開発者のためのカンファレンスにて発表され、1年間の利用申請が必要なベータ版を経て、昨年11月に正式リリースされました。
GitHubのリポジトリに 「Actions」のタブがありますよね。コレです。
GitHub Actions Tab
GitHubのイベントをトリガーとして、任意のDockerコンテナの実行を順番を定義することで自由にワークフローを定義できるというものです。Dockerコンテナを実行できるのでビルドやテスト、デプロイなど、さまざまな環境でいろんな動作を組み合わせることができます。

良い点、おすすめポイント

簡単

CricleCiやTravis-CI、Jenkinsなど他のツールは多少なりともGitHubと連携するための初期設定が必要ですが、GitHub Actionsなら設定ファイルをcommitするだけでよいので簡単にはじめることができます。

安い

安い!!というか無料で利用できます。プライベートリポジトリでもプランによって無料枠があるので、追加料金を課金しなくてもよさそうです。詳しくは GitHub Actionsの支払い についてをみてください。

再利用可能

ワークフローで利用する一般的なActionはマーケットプレイスで公開されているので、リストから検索してすぐに利用することができます。
また、マーケットプレイスで公開されていなくても、パブリックリポジトリのActionなら同じように利用できます。いちから自分で作らなくても良いのでとても助かります。

導入/設定方法

この入門編では、”JavaのGradleプロジェクトをビルドしてAWS Lambdaにアップロードする設定”を紹介します。トリガーや詳細、追加設定内容は以下の通りです。

  • ‘feature/deploy-test’にpushされたら実行する
  • JavaはJDK 1.8を利用する
  • 成果物は保存する
  • 既存のAWS Lambda関数に成果物を反映する

1. 設定ファイルを作成してビルドする

設定ファイルはYAMLで記述します。設定ファイルは  「.github/workflows」 に配置する必要があります。恥ずかしながら私は最初に 「workflow」ディレクトリを作ってしまい、うんともすんとも言わない無駄な時間を過ごしてしまったので、しっかり「workflows」 ディレクトリを作りましょう。そんな凡ミスをしないためにも、設定ファイルはGitHubの画面から作成することをオススメします。

GitHub Actionsの画面を開くと「Choose a starter workflow」の画面が表示されます。自分のリポジトリにあったワークフローがいくつか提案されているはずです。
JavaのGradleプロジェクトをビルドするべく、「Java with Gradle」の「Set up this workflow」に進むと以下のYAML構文が表示されます。

「uses」では再利用可能なActionを指定します。この初期サンプルではcheckoutsetup-javaを利用しています。
他の構文についてはリファレンスのワークフロー構文を参照してください。

サンプルのままだと、トリガーの条件が「masterブランチにpushされたら」、または「masterブランチに関するpull_requestでなにかしらのイベントが発生したら」なので、設定したい条件の「’feature/deploy-test’にpushされたら」になるように変更します。

こちらについてもより詳しく知りたい場合はリファレンスを参照してください。トリガーのイベントについてはこちらワークフロー構文のonについてはこちらです。

さて、これで最初の準備ができました。’feature/deploy-test’ブランチにこのファイルをcommit&pushすると、記述した処理が実行されます。
Actionsの画面でこのような画面が表示されれば、ビルド成功です。

2. 成果物を保存する

ビルドでできた成果物を保存して画面からダウンロードできるようにします。
成果物の保存には、upload-artifact Actionを利用します。ファイル名やパスをプロジェクトに合わせて記述するだけです。

上記の構文を追加してcommit&pushすると、またワークフローが実行されます。コミットコメントのリンクをクリックして遷移した画面には、以下のようにArtifactsにファイルがあるはずです。

Artifacets

3. AWS Lambdaへのアップロード設定をする

はやくも最後のステップです。appleboy/lambda-action を利用してAWS Lambdaの関数に反映します。
前提条件としてすでに作成されているAWS Lambda関数に反映します。まだ Lambda関数がない場合は作成してから試してください。

AWS LambdaにファイルをアップロードするユーザーのアクセスキーIDとシークレットキーIDが必要です。AWSユーザーに必要なポリシーは以下です。

AWSユーザーのアクセスキーIDとシークレットキーIDが発行できたら、AWS Lambda関数があるリージョンとともにGitHubのSecretsに登録します。
GitHub Secrets
AWSの準備が終わったら、ワークフロー構文を追加します。

まずは dry_run: truepublish: falseにして各種設定が正しいことを確認します。成功したならば、いよいよ本番です。dry_run: false と publish: trueにして実行します。
これも成功したなら、AWSマネジメントコンソール上でLambda関数の最終更新を確認しましょう!きっと反映できていると思います。

4. 入門編設定ファイル

これで入門編は終わりです。おつかれさまでした。
ステップ1〜3で設定したファイルは以下のようになっていると思います。

さいごに

GitHubActions入門編として”JavaのGradleプロジェクトをビルドしてAWS Lambdaにアップロードする設定”を紹介しましたが、いかがでしたでしょうか。すぐ「やってみよう!」と思ってもらえたり、実際に試してもらえたら嬉しいです。
ハプニング再発防止と開発リードタイムの短縮作戦の完遂に向けてまだまだ設定を進めていきますが、GitHub Actionsではさまざまなことが自動化できるので、リリース作業の他にも自動化できることがあれば積極的に試していきたいです。