開発環境と本番環境 第05回 20年04月 / 最終更新：2020.04.07
今回は「開発環境と本番環境」について、理想と現実の2つの側面から色々と考察をしていきたいと思います。
この辺りは割と色々とトラブルのお話を伺うので、運用面や費用面なども考えながら、いくつか考察をしていきたいと思います。
まず一番マズいと思われる、ただ定期的に伺うのが「本番環境のみ」というケースです。
経緯としては「サービス本番化前までは本番環境で開発、その後もなんとなく慣習的にそれが続いた」といったケースを、比較的多く伺います。
また、現場さんによっては「修正も直接本番のコードを触る」というお話を、実際に何度か伺った事があります。
勿論ケースバイケースではあるので「絶対に駄目」とは言わないのですが。「ごく軽微な文言の修正」を超える修正変更がある時の、エンジニアさんにかかる心理的負担は、かなり大きいのではないか、と思われます。
また「エラー画面がユーザに見えてしまう(かもしれない)」のも、比較的大きな問題点です。また、それを克服するために「エンジニアが修正するのを、真夜中～早朝に限定している」といったお話を伺ったときは、ちょっと色々と思案した事を覚えております。
そのため、「ごく軽微な文言の修正」以外は一切の変更がないサイトである、といった状況でもない限りは、出来るだけ「本番環境のみ」というケースは、避けたほうが色々とよいのではないか、と思います。
次に「本番環境と同じマシンに、別のディレクトリで開発環境。切り替えは「名前(domain)ベースのバーチャルホスト」で行う、といった運用を拝見する事があります。
こちらは、実は「相応にコンパクトなシステム」であれば、ある程度「なんとかならないこともない」環境ではあったりします。
ただ、「なんとかならない / 難しい」のが、ミドルウェアなどのアップデート。筆者はPHPを使う事が多いのですが、例えばPHP自体がバージョンアップした時に「いきなり本番サーバをアップデートするのか？」という問題が出てきます。
そこがなんとかなるのであれば必ずしも否定をする所ではないのですが、「アップデートはしない」という運用だとすると、ちょっと危険が伴うので、あまりお勧めはいたしません。
そうするとやはり、廉価ではよくても「開発環境は、本番環境とは別サーバで欲しい」という状況になります。
別サーバにしますと、例えばPHPのバージョンアップであっても「一端は開発環境でアップデート」「しばらくテストや開発で様子をみる」「問題がなければ本番環境をアップデート」といったやり方にする事で、より安心出来る環境を整える事ができます。
このケースの場合、やはり費用などの問題が出てきやすいので、端的には「開発環境用のサーバは、ある程度廉価なものでよいか、と思います。
このようにして開発環境と本番環境を切り分けていく、のですが、そうするとその次にやはり定期的に伺うのが「開発環境が御しくれなくて結果的にあまり意味を成していない」というお話になります。
これは、端的には「開発環境と本番環境で相応の差異がある」ために、多くの場合は「開発環境では動くが本番環境に持って行ったら動かなかった」というような内容に集約されます。
これについては、最終的には「開発環境と本番環境で差異が出ないようにする」という所になるのですが、そこにたどり着くまでのルートがいくつかありますので。現場やメンバーのスキル構成や経験や慣れ等にもよるので「ベストプラクティス」があるわけではないのですが、いくつか、ヒントになるようなものが提示できれば、と思います。
昨今は「個々のPCに開発環境を持っている」事も多いかと思うのですが、筆者は「1台、開発環境用のサーバを用意して、全員がそこで開発をする」というスタイルを取る事が多いです。
このやり方ですと、まず構築時に「開発環境と本番環境とで、同じインストール状態にする」からstartして、後は「開発環境に加えた変更は、タイムラグはあるにしても、同じ変更を本番環境にも適用する」という比較的簡単なルールを1つ守ることで、割合シンプルに「開発と本番での環境の差異」を防ぐ事ができます。
サーバへの変更は、構成管理ツールと呼ばれるもの(Ansible、Chef、Puppet、Bolt 等)を使うと綺麗に管理できる事も多いかと思いますが、インフラを古くからやっている技術者であれば、近しい相応のノウハウを持っている事も多々あるので、一度質問を投げてみるのもよいかと思います。
また、このように作る時は、出来るだけ「開発環境と本番環境は同じプラットフォーム上にある」ようにしたほうが、不要なトラブルを避ける事が出来る事が多いでしょう。
「開発環境はA社のVPS、本番環境はB社のクラウド」といった棲み分けは、メリットよりデメリットのほうが顕在化しやすいように思われます。
一方で。
個人のPCに開発環境を持つ場合、長らくVagrant が使われておりましたが、最近はDocker である事も増えてきているように思われます。
こういった環境で一番のネックは「個々が勝手に環境を修正し、かつその修正が全体に共有/告知されない」ようなケースで。
それをやると、そこそこの頻度で「開発環境では動くが本番環境では動かない」が再現できて、あまり嬉しくない状態になりやすいです。
Vagrant や Docer を使う場合、ルールとして「構成を勝手に変更しない」「変更するルートを作って、変更申請を上げられるようにする(そうしないと「開発できない」という理由でルールの違反や抜け道の模索などが横行します)」といったものが必要になります。
また、これらをやってなお「本番環境との差異」の問題が出てくるので。
Dockerであれば「同じイメージを使う」ことで比較的簡単に回避ができるので、イメージなりDocker Composeなりを使って「確実に同じ環境が構築できる」ような仕組みを整えておくとよいでしょう。そうすると「開発者間の開発環境の統一」だけでなく、「開発環境と本番環境と本番環境の統一」も出来るようになります。
ただ、それでもなお「環境で変更があったら、開発者全員が"開発環境の更新"をする必要がある」ので。
手順を確立して「開発環境の更新が比較的簡単に、迷わずに出来る」ような仕組みなりマニュアルなり質問ルートなりを作っておくとよいでしょう。
一方で、「ちゃんと更新しているかのチェック機構」については、甘めでよいので作っておいてもよいでしょう。
開発環境用は、割とあちこちで「あまり重要視されていない」ケースを見かけますが、そこに起因した事故は意外と時間を食うので、地味に金食い虫になってしまいます。
かといって「シンプルなサイトにあんまり大げさな仕組み」も牛刀割鶏になりかねないので。その辺りの加減が上手くできるようになるとよいのではないか、と思います。
短い間でしたが、本連載をお読みいただいてありがとうございました。
4月からは新しいトピックでの連載になりますので、引き続きよろしくお願いいたします。
サービス・ソリューション
