今回は先日遭遇したトラブルについて書いていきます。

トラブルの概要

とある機能を実装⇒ステージング環境に反映し動作確認もOK⇒「これ本番だと上手く行かないよ」と指摘が入る

ということがありました。

なぜ起きたかと言うと、ステージング環境と本番環境で一部異なる部分があったからです。

そこを考慮できていない実装になっていた為、慌てて修正を行うこととなりました。

この場合、環境の違いだけでなく仕様についても理解が不十分だったことも原因の一つです。

今回の件で環境の差異をピンポイントで踏み抜いたので次回以降は同じミスはしないよう気をつけます。

開発環境

開発を進める環境はいくつかの段階に分かれていることがほとんどだと思います。

企業によっても様々ですが、一般的には以下の3つに分かれているかと思います。

開発者が実装を行う環境です。チーム内で環境を揃えるためにDockerを使うことも多いです。

Dockerで共有しておけば簡単に環境構築を行えますし、何か不具合があっても修正も容易です。

また、自分の手元の環境なので色々試すのも自由に行えます。

開発が完了したコードが実際に想定通りの挙動となっているか検証するための環境です。

「動作確認したときは問題なく動いたのに本番にデプロイしたら動かなかった」というケースを避けるため、本番環境とほぼ同一の環境とすることが多いです。

これにより、ステージング環境できちんと動作確認ができれば本番でも動作することが担保されます。

Docker等で構築したローカル環境はあくまで擬似的なものなので本番環境と同じ環境を用意することは難しいです。

なので、本番環境に限りなく近い環境で検証することが必要であり、そのためのステージング環境となります。

ローカル環境やステージング環境は社内だけで使用するための環境ですが、本番環境はエンドユーザーが実際に使用するのが本番環境です。

ステージング環境での検証が完了し、問題ないことが確認できたコードを本番環境にデプロイすることが開発のゴールと言えます。

エンドユーザーが実際に触れる環境なので自由にデータを触ることはできません。

上記の通り、ステージング環境は本番環境に限りなく近い環境であることが求められます。

ツールのギャップを小さくする: 開発環境と本番環境をできるだけ一致させた状態を保つ。

とあります。

しかし、現実的に同一の環境を用意することは難しい場合も多いです。

コストの問題やメンテナンスの問題など要因は様々あるかと思います。

なので環境ごとの差異についてはチーム内及びチーム間で十分に共有しておくことが必要です。

今回もその点を共有いただけたのでリリース前に気づくことができました。

今回のトラブルは個人的には良い機会だったと思います。

もちろんトラブルが無いに越したことはないんですが、失敗したことで環境の差異や仕様について把握することができたのは良かったと思います。

今後もこうしたケースは起こると思うので都度対処していければと思います。