プログラマが知るべき97のこと/そのコードに触れてはならない！
ステージングサーバでのシステムテストに入ってから、自分の書いたコードに問題が見つかり、それを知らせるメールがテストマネージャから届く、そんな経験はプログラマなら誰もがしていると思います。そのメールを見た時にプログラマが最初に思うことは、「すぐにそっちへ行って直させてくれ。どこが悪いかはわかっているから」ではないでしょうか。
「プログラマがステージングサーバを触ってもいいじゃないか」そう考えるのは一見、間違ってはいないように思えます。しかし、大局的にとらえるとやはりそれは間違いなのです。なぜでしょうか。
Webシステム開発プロジェクトの環境は、次のようにアーキテクチャ分割されているのが普通です。
- 開発者のマシン上の、ローカル開発/ユニットテスト環境
- 統合テストを手動、あるいは自動で行う開発サーバ
- 品質保証(QA)チームや顧客が受け入れテストを行うステージングサーバ
- 本番環境
もちろん、実際にはこれですべてではなく、他にもソースコード管理(SCM)や問題管理システム(ITS)などのサーバやサービスなどが色々と関わるのですが、おおまかには上のとおりと考えていいでしょう。上記のように分割されている場合、開発者は(たとえ上級開発者であっても)決して、開発サーバより後の環境に触れるべきではありません。開発の大半は、開発者のローカルマシンで行われます。開発者はローカルマシン上で自分に合ったIDEや仮想マシンを利用し、その他にも独自のツールを使うなど個々に工夫して、良いコードを書くために最善を尽くします。
SCMへチェックイン後は(自動であれ手動であれ)開発サーバに配備させて、そこで必要に応じてテスト、修正を行うことになります。そのテストにより、全体が問題なく機能するか確認するのです。ここで注意すべきなのは、チェックイン以降は、開発者は基本的にはプロジェクト進行の「傍観者」になるということです。
コードをパッケージングして、QAチーム向けのステージングサーバに配備するのは、ステージングマネージャの仕事です。開発者が開発サーバより後の開発環境にアクセスすべきではないのと同様、QAチームおよび顧客は、開発サーバ上のものには手を触れるべきではありません。あくまで受け入れテストが出来る状態が整ってからリリースし、配備するのです。
たとえば「開発サーバ上のシステムをちょっと見てくださいませんか?」と顧客に頼んではなりません。そのプ口ジェクトでコードを書いている人間が1人だけであれば話は違ってきますが、普通は他にもコーディングをしている人がいるはずです。全員が「いつユーザに見られても大丈夫」という状態でいるとは限りません。開発サーバとステージングサーバの両方にアクセスできるのは、リリースマネージャだけにすべきです。
そして、たとえどんなことがあっても、開発者は本番環境に触れてはなりません。問題が起きた場合でも、それを修正するのは基本的に運用チームの仕事であり、仮に開発者が修正にあたるにしても、それは運用チームからの依頼であるべきです。そして修正をSCMへチェックインした後で、彼らがSCMからパッチを作成して運用するのです。私がプログラマとして経験した中でも「最悪」と言える事件は、誰か(まあ、それは私、なんですが。。。)が、この「必ずSCMへのチェックインしてSCMからパッチを作る」というルールを守らなかったために起きたものでした。たとえシステムのどこかが壊れても、本番環境でそれを修理しようなどと考えてはいけません。