構成管理

初めての人のための構成管理: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)

危険はことは避けるべき

Subversionのログを調べると、commitが衝突していて、その後、updateしてcommitしているというケースがある。
開発チームに状況を聞いてみると、複数のプログラマが同時に同じファイルを修正しているが、commitするときには調整してからcommitしているから、構成管理ミスはないという。
ログの内容から判断して、その説明もかなり怪しいが、仮に彼らの説明を信じるとしても、やはり人的誤りが起こり得るような運用は避けたほうが良いだろう。
今の場合なら、「複数のプログラマが同時に同じファイルを修正する」ような運用は構成管理ミスを招きやすいので、避けるべきだ。

  • 原則として、一つのファイルは一人のプログラマだけが修正することとする
  • 一つのファイルを複数のプログラマが修正する場合でも、commitできるのは一人とする

この規則を守るだけでも、構成管理ミスは減らせるはずだ。
とくに共通のヘッダファイルや設定ファイルには、この規則を徹底する方が良い。

★WOZ★

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

構成管理のリスク

Subversionでバージョン管理していると、updateコマンドを使うことが多い。
しかし、このupdateコマンドはリポジトリの内容で、ローカルのファイルを上書きしてしまうため、注意が必要だ。
例えば、あるファイルを修正している途中で壊してしまった場合に、updateコマンドでリポジトリから修正前のファイルをとってくるということがよくある。
しかし、ここでうっかり、そのファイルより上位のディレクトリをupdateしてしまうと、目的のファイル以外のファイルもupdateされてしまう。
つまり、もし他のファイルの修正もしている場合、そのupdateにより、意図しないファイルまで、以前の状態に戻ってしまうわけだ。

このようにupdateコマンドをうっかり使うと思わぬ失敗につながることがあるので、使うときには細心の注意を払う必要がある。

★WOZ★

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

構成管理のリスクを小さくする

Subversionのログを見ていると、問題が起こりそうな開発チームがすぐわかる。

例えば、ある人があるファイルをチェックアウトして、その人がそのファイルをコミットする前に、別の人がそのファイルをチェックアウトしていれば、そのファイルには上書きのリスクが発生しているという具合だ。

これなどは、あるファイルを触れるのは特定の人だけ、という規則を作ってしまえば容易に回避できるリスクなのだが、実際の開発ではそうできないと考えている開発チームが多い。

ただでさえソフトウェア開発にはたくさんのリスクがあるのだから、簡単に回避できる方法があれば、これまでと違った方法であったとしても、真っ先に適用したいものだ。

★WOZ★

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

ISO9001の文書管理

今時のソフトウェア開発では、ソフトウェアの設計書は、紙ではなく電子ファイルで管理している組織が多いだろう。

しかし、ISO9001の文書管理に関する要求からは、電子ファイルでの文書保管には注意が必要だ。

電子ファイルの管理でよくあるのが、ファイル名に年月日をつけてバージョンを表し、古いファイルも新しいファイルも、全部まとめて一つのディレクトリに入れているパターンだ。

この管理方法だと、最新版だと思って古いものを使ってしまったり、最新版を修正しようとして古い版を修正してしまうというミスを犯すリスクが大きくなる。

この問題の解決方法として、例えばoldという名前のサブディレクトリをつくり、古いものはそのディレクトリに入れてしまい、元のディレクトリには最新版だけを残す、という方法がある。

確かに、この方法だと、古いものを使ったり修正したりするリスクが小さくなるので一定の効果はあるだろう。

しかし、できることならSubversionなどのバージョン管理システムを使って、設計書その他文書を管理するのが望ましい。

★WOZ★

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

構成管理の現状

最近、構成管理について何人かの人と話をする機会があったのだが、彼らの話に共通しているのは、構成管理はまだまだ開発現場に普及していないということだ。
Subversionなどのバージョン管理システムを使っていないどころか、開発チーム用の共有ディレクトリに一週間に一度でも最新の設計文書やソースコードのファイルを集めていれば良いほうで、個人用PCのローカルディスクにしか開発中のファイルがない、というやり方で開発を行っている組織も多いという。

