個人サービスでFirestoreの本番データを検証環境のAlgoliaにデータを保存してしまった

起こったこと

Firestoreのデータのマイグレーションを行ったところ、マイグレーションでデータが生成され、それがCloud Functionsにトリガーされ、Cloud Functionsに設定されているAlgoliaのデータの保存先が検証環境を向いていたため、本番環境のデータを全て検証環境のAlgoliaにデータを保存してしまった。

原因

要因は二つ

・マイグレーションしたらCloud Functionsがトリガーされることに気づかなかった
・Cloud FunctionsのAlgoliaの保存先を検証に向いたままデプロイしてしまった

再発防止策

再発防止策として下記の２つの行いました。

・マイグレーションを行うときは必ずチェックリストを作成し、そのチェックリストに「実行前にCloud Functionsのトリガーの発火状況を確認する」という項目を追加する
・Cloud Functionsの向き先情報を環境変数として、Cloud Functionsに直接保存し、ソースコードが自動的に環境変数を見にいくように修正する

-----------------------------------------------------------------------------

ここまでは報告でしたw
現在「失敗の科学」という本を読んでいて、「失敗から学ぶことこそミスの数を段階的に減らしていき、成功の確率をあげる。」というような文章を読んだためこんな記事を書いています。

本書では、なぜ飛行機はほとんど事故が起きないのか、という題材でその理由について深く考察しています。いろんな文献からも真実を引用したりもしていて良書でした。

失敗の科学 失敗から学習する組織、学習できない組織

なので、失敗から学び、再発防止策について書いていきます。

チェックリスト

マイグレーションときには下記のチェックリストをコピーしてから、今回の変更分を追加して、チェックリストを作成する

Cloud Functionsの環境変数を設定する

Cloud Functionsの環境変数を設定することでソースコードから環境ごとに保存された環境変数を参照しにいくのでソースコードに手をいれることなく、本番環境の向き先と、開発環境の向き先を変えることが可能です。

環境の構成  |  Firebase

やり方はいたってシンプルで

firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"

このコマンドで環境変数を設定することができます。

確認するには下記のコマンドから確認

firebase functions:config:get

結果↓

{
 "someservice": {
   "key":"THE API KEY",
   "id":"THE CLIENT ID"
 }
}

ソースコードからは下記のような感じで参照します。

functions.config().someservice.id

以上です。