GoogleCloudFunctionsの環境分けについて

プロジェクトに導入しようとなると、dev環境、stg環境、prd環境など一つ以上の環境が必要となっていくる。
GoogleCloudFunctionsを導入した場合、どのように環境を分けたら良いのかざっくりと調査してみた。

いきなり結論

公式のベストプラクティスの中に、

注: 開発環境、テスト環境、本番環境を分離することをおすすめします。そのための 1 つの方法は、各段階で別個の GCP プロジェクトを使用することです。また、可能な場合は、システムテストのリソースにグローバルに固有の名前を割り当てることもおすすめします。こうすることで、システムテストを同時に実行してもテストは互いに干渉しなくなります。リソースにグローバルに固有の名前を割り当てるには、テストを実行する前に（たとえば、test.before フックで）必要なリソースを作成します。テストが完了したら、（たとえば、test.after.always フックで）リソースを破棄します。

とあるのを見つけた。
環境の分け方だけにフォーカスしてみると、環境別にGCPのプロジェクトを分けるといいとある。

自分なりに考えたこと

上記、 GCPのプロジェクトを分ける ということを見つけるまでは、
環境別のデプロイどうするのかな？
例えばcircleciなどでデプロイするには環境別のjob作って、
その中で環境を表すprefixなどをつけてデプロイしてGCF上での区別をつけるのかな？
とか考えていた。

でも公式見てハッとさせられた。
プロジェクト分ければいいんだと。

ただ、プロジェクト分けるのが難しいケースやめんどくさいケースもあると思った。

例えば、すでにGKEを使ってプロジェクトを利用していて、
GKE上では環境の区別をクラスターでやっている。
でもGCFを導入するとなると違った考えて環境を区別しないといけなくなる・・・
どうしよ？そういうもんと思って諦める？あー考えるのめんどくさとか。
（極端な例です）

もしくは、大きい会社などはGCPのプロジェクト管理はどこかのインフラ部署が担当していて、
払い出してもらうのにいちいち申請が必要・・・とか。

逆にマッチする状況を考えてみると。
アプリケーションとしてボリュームがないからGCFの方が要件にあっている、
今後も拡張される予定はないし、GKEやGCE使ってアプリケーション作るのは流石に時間かかるし・・・
っていう状況だったら利用はありかな。

あとはフロントエンジニアしかいないけど、ちょっとだけバックエンドが必要になった時とか
nodejsで実装できるからそういった状況にはマッチしそう。

ただ、バックエンドのエンジニアがいてGKEやGCEの利用にも慣れている・・・
っていう状況であればそれこそ今後のことを考えると導入には慎重になってしまうのでは。

そんなことをグダグダ考えてみた。
結局はプロジェクト次第！！
（楽をした）