kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

本番環境は出来得る限り早めに用意し、早期からビルドを定期反映する


表題のとおりなんですが、リリース直前/前後の無用なトラブルを避ける為の鉄則でございます。

ただし、これをやる事での弊害が有ります。

  • 早期ビルドの(当然の)不安定性についての雑音がすごく多くなる

早期ビルドなんてへたすりゃまともに動くのなんて数割にも満たないと言っても過言ではないって事を理解しない人が早期ビルドを見て大騒ぎします。

その道を理解している人が安易に「よくある事です」というと「そんな事よくあっちゃ困ります」とすごい剣幕で乗り込んでくるパターンは非常によくある事です。

「技術的に問題を考察し、バグレポートを適切に書ける人」に早期ビルドを見せるのは多いにメリットがあります。

うろたえた挙句に「説明を求む」等と言いだして会議を招集し開発時間を奪い結果的に邪魔をしそうな人には見せてもデメリットしかありません。

見せても邪魔にしかならない人こそ見せろって声がでかいので、うるさい奴にほど見せちゃいけません。なぜなら「うるさいだけの役立たず」となる彼らは不安なんです、だからこそ見た瞬間にうろたえ、邪魔にしかなってない事をやり始めるのです。

うろたえずに、今何をやるべきかを考えれば、不具合のパターンを洗うとかできるはずだし、結果的に開発チームに貢献する事もできるはずなのにです。

  • 毎回のリリース手間を消化しないといけなくなる

自動化重要、とりあえず自動化できないなら、この鉄則は逆効果を生みかねないのでやめましょう。

その場合のお勧めの策としては「本番環境へのインストールリハーサルです!」と言い切ってリリース物は確認したら削除しちゃいましょう。「リリース物を入れてみた時に不足するコンポーネントやその他が無い事を確認する」のが第1義で、「その後の変更で依存コンポーネントの増減が発生しておらず、確認済の手順でインストール可能である事を確認し続ける」のをトレードオフとしてあきらめる事ができればインストールされた早期ビルドの入った環境など捨てて良いんです。

という訳で、来月リリースな物の早期ビルドの展開スクリプトを書いているナウ。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。