3.開発環境

ソース管理の実施

• ソースのバージョン管理「元に戻す機能」。
• ロックを使用すると競合の問題はなくなるが、ロックの解除を忘れると悲惨だったり欠点あり。
• tagはマイルストーンに対して意味のあるラベルとして使える。
• branch
  • リリース時にbranchを作り、保守用に利用することで、次バージョンに向け--コードベースに劇的な変更をするような新機能の開発時にtrunkに影響を与えずに開発を進めることができる。
• グループで開発する際に便利なユーティリティ
  1. ウェブインターフェース
     • 一覧参照、diff（差分）の表示など
  2. コミットログのメーリングリスト
  3. コミットログのRSSフィード
  4. コミットデータベース
     • コミット処理をRDBMSに記録しておくことで、誰が変更したのか、いつ変更されたのかなどを即座に調べることが可能。
  5. コミットフック
     • コミットやbranch作成、ファイルのロック時などに他のユーティリティを起動したり、自動テストを実施したりできる。
• 代表的なソース管理システム
  1. Concurrent Versions System
  2. Subversion
  3. Perforce
  4. Visual Source Safe
• ソース管理に入れるべきもの
  • ドキュメント
  • アプリケーションの設定ファイル
  • ビルドツール
• ソース管理に入れるべきでないもの
  • コンパイル済みのソフトウェアなど

作業環境

• 作業環境のモデル
  • 開発環境
    • あらゆる新規コードの作成、テストの場。
    • マメにソース管理システムと同期しておく（毎朝始業時など）
• ステージング環境
  • 開発環境ではソース管理と完全に同期とれていないことがほとんど。（自分のところでうごいても本線のソースでちゃんと動くかは保障できない）完全に同期しようとすると、開発者全員が完全に足並みをそろえないといけなくなる。
  • ハードウェアとデータプラットフォームが開発用と実運用用では動作が異なることもある。
  • 開発環境で構築されたアプリケーションを実運用環境時と同じ環境でテストするための環境。
  • スナップショットを取り出して実運用ハードウェア上の実運用データでテストが可能になる。
• 実運用環境
  • ユーザが目にすることのできる唯一の環境。
  • ステージングサーバからコピーする。

1ステップビルド

開発、コミット・ステージング、デプロイ（展開）の一連の処理を1ステップで自動的に実行してくれるツールをつくる。複雑な作業を1ステップで実施できるようにしておくことでミスが減る。

• 開発用と実運用用の設定ファイルを両方ともソース管理に保存しておくテクニック
  • 「基本的な（環境に左右されない）すべての設定と、開発用の設定を書いたファイル（config.php）」と「ステージングと実運用固有の設定だけを書いたファイル（config_production.pho）」を用意しておく。
  • ステージング時にconfig_production.phpをconfig.phpの末尾に追加した最終版の設定ファイルを作成する。開発用の設定より後に実運用用の設定が書かれているため、実運用時には開発時の設定を上書きされる。
• デプロイ
  • ステージングされたコードにリリース番号と日付のタグを付けて実運用サーバにコピー
• 自動化すべきでないもの
  • データベースのスキーマ変更
    • スキーマの変更は大きなテーブルになると長時間ロックすることになる
    • フィールドの削除では削除したデータは帰ってこない
    • ひとつひとつ注意深く検討する必要があるため、自動化しない方がよい
  • ソフトウェアとハードウェアの構成変更
    • ドライバのアップグレード
      • ステージング用サーバで実施してテストした後、作業を適用するためのスクリプトを作成して、実運用サーバを1台ずつ取り出して適用
    • Webサーバなど基本サービスを提供しているソフトウェアのアップグレード
    • アプリケーションの開発→展開用とは別に、構成の展開用のツールも作っておくと良い

問題の追跡管理

開発上の未解決の問題（不具合、要求の不一致）がどうなっているか追跡する。
小さな規模の解決の場合付箋紙を使うのが有効だが、ある程度の規模になると、問題の優先度を決めてマイルストーンを追跡管理するツールが必要になる。

• 問題追跡管理ツール
  • 最低限の機能
    • 「問題」という実体に対して、「タイトル」「説明」「メモ」「所有者」「担当者」「状態」が含まれること。
  • ソフトウェアの例
    1. FogBugz
    2. Mantis Bug Tracker
    3. Request Tracker
    4. Bugzilla
    5. Trac
  • 何を追跡管理すべきか
    1. バグ
       • すぐには修正しないものも項目はつくっておく。関係する開発者を担当者に割り当てて優先度を設定。
    2. 機能
       • 新機能を計画したら、各機能に対してタスクやサブタスクを追加して進捗を管理する。
       • バグを一緒に管理することで開発者自分が抱えている残作業を全体的に把握可能。
    3. 作業
       • 即座に完了すべき作業以外はすべて。
       • ある作業をすることになっているが、他の作業の待ち状態になっているとき、行いたい作業に対して「問題」を作成して、そこから完了待ちの「問題」へのリンクを張れば、まだ終わっていない作業がいつ完了したか追跡管理可能になる。
       • 作業に必要な詳細事項を全てメモとして追加しておく。
    4. サポート依頼
       • 顧客サポートも追跡管理する必要がある。

• • 問題のカテゴリ化
    1. S1/高
       • 即座に対応する必要のある問題。現在の開発を中断させてでも取り掛かる必要のあるもの。
       • システム停止に関わるようなもの。
    2. S2/中
       • 重要だが、現在の作業を中断するほどではない問題。
       • 重要な機能、比較的重大なバグ修正など。
    3. S3/低
       • 新機能のための作業などあまり本質的ではない問題。
       • S1またはS2の問題がなくなったら取り掛かる。

テスト

• • • リグレッションテスト（回帰テスト）
      • バグが発見されたら、現在は通らないテストケースを作成し、それが正しく通るように修正する。
      • 以後コードを修正した際に、同じバグが発現しないことを保障できる。このようなバグのある状態に退行することを防ぐためのテストをリグレッションテストと呼ぶ。
    • 手動テスト
      • 最低でも開発担当者と機能について詳しくない人の2人でテストを行う。
      • テストすべき機能を網羅するために
        1. 主要な機能を抽出
        2. 理想的な利用パス（ユーザが実行する可能性が一番高い操作）のテスト
        3. 境界条件のテスト

スケーラブルWebサイト