ソフトウェア構成管理に必須のインフラについて

1. ソフトウェア構成管理のインフラ
Infrastructure for Software
Configuration Management (SCM）
α版
(C)Copyright 2009 Koki Yamamoto
kokiya@gmail.com

2. ソフトウェア構成管理（ SCM ）とは
Wikipedia より
http://ja.wikipedia.org/wiki/%E3%82%BD
%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E6%A7%8B%E6%88%90%E7%AE
%A1%E7%90%86
ソフトウェア開発プロジェクトをその成果物を通して制御・管理す
る方法論である。ソースコードや文書などの成果物の変更履歴を管
理し、製品のバージョンやリビジョンに個々の成果物のどのバージ
ョンが対応しているかを識別し、任意のバージョンの製品を再現可
能とする。

4. ソフトウェア構成管理（ SCM ）とは
ISO 文書管理規定や部署のバージョン管理規定
(リリース時にするべきことが定められている)
に従っていれば OK?

5. ソフトウェア構成管理（ SCM ）とは
引き続き Wikipedia より
SCM の一般的な目的は次の通り :
* 構成の識別 - 修正を施すべきコードはどれか？
* 構成の制御 - 製品のリリースとその修正を制御する
* 状態の記録 - コンポーネントの状態を記録し報告する
* レビュー - コンポーネント間の一貫性と完全性を保証する
* ビルド管理 - ビルドのためのプロセスとツールを管理する
* プロセス管理 - 組織としての開発手法を厳守する
* 環境管理 - システムの基盤となっているハードウェアおよびソフ
トウェアを管理する
* チームワーク - 開発に関するチーム内のやりとりを促進する
* バグトラッキング - 全ての障害について対処状
況を追跡可能とし、かつコード修正と対応付ける

6. ソフトウェア構成管理（ SCM ）とは
SCM とは、
ソフトウェア開発で継続的に実施す
ることが
必要な管理全般のこと
のように思える。

7. 開発規模と SCM 力

8. SCM 力を付ける動機
悲惨から普通へ
非効率から超楽へ
⇒いろんな開発規模に対応できる技術
者に

9. SCM 力は両輪で

10. 必須インフラ
バージョン管理システム
単一リポジトリ型
分散リポジトリ型
CVS
Git
Subversion
Mercurial
Perforce
Bazzar
Visual Source Safe
課題 ( バグ ) 管理システム
Trac
Redmine
Mantis
不具合連絡システム
継続的インテグレーションサーバー
Continuum
CruiseControl.NET
Hudson

11. バージョン管理システム
・必須インフラの中でも特にバージョン管理システ
ムが重要。
・一つの組織内では、同じバージョン管理システム
を使い、シンプルな方法で管理するのが好ましい。
・総合力で Subversion が優れている。

12. なぜ Subversion か ?
GPL
進歩と安定性
マージ方式とロック方式の両方に対応
日本語対応
日本語情報
他のインフラ、ツールとの連携
TortoiseSVN

13. Subversion 利用の肝
・ブランチ作成
- いつブランチを作成するべきか
- 作成したブランチをどう管理するか
・マージ機能
- マージの邪魔をしない
- マージを活用する

14. 結合方式
・ビッグバン結合
- ウォータフォール開発で行われる。
- 全てのモジュールを作成して単体テスト完了後、
結合を行う方式。
・継続的インテグレーション
(Continuous Integration、以下 CI)
- XP 開発で行われる。

15. - コードを作成してユニットテストが通れば順次
結合を行う方式。

16. 結合方式
ビッグバン結合
・開発の進め方がシンプル
・仕様や設計の不整合が開発終盤に発見されるリス
クが高く結合時に多大なコストがかかる。
・日々の結合コストは無い。

17. 結合方式
CI
・開発の進め方が複雑
・日常的に結合しているので、仕様や設計の不整合
発見が早くできる。
・日々の結合コストがかかる。

18. 結合方式
CI<------------>ビッグバン結合
結合方式は二分法ではなく、開発の状況や、コストと
リスクのバランスをとってこのスペクトルのどこか
の方法で結合している。

19. 日々の結合コスト
CI での一番の問題はマスターコードでのビルド失敗
最新のマスターコード取得
->ビルド失敗
->自分で修正するかビルド失敗させた人を見つけて修正依頼
->ビルド成功するまで時間がかかる
->コーディングのリズムが崩れる
->生産性低下

20. 日々の結合コスト
開発人数が多いとコミットミスも多くなる
->マスターコードのビルド失敗が頻繁に発生
->トラブルを避けようとして最新のマスターコード取得する
のを避ける
->ビッグバン結合へ振れてしまい、不整合リスクが増える。
->CI 方式でやっているつもりが、その効果なし

21. CI のコストを下げるにはどうすればよいか
[目的]
確実なビルドを確保する
[やること]
・バージョン管理システム上のマスターソースコ
ードの変更を検出
・自動的にビルドを実施
・ビルド結果をチームで共有する

22. ->ビルドの見える化をインフラでサポートする

23. CI インフラの条件
・シングルソースポイント
・自動化されたビルドスクリプト
・安定したビルド
・コミット後なるべく早くビルド結果をフィードバ
ック

24. CI インフラ構成例
バージョン管理システム: Subversion
(Visual Source Safe にも対応しているらしい)
ビルドツール: Visual Studio 2005
CI サーバー: CruiseControl.NET
CI クライアント: CCTray

25. CI サーバー導入後のコミットの流れ

26. CI サーバー導入後のコミットの流れ
1. ソースを Subversion へコミットする。
2.
CCTray で CI サーバーでのビルドの状態をそれと
なく注意する。(黄=ビルド中、緑=ビルド成功、赤=
ビルド失敗)
3.
ビルド成功なら一安心、失敗なら最優先で修正す
る。

27. CI サーバー導入後の更新の流れ

28. CI サーバー導入後の更新の流れ
1.
CCTray で CI サーバーでのビルドの状態を確認す
る。(黄=ビルド中、緑=ビルド成功、赤=ビルド失敗)
2.
ビルドが成功していれば、安心して更新を実行。失
敗していれば成功するまで待つか、ビルド失敗さ
せた人に状況確認する。

29. CI サーバー結論
・CI にはビルド自動化と見える化をサポートするイ
ンフラが必要
・開発者が多ければ多いほど CI サーバーの必要性が
増す
・CI サーバーがあれば開発者は安心して、更新、コミ
ットを行える。