ソフトウェア構成管理のインフラ

2,000 views
1,937 views

Published on

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,000
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
14
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

ソフトウェア構成管理のインフラ

  1. 1. ソフトウェア構成管理のインフラ Infrastructure for Software Configuration Management (SCM) α版 (C)Copyright 2009 Koki Yamamoto kokiya@gmail.com
  2. 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 ソフトウェア開発プロジェクトをその成果物を通して制御・管理す る方法論である。ソースコードや文書などの成果物の変更履歴を管 理し、製品のバージョンやリビジョンに個々の成果物のどのバージ ョンが対応しているかを識別し、任意のバージョンの製品を再現可 能とする。
  3. 3. ソフトウェア構成管理( SCM )とは ISO 文書管理規定や部署のバージョン管理規定 (リリース時にするべきことが定められている) に従っていれば OK?
  4. 4. ソフトウェア構成管理( SCM )とは 引き続き Wikipedia より SCM の一般的な目的は次の通り : * 構成の識別 - 修正を施すべきコードはどれか? * 構成の制御 - 製品のリリースとその修正を制御する * 状態の記録 - コンポーネントの状態を記録し報告する * レビュー - コンポーネント間の一貫性と完全性を保証する * ビルド管理 - ビルドのためのプロセスとツールを管理する * プロセス管理 - 組織としての開発手法を厳守する * 環境管理 - システムの基盤となっているハードウェアおよびソフ トウェアを管理する * チームワーク - 開発に関するチーム内のやりとりを促進する * バグトラッキング - 全ての障害について対処状 況を追跡可能とし、かつコード修正と対応付ける
  5. 5. ソフトウェア構成管理( SCM )とは SCM とは、 ソフトウェア開発で継続的に実施す ることが 必要な管理全般のこと のように思える。
  6. 6. 開発規模と SCM 力
  7. 7. SCM 力を付ける動機 悲惨から普通へ 非効率から超楽へ ⇒いろんな開発規模に対応できる技術 者に
  8. 8. SCM 力は両輪で
  9. 9. 必須インフラ バージョン管理システム 単一リポジトリ型 分散リポジトリ型 CVS Git Subversion Mercurial Perforce Bazzar Visual Source Safe 課題 ( バグ ) 管理システム Trac Redmine Mantis 不具合連絡システム 継続的インテグレーションサーバー Continuum CruiseControl.NET Hudson
  10. 10. バージョン管理システム ・必須インフラの中でも特にバージョン管理システ ムが重要。 ・一つの組織内では、同じバージョン管理システム を使い、シンプルな方法で管理するのが好ましい。 ・総合力で Subversion が優れている。
  11. 11. なぜ Subversion か ? GPL 進歩と安定性 マージ方式とロック方式の両方に対応 日本語対応 日本語情報 他のインフラ、ツールとの連携 TortoiseSVN
  12. 12. Subversion 利用の肝 ・ブランチ作成 - いつブランチを作成するべきか - 作成したブランチをどう管理するか ・マージ機能 - マージの邪魔をしない - マージを活用する
  13. 13. 結合方式 ・ビッグバン結合 - ウォータフォール開発で行われる。 - 全てのモジュールを作成して単体テスト完了後、 結合を行う方式。 ・継続的インテグレーション (Continuous Integration、以下 CI) - XP 開発で行われる。
  14. 14. - コードを作成してユニットテストが通れば順次 結合を行う方式。
  15. 15. 結合方式 ビッグバン結合 ・開発の進め方がシンプル ・仕様や設計の不整合が開発終盤に発見されるリス クが高く結合時に多大なコストがかかる。 ・日々の結合コストは無い。
  16. 16. 結合方式 CI ・開発の進め方が複雑 ・日常的に結合しているので、仕様や設計の不整合 発見が早くできる。 ・日々の結合コストがかかる。
  17. 17. 結合方式 CI<------------>ビッグバン結合 結合方式は二分法ではなく、開発の状況や、コストと リスクのバランスをとってこのスペクトルのどこか の方法で結合している。
  18. 18. 日々の結合コスト CI での一番の問題はマスターコードでのビルド失敗 最新のマスターコード取得 ->ビルド失敗 ->自分で修正するかビルド失敗させた人を見つけて修正依頼 ->ビルド成功するまで時間がかかる ->コーディングのリズムが崩れる ->生産性低下
  19. 19. 日々の結合コスト 開発人数が多いとコミットミスも多くなる ->マスターコードのビルド失敗が頻繁に発生 ->トラブルを避けようとして最新のマスターコード取得する のを避ける ->ビッグバン結合へ振れてしまい、不整合リスクが増える。 ->CI 方式でやっているつもりが、その効果なし
  20. 20. CI のコストを下げるにはどうすればよいか [目的] 確実なビルドを確保する [やること] ・バージョン管理システム上のマスターソースコ ードの変更を検出 ・自動的にビルドを実施 ・ビルド結果をチームで共有する
  21. 21. ->ビルドの見える化をインフラでサポートする
  22. 22. CI インフラの条件 ・シングルソースポイント ・自動化されたビルドスクリプト ・安定したビルド ・コミット後なるべく早くビルド結果をフィードバ ック
  23. 23. CI インフラ構成例 バージョン管理システム: Subversion (Visual Source Safe にも対応しているらしい) ビルドツール: Visual Studio 2005 CI サーバー: CruiseControl.NET CI クライアント: CCTray
  24. 24. CI サーバー導入後のコミットの流れ
  25. 25. CI サーバー導入後のコミットの流れ 1. ソースを Subversion へコミットする。 2. CCTray で CI サーバーでのビルドの状態をそれと なく注意する。(黄=ビルド中、緑=ビルド成功、赤= ビルド失敗) 3. ビルド成功なら一安心、失敗なら最優先で修正す る。
  26. 26. CI サーバー導入後の更新の流れ
  27. 27. CI サーバー導入後の更新の流れ 1. CCTray で CI サーバーでのビルドの状態を確認す る。(黄=ビルド中、緑=ビルド成功、赤=ビルド失敗) 2. ビルドが成功していれば、安心して更新を実行。失 敗していれば成功するまで待つか、ビルド失敗さ せた人に状況確認する。
  28. 28. CI サーバー結論 ・CI にはビルド自動化と見える化をサポートするイ ンフラが必要 ・開発者が多ければ多いほど CI サーバーの必要性が 増す ・CI サーバーがあれば開発者は安心して、更新、コミ ットを行える。

×