GatsbyJSで作ったコンテンツをS3+CloudFrontで公開する その０
なぜこうした仕組みが必要なのかについて、もう少し丁寧に説明をします。
やりたいこと
このページを見ている方の大半は、要はこういうことがやりたいのだと思っています。
LPを作成
↓
クライアントに見てもらいOKをもらう
↓
本番環境にリリース
特に難しい事を考えずにやればよいのでは？と思う人も多いと思うのですが、本当にそれでよいのでしょうか。
何も考えずに行うと起こること
実は「やりたいこと」を後先考えずに行うと、例えば以下のような事が起きます。（ここに書いたことは一例で、他にもあると思います）
１．ソースコードが個人のPCにしかなく、チーム開発できない
２．本番環境でページ確認中に顧客が流入してしまう
３．本番とテスト環境でソースコードの保管先が違う
４．LP開発の生産性が低い
１．ソースコードが１人のデザイナーのPCにしかなく、チーム開発できない
ソースコードがLP作成者のPCにしかないため、チームで開発しようとしてもできません。一度LPを作って終わりなら問題にならないでしょうが、サービスが伸びて情報の追加や修正をする時に仕事を分担することができず、すべてLP作成者が行う必要があります。
もしLP作成者に連絡が取れなかったり作成者が忙しくて手が回らない場合、LPの追加や修正ができません。
２．本番環境でページ確認中に顧客が流入してしまう
訪問する人がほとんどいないページであればよいのですが、サービスが伸びて常に閲覧している人がいるとアクセスのたびにページの内容が変わることんあります。これではユーザから不信感を持たれてしまう場合があります。
３．本番環境とテスト環境でソースコードの保管先が違う
テスト環境を用意しても、本番環境とテスト環境でソースコードの保管先が別になっているとよほど注意しない限りはコードに不整合が発生します。人の努力ではなくて、仕組みで不整合が発生しないようにすることが必要です。
４．LP開発の生産性が低い
LPの多くは静的ページ、つまりhtmlとCSS（と画像）だけで作られたページなので、フレームワークを使わなくても開発できます。
しかし変数が使えないのでフッターのような各ページ共通に書くことも、各ページに書く必要があります。これだとページ作成の生産性が低いため、ページの追加・改修に時間がかかります。
問題の解決にやること
このような問題に対し、このような対応を取ることが多いと思います。
・GitHubのようなソースコードホスティングサービスを利用する
・テスト環境と本番環境の２種類用意する
・GitHubの単一レポジトリにソースコードを置く
・ページ開発のフレームワークを利用する
しかしそれでもこうした問題は解決できません。
・単一レポジトリにソースコードを置いても、テスト環境と本番環境への出し分けができない
・フレームワークを導入してページ作成の生産性を上げたが、サーバが必要になったため追加コスト発生
特に２番目ですが、htmlやCSSだけならAWSのS3や静的サイトホスティングんサービス（例えばNetlify）に置くだけでよいのに、サーバとなるとAWSのEC2とかVPSを利用する必要があります。
またサーバを利用すると大量にユーザの流入があるとサーバの高負荷によってページが閲覧不可となる可能性が上がるため、サービス紹介や申込の機会も逃す可能性が上がってしまいます。
それを防ぐために、エンジニアの方や業者にお願いをして管理してもらう必要が出てきます。そのため、S3やNetlifyを使う以上のコストが必要となります。しかし管理をするエンジニアや業者の方を除き、できればコスト発生を防ぎたいと思う人が大半ではないでしょうか。
このページで紹介する仕組みの意義
今回作った仕組みによって、以下のことが実現します。
・ソースコードをGitHub上に保管して、チームでLP作成ができる
・単一レポジトリのコードをテスト環境と本番環境に出し分けできる
・テスト環境で確認できて、OKなものだけを本番環境に反映できる
・独自ドメインとHTTPS接続が利用できる
・Gatsby.jsを使ってLPの開発生産性を上げつつも、サーバ不要にできる
・S3にはGatsby.jsで生成されたhtml/CSSファイルと画像だけを置ける
・ベンダー依存度が低い仕組みなので、別サービスへの移行が行いやすい
もちろんこの方法がすべてではないですが、方法の一つにはなると思います。
現在のWebでは、個人開発や小規模サービスだったら問題にはならない方法なら多く見つけることができます。しかし、チーム開発や中規模以上のサービスにおける開発を想定したものになると急に資料が少なくなるので、今回こうしたページを作成しました。