個人サービスでFirestoreの本番データを検証環境のAlgoliaにデータを保存してしまった
起こったこと
Firestoreのデータのマイグレーションを行ったところ、マイグレーションでデータが生成され、それがCloud Functionsにトリガーされ、Cloud Functionsに設定されているAlgoliaのデータの保存先が検証環境を向いていたため、本番環境のデータを全て検証環境のAlgoliaにデータを保存してしまった。
原因
要因は二つ
・マイグレーションしたらCloud Functionsがトリガーされることに気づかなかった
・Cloud FunctionsのAlgoliaの保存先を検証に向いたままデプロイしてしまった
再発防止策
再発防止策として下記の2つの行いました。
・マイグレーションを行うときは必ずチェックリストを作成し、そのチェックリストに「実行前にCloud Functionsのトリガーの発火状況を確認する」という項目を追加する
・Cloud Functionsの向き先情報を環境変数として、Cloud Functionsに直接保存し、ソースコードが自動的に環境変数を見にいくように修正する
-----------------------------------------------------------------------------
ここまでは報告でしたw
現在「失敗の科学」という本を読んでいて、「失敗から学ぶことこそミスの数を段階的に減らしていき、成功の確率をあげる。」というような文章を読んだためこんな記事を書いています。
本書では、なぜ飛行機はほとんど事故が起きないのか、という題材でその理由について深く考察しています。いろんな文献からも真実を引用したりもしていて良書でした。
なので、失敗から学び、再発防止策について書いていきます。
チェックリスト
マイグレーションときには下記のチェックリストをコピーしてから、今回の変更分を追加して、チェックリストを作成する
Cloud Functionsの環境変数を設定する
Cloud Functionsの環境変数を設定することでソースコードから環境ごとに保存された環境変数を参照しにいくのでソースコードに手をいれることなく、本番環境の向き先と、開発環境の向き先を変えることが可能です。
やり方はいたってシンプルで
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
以上です。
ここから先は
shogo.yamadaサービス開発研究所
shogo.yamadaがサービス開発についていろいろな考えや、アイデア、サービスを開発を継続させるための仕組み化の話をします。 現在SN…
投げ銭はいりません。それより無料でできる拡散をしてください!! 感想をツイートしていただけることが一番嬉しいです!!