Webサイトのテスト環境をGitからAWS Amplifyに変更したはなし

Webサイトの運営では、機能が追加された、説明内容に誤解を招く表現があった、ダウンロード資料を変更したなど、日々の更新が不可欠です。それらの更新一つ一つに対して、まずはテスト環境で試してから本番公開するというのが一般的です。

サイボウズでは、Webサイトのソースコードの管理にGithubを採用し、開発環境と本番環境をブランチで分けて運用していましたが、リポジトリ内の同ファイルに同タイミングで更新が入ることがあり、Gitだけでの運用に限界を感じていました。そんな折、AWS Amplifyでアプリ開発だけじゃなく静的サイトを簡単に構築できることを知り、Webサイトのテスト環境として採用することになりました。

実際にGitを利用してWebのソースコードを管理している方や、Amplifyってなんとなく聞いたことあるけどWebサイトとは関係ないでしょ？という方のご参考になればうれしいです。

SubversionからGitHubへ切り替え

社内のサーバーでWebサイトを管理していた時は、Subversionというシステムを利用してHTMLやCSSの履歴管理をしていました。

サーバーをAmazon Web Service（AWS）に引っ越すことを決めたと同時に、エンジニア界隈で最もスタンダードであるGitHubを採用することにし、Gitで更新したものをAWS上に展開するよう構築してもらいました。

ただその際も、AWSの開発環境で依頼者に確認してもらったのちにGitのdevelopからmasterにマージして本番公開するという、それまでのSubversionでのやり方を踏襲していました。

それまでSubversionも触ったことないため、履歴管理の仕組みが良くわかってない中、取りあえずGitはポピュラーだし今までと同じ履歴管理もできるし、安泰！なんて思っていたら、本当に全然わかってなかったんですね、仕組みを。

git cherry-pickという諸刃の剣

サイボウズのWebは１つのサイト配下に複数のメンバーから同時に更新依頼が入ることも多く、それまでは社内のHP更新チーム内で一人担当者を設けて、他の人は更新はしないよう声をかけ、更新依頼の優先順位を判断するためオーナーに確認しつつ作業を進めるという、かなり人力に頼った形で作業をしてました。

Gitになったらその辺の問題も解決するんでしょ？なんて、それまでGitを触ったこともない私は軽く考えていました。

しかし、Gitでもdevelopとmasterをブランチで切ってまるっと反映（merge）させる運用をしていると、複数更新が走っている場合developで確認中の他の更新も持って行ってしまいます。そこで、cherry-pick（チェリーピック）という、公開したい更新だけピックアップして反映するという手法に変更しました。チェリーピックに切り替えて数年、安定して運用されているかのように見えていました。

そんな中、とある大規模なプロジェクトで、Web更新会社のJ-COOLさんが更新してくれた箇所と社内の担当者が更新した部分を同時公開する際に、ピック漏れによりページが動作しないことが発生してしまいました。この時改めて、何度も微調整が入った後にすべて反映させるような場合、更新箇所を全部ピックアップすることが担当者に負担をかけていたことが露呈しました。

ピック漏れで動作しなかったケース

また改めてdevelopとmasterを比較してみたところ、一部のサイトでは大量のコンフリクトが発生していました。どちらかに改行が入ってしまっているなど、ほとんどが些末な問題だったのですが、あえてテスト環境だけ読み込むJSファイルを変更していたりと、個人の記憶に頼った運用をしている部分もありました。テストと本番があってないなんて意味ないし本当に怖い状態でした。

登場！　AWS Amplify

サイボウズの社内には「多様で価値あるサービスを迅速に提供するため、部署やプロダクトを横断して、生産的でオープンな開発基盤を整備する」というミッションを掲げた、生産性向上チームが存在します。

「チェリーピックしんどいし危険どうしよう～？？」の相談すると「せっかくAWS使ってるんだし、Amplify使えばいいんじゃない？」という鶴の一声をいただきました。

Amplifyとは（AWSのサイトより）
「スケーラブルなモバイルアプリケーションとウェブアプリケーションを無限の柔軟性ですばやく構築する」

？？？アプリケーションの作成時に使うもの？Webサイト構築に関係あるの？？？
早速クラスメソッドさんに具体的なメリット・デメリットやAmplifyならできること、できないことなどをご教示いただきました。IPアドレス制限など、今まで利用していた機能が一部使えなくなったりするものの、とにかく簡単に独立したテスト環境を構築できるという理解を得て、導入を決定しました。

Amplifyを導入後

更新ごとにGitのブランチを作成し、テスト環境を構築します。技術的な詳細はクラスメソッドさんのブログでどうぞ！

更新作業のながれ

①依頼者がHP更新依頼アプリに依頼レコード作成、J-COOLさんに通知が飛ぶ。
②依頼ごとのブランチを作成・更新すると自動でAmplify環境が構築される
　Amplify環境が構築されるとkintoneのコメントに通知が飛んでくる
③依頼者はAmplify環境で更新内容を確認
④OKならば該当ブランチをdevelopブランチに反映masterにコピーして公開

Amplify導入後のフロー

Amplify導入による副産物

Amplifyは該当リポジトリのデータ全体に対して「０」から構築するため、リポジトリのデータが重ければ重いほど構築に時間がかかります。そのため、構築が完了したら、HP更新のやり取りをしているkintoneアプリに自動でコメントを書き込むよう、生産性向上チームの支援のもと設定してもらいました。

kintoneに自動でコメント通知がきたところ

この仕組みを構築してもらって気づいたのですが、今まではGitからAWSの環境を作るのもリポジトリの容量によってかかる時間が変わるため、J-COOLさんが肌感覚で「このサイトならだいたい〇分後に完了する」というのを見計らって確認してくれてました。それでも反映されてなければさらに数分後に確認するという何ともアナログな手法をとっていたため、同時に複数の更新をしている中で、地味にストレスを感じさせていたということに気づかされました。

Amplify環境は、構築されたら通知が飛ぶため、Gitのコミットをしてからの時間を常に念頭に置いておく必要がなくなり、本来の業務に集中していただけるようになりました。
以上、AmplifyはWebサイト開発環境としても活用できるというおはなしでした。

※写真はCURRY&SPICE BAR 咖喱人＠飯田橋