アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

Amplify Console の Branch Autodetect でステージング環境を自動で作り放題

morishitaです。

以前、Nuxt.js のSPAの稼働環境としてAWS Amplify Console を紹介しました。

tech.actindi.net

とても便利に使っているのですが、先日、次の機能追加があり、更に便利になりました。

aws.amazon.com

早速使って見たので紹介します。

Branch Autodetect ってどんな機能?

Amplify Console ではブランチ毎に専用環境が用意され、そのブランチにPushするたびに自動的にデプロイされる機能があります。 これまではどのブランチをその対象にするかを事前に設定する必要がありました(Amplify用語ではブランチを接続するといいます)。
今回追加された Branch autodetection はその名の通り事前設定なしで、ブランチ毎の環境を作ってデプロイしてくれます。
全ブランチが対象というわけではなく、事前にブランチ名のパターンを設定しておきます。するとそのパターンにマッチするブランチをリポジトリにPushするだけで新たな環境を自動的に追加しデプロイしてくれます。

ということは開発中に作業ブランチ毎に本番とは独立した環境=ステージング環境が自動で作れるということです。
いくつもの開発が並行で走っても互いに干渉しないステージング環境で動作確認ができます。

設定してみる

アプリの設定の「全体」で設定できます。 下の方にまだ翻訳もされてない追加ほやほや項目がそれです。

f:id:HeRo:20190801081757p:plain
全体設定

編集モードに入ると設定できます。 有効にしていない状態では隠れていますが、Branch autodetection のスイッチを Enabled にすると次の項目が表示されます。

  • Branch autodetection - patterns
  • Branch autodetection - access control

f:id:HeRo:20190801081729p:plain
Branch autodetection の設定項目

Branch autodetection - patterns

ブランチ名のパターンを設定する項目です。 * にすると全ブランチが対象になりますが、まあ普通全ブランチを対象にする必要はないと思うので、個別ステージングがほしい場合のブランチ名のプリフィックを決めるといった運用をすることになるかと思います。

当社では d/〜から始めるブランチでステージングを用意する運用をしようと思うので d/** と設定します。

UI上の例では "*", "*/**"のようダブルクオートでパターンを囲っていますが、実際の設定では不要。というか付けるとマッチしなくなってしまうのでご注意を。

Branch autodetection - access control

access control はBASIC認証の設定です。usernamepassword を設定します。
ステージングとして利用するなら設定しておくほうがいいでしょう。開発途中をパブリックに公開したくないでしょうし、うっかり検索エンジンにインデックスされてしまうと本番サービスに悪影響が生じます。

ブランチをPushしてみる

では、上記の設定にマッチするブランチをリポジトリにPushしてみるとどうなるか見てみます。

Pushしてちょっとすると次の様に新たな環境が追加され、プロビジョニングが始まります。

f:id:HeRo:20190801082832p:plain
プロビジョニングの開始

で、処理を待っているとビルド->デプロイ->検証と進み、アクセスできるようになります。
URLは Amplify Console が用意するドメインのサブドメインとなります。
サブドメイン名は基本的にブランチ名となりますが、/(スラッシュ)は -(ハイフン)に変換されます。

アクセスしてみると設定したBASIC認証でアクセス制限もされています。

アプリの設定の「全般」のブランチリストにも追加されています。

f:id:HeRo:20190801083021p:plain
ブランチリスト

カスタムドメインに自動でブランチを追加してはくれないようです。
追加したければ自分でカスタムドメインの設定にサブドメインとして割り当てる必要があります。
まあ、開発中に使うステージングなのでドメインは気にしないケースがほとんどではないかと思います。 別サブドメインのサービスとCookieを共有したいなどの要件があると別ドメインのステージング環境を含めちょっと工夫が必要になるかと思います。

作業ブランチをマージするとどうなるか?

一応、「本番稼働ブランチ」という設定項目があるので、masterにマージしたらそのブランチの接続を自動削除してくれないかなぁと淡い期待を抱いていたのですが、 残念ながら何もしなければ一度できた環境はずっと存在し続けます。

放置すると使い終わったステージング環境が大量に残ってたという事態になりそうです。アクセスしなくても不要なストレージコストもかかるので削除していくほうがいいでしょう。
業務終了時間にパターンにマッチするブランチの接続を全消去するとか、master にマージされたタイミングで始末する仕組みを考える必要がありそうです。
ちなみに AWS CLISDK でも Amplify Console の操作がすでにサポートされています1

まとめ

このようにちょっと設定を追加してやるだけでステージング環境作り放題が実現できます。

Amplify Console はアプリケーションの構成によっては DynamoDB などバックエンドも作るので、どんどん環境を増やすってわけにはいかないアプリケーションもあるかと思います。
しかし、私が今やっているプロダクト は Nuxt.js の SPA のフロントエンドだけなので、気軽に増やしても構わないかなと思っています。
一方、使い終わった環境の後始末は要検討です。Lambdaで実装して定期実行しようかな。

最後に

アクトインディではエンジニアを募集しています。 actindi.net