菊池 Blog

移転しました 続・菊池 和彦の足跡

AILight Banner
AILight Blog

プロフィール

菊池 Blog

目次

Blog 利用状況

記事分類

過去の記事

タグ

ビルドの自動化

ミッション:ビルドを自動化セヨ! - @IT

自分の目的論とはちょっと違うんだよなぁ。

  1. 手動ビルドではミスを完全に防ぐ事は不可能である

    あってはならない事だけど過去に自分の周りであった話、テスト環境と本番環境がある場合に、テスト環境にデプロイするつもりで本番にデプロイしちゃったとか。こういう間違いはユーザ(この場合は開発者)インプットを受ける限り避けられない、だからユーザインプットを減らす。コンピュータ上でスケジューリングを行い最終的にはユーザインプット無しで駆動する事で操作ミスを排除する。

    DB構築スクリプトを本番環境で流しちゃったとか言う悪夢な話は避けたいですよね。
  2. そのリリース物はテストされてますか?

    コンパイルされたバイナリならコンパイルエラーぐらい無い事は事実だけど、スクリプト言語とかでは実際問題として動作させて見ないと解らない。テストを通すことによってそれがテストされている事を保障する。
    自分にとってのテストコードはコードの一行一行が正しいという事に保障をつける物で、いわば正しいという事の裏づけなのである。保障されていない物などはただのゴミである。
    ビルド結果としてはゴミではない成果物が必要なのだからビルドの中にテストも含めなければいけない。

    単体テスト等はコンパイルされたバイナリに対して行わなければ意味が無いのだ、昔にやった事があるなんてのはまったく無意味で、それは「別の単体」に対して単体テストを実行したことがあるのに過ぎない。
  3. 毎回同じ事をするという保障が無ければ、時間軸にそったログを比較する事が無意味になる

    コンパイル、テスト、コードカバレッジ、プロファイリング、いろいろな事をビルド作業の中で行うわけだけど、プロジェクトの進行中にこれらを常に一様の基準で取ったログが無ければ、品質や性能という面での比較ができない。
    比較検証した結果として「品質が上がってる/下がってる」、「性能が上がってる/下がってる」という事がわかり、これが把握できて初めて「品質を上げよう」とか、「性能を上げよう」とか言う事ができる。

    要するに、絶対指標の無い物は「過去の任意のものと現在のものを比較する事ができ、比較結果に基づいた改善行動ができる」ことを「管理できる」と言う事ができる。その代表は品質である。品質にしても性能にしても管理できるというからには比較して意味のあるログが必要なのだ。
  4. 「お前が悪い」という言葉を人ではないコンピュータに言わせる

    基準が明確でクリアする為の指標がはっきりしていて、区別、差別無く、たとえはっきり言われても誰に対しても不平不満を持つ事ができない。
    人間系で「お前が悪い」と言うのは余計な問題がいろいろ出るから、コンピュータに言わせる。

楽をする事よりもまず、人間系で発生する操作ミスその他による結果のブレを排除する事で、プロジェクトを管理可能な状態にする(管理指標の取得基準を一様にし、常に管理指標を取り続ける)ために、ビルドを自動化する。

んなわけで、管理職なのにビルドサーバを立てるのに難色を示すなんてのは自分にしてみれば愚の骨頂なわけである。

投稿日時 : 2006年9月9日 16:10


コメントを追加

#  re: ビルドの自動化 2006年9月11日 12:01 tsune

これとっても重要! >「お前が悪い」という言葉を人ではないコンピュータに言わせる
タイトル
名前
URL
コメント