« 2011年12月 | トップページ | 2012年4月 »

2012年2月

初めての人のための構成管理:Subversionの使い方

先進的なユーザの間では構成管理ツールのトレンドはgitに移っていると思うが、Subversionを使っている組織もまだまだ多い。

実際、Subversionによる構成管理のやり方を聞かれることが多いので、一般的と思われる管理方法をまとめてみた。

■Subversionによる構成管理

0.準備

サーバにsubversionをインストールする。

クライアントにTortoiseSVNをインストールする。

1.リポジトリの作成

リポジトリ作成コマンドで、リポジトリを作成する。


2.最初の登録

インポートコマンドで、リポジトリに構成管理対象を登録しても良い。

このコマンドは、リポジトリの作成後、一回だけ実行できる。

この登録は必須ではない。


3.日々の管理

構成管理対象の日々の管理(ファイルの追加、更新、削除)は、リポジトリを直接操作せず、リポジトリからローカルPCにチェックアウトした作業コピーに対して行う。

まず、変更前にリポジトリから作業コピーをチェックアウトする(チェックアウト)。

次に、その作業コピーに変更を加える。

最後に、作業コピーに加えた変更をリポジトリに反映させる(コミット)。


3.1 チェックアウト

リポジトリの作業コピーをローカルPCに作成する。

Subversionの管理対象であるディレクトリには、.svnディレクトリが含まれる。

【注意】
チェックアウトのとき、URLの大文字小文字の区別に注意すること。この区別を間違えると、チェックアウトはできるが、コミットできない場合がある。


3.2 追加

作業コピーにファイルを追加した場合は、追加コマンドで、それを明示的に示す。

ただし、追加したファイルはコミットするまでリポジトリには反映されない。


3.3 コミット

コミットコマンドで、作業コピーに加えた変更をリポジトリに反映させる。

3.4 作業コピーの更新

更新コマンドで、リポジトリの最新状態を作業コピーに反映させる。

4.エクスポート

エクスポートコマンドで、Subversionの管理対象ではないコピーを、ローカルPCに作成する。

Subversionの管理対象でないディレクトリには、.svnディレクトリが含まれない。

エクスポートは、tarファイルを作るときその他、.svnディレクトリを含めたくない場合に使う。


5.ベースライン管理

日々の管理はtrunkで行い、リリースが近づいたらbranchesに移り、ベースラインはtagsに登録する運用が一般的だ。

ベースラインの登録では、作業コピーでなく、リポジトリを直接操作する。

ベースラインを登録する時は、branchesにあるディレクトリを、TortoiseSVNのコピーコマンドでtagsにコピーする。

そのコピーのタグ名は、年月日で始めると時系列で管理しやすい。

例)
20120201_要求分析
20120301_設計

6.構成監査

ベースラインを登録する前に、そのベースラインに含まれているものが正しいものであることを確認することを構成監査と言う。

ベースラインは、登録後、いろいろな場面で基準として扱われるので、その正しさを保証する構成監査は重要である。

確認する項目としては、

・構成物がレビューやテストで合格したものであること(機能的に正しいか)
・構成物が定義どおりであること(物理的に正しいか)
・構成監査の記録と構成物が、完全で一貫性があり正しいこと(管理方法的に正しいか)

がある。

また、ベースラインは記録であるので、tagsに登録後はその内容を書き換えてはいけない


以上

| | コメント (0) | トラックバック (0)

レビューで見つけた誤りの分析について

レビューを十分に行ったはずでも、

誤りが流出してしまうことがある。

そのような場合、流出した誤りを分析すると、

流出しやすい誤りの特徴や、

誤りを見逃してしまうレビューアーの習慣が明らかになる。

■分析で終わらず、情報を活用する

それらの情報を、

レビューガイドラインやチェックリストに応用することが、

個人やチームのレビュー能力の向上につながる。

■テストでも同じ

上のことは、レビューだけでなく、テストにも当てはまる。

テストで見つけられなかった誤りを分析することで、

さらに良いテストを設計できるようになる。


| | コメント (0) | トラックバック (0)

検証(レビュー、テスト)の費用対効果について

ソフトウェアの開発状況を調べていると、

前フェーズからの誤り流出が、費用対効果を考慮した計画の結果と考えられる場合がある。

つまり、コストのかかる検証を減らすかわりに、誤り流出リスクを管理して、計画的に誤りを流出させているのだ。

世間には、

「フロントローディングが良くて、誤り流出は悪い」というスローガンばかり唱える管理職もいるけれど、

この開発は、開発管理を適切に行っている良い事例だと言える。

■ソフトウェア品質保証はある意味ギャンブル

こんなことをいうと、上のような管理職には怒られるだろうが、

実際のところ、

ソフトウェアの品質保証は、ギャンブル的な一面がある。

誤りが流出するかもしれないリスクをとって、

レビューやテストのコストを削減することもできる。

そうやって、もし誤りが流出しなければ、

開発チームの勝ちだ。

■効果(勝ち負け)の検証

開発の終了後に、

検証の費用対効果を評価して、自分たちの方法の有効性を評価してみるのが良いだろう。

| | コメント (0) | トラックバック (0)

« 2011年12月 | トップページ | 2012年4月 »