最初使っていなかったNetlifyを使いたくなった理由
もともと何でNetlifyを選ばなかったのかと、なぜ良いと思ったかの両方を書くことがこのページの目的。
選ばなかった理由
GitHub Pagesで満足していた。
料金がかからない、
好きなブランチを一つ選んでデプロイできるし、
カスタムドメインつくし、
それと、どこかの記事でNetlifyよりレスポンスが早いと書かれていたので、わざわざサードパーティのNetlifyを使う気がしなかった。あと、名前の後ろlifyの部分の音の響きが何となく気に入らなかった。
理由は、プルリクエストごとに、プレビューサイトを作成してくれるところ。 プルリクエスト上で、以下のように色々チェックされて、プレビューサイトへのリンクもある。
https://gyazo.com/8c910a2530e90727272d30de2c84a38e
プレビューページは、https://deploy-preview-PR番号--サイト名.netlify.comのようなサブドメインが与えられる。
正直、この一つ機能が強力すぎて、GitHub上で開発している静的サイトをNetlifyにデプロイしたほうが良いという判断になった。あと、GitHub Pagesでやりたかったことを満たしいたことも判断基準。プルリクエストをレビューするときに、結局最後は実際の画面が見たくなる。自動デプロイされたので、TypeScriptのトランスパイルとかBabelとかProductionの特別な処理とかそういうものを全部通過してプレビューされている安心感も得られる。
これが偉大すぎるので、Netlifyにデプロイしたら良いという判断になった。
ブランチデプロイ可能なのは知っていたが、自動ですべてのブランチをpushしたタイミングでデプロイがトリガーされるのはとても良かった。
このプルリクストの機能を有効にする方法は、NetlifyでGitHubのリポジトリを結びつけて、「Build command
」と「Publish directory」しただけで、それ以外何もしてないはず。すごく手軽に設定できるところも素晴らしいところ。あとは、PR来たら自動でトリガーされてくれる。
フリーだと転送量100GB制限とか500 req/minとかの制限あるので、
プロダクションのデプロイ先はGitHub Pagesで、プルリクの自動プレビューとしてNetlifyを使う
みたいなことをしていいと思った。
将来の変化
いま知っているNetlifyの機能だけを使い続けるなら、
もちろんGitHub代替で、GitHubの問題点を解決してくれるソースコードホスティングサービスが出来れば、 GitHubからも変更する可能性がある。
とにかく、GitHub PagesもNetlifyも素晴らしいサービスで、無償で使わせてもらえるのがとてもありがたい。