そのような組織では構成管理ミスが原因の不具合が頻発し、金銭的な損失も大きいのだが、構成管理プロセスや手法を改善しようという動きは、何故か起こらないらしい。

正確には、個人的に改善しようという人はいるのだが、組織としては改善が進まないそうだ。

改善が進まない理由を調べてみると、その組織では、いままでのやり方で問題がないので、新しいやり方に変える必要がない、と考えている人が多いことに気づく。

なるほど、要は自分たちの組織で起こっていることを認識していないのだ。

不具合が起こっていることを組織として情報共有していないのかもしれないし、あるいは、何か問題があることはわかっていても、それが構成管理ミスに関係があることを認識できないのかもしれない。

こんな状態では、開発プロセス改善を進めようとしても、なかなか上手く進まないのも頷ける。開発プロセス改善のような高度なことをする前に、基本的なエンジニアリング技術の不足をなんとかしなければならないのだろう。

★WOZ★

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

構成管理の開始時期

ソフトウェア開発で、構成管理はいつから始めるのが良いのだろうか?

Subversionでソースコードのバージョン管理をしているチームなら、実装フェーズから構成管理を始めているかもしれない。
自分たちは設計だけして、実装は外注するという開発チームでは、外注先からソースコードを受け取った時から、構成管理を始めるかもしれない。
また、まれに、製品が完成したときに、その時のソースコード一式をまとめて、そこから構成管理をする開発チームを見かけることもある。

しかし、上の開発チームのいずれも、構成管理の開始時期としては遅い。
開発を始めた時から構成管理も開始するのが適切だ。
というのも、構成管理の対象になるのは、ソースコードだけではなく、

  • ソフトウェア開発計画書
  • ソフトウェア開発チームへの入力であるシステム設計書
  • 要求仕様書、基本設計書、詳細設計書その他の設計書
  • テスト仕様書と成績書
  • 各種レビュー議事録
  • テストデータ
  • 開発に使ったツールと設定ファイル
  • テストに使ったツールと設定ファイル
  • 製品の設定ファイル

など、開発に関わる一切のものだからだ。
こう書くと大変なようだが、これらはいずれにせよ何らかの方法で管理しなければならないものなので、せっかくならソースコードと同じように、Subversionなどのツールを使って、バージョン管理とベースライン管理をしてしまえば、管理自体も簡単で確実だ。

開発の途中からしか構成管理をしていないという開発チームや、ソースコードしか構成管理していないという開発チームには、開発に関わる一切の情報を開発の最初から構成管理するという方法をぜひ試してみてほしい。

★WOZ★

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

Subversionで文書管理を確実にしよう

ファイル名やディレクトリ名を日付入りにして、バージョン管理をしている人は多いだろう。例えば、

file20100123.doc

とか、

dir20100123

という具合だ。

同じ日にバージョンが上がる場合は、

file20100123-1

とか、

file20100123a

といった名前になる。

こういう管理方法は、一見わかりやすいように思えるので、多くの人や組織がこの方法を使っている。

しかし、この方法では、ファイルやディレクトリが増えてくるとあっという間に混乱してしまう。最新だと思って人に渡したソースコードが実は古いものだったり、正しいと思ってコーディングのインプットにした設計書が、実はバグ修正前の正しくないものだったりすることが起こりがちなのだ。

しかも、こんな方法でファイルを管理していると、ISO9001の監査で不適合になる可能性が高い。

つまり、

  • 文書の変更の識別及び現在の改訂版の識別を確実にする
  • 該当する文書の適切な版が、必要なときに、必要なところで使用可能な状態にあることを確実にする
  • 廃止文書が誤って使用されないようにする。また、これらを何らかの目的で保持する場合には、適切な識別をする

という要求を満たせない可能性が高いのだ。

こんな間違いや不適合の可能性に心当たりがあるなら、バージョン管理システムを使うことを検討してみてはいかがだろうか。

2010年現在、広く使われているバージョン管理システムはSubversionだ。

もちろん、これさえ使えば完璧というものではないが、バージョン管理にまつわる失敗の多くをなくすことができるのは間違いない。

★WOZ★

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