Subversionを見直せ
SW構成管理の概念の中心は、バージョン管理。
バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。
デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。
おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。
もう一度、Subversionの機能を見直してみた。
【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー|gihyo.jp … 技術評論社
最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。
メインラインモデルと呼ばれる。
メインラインモデルの手法を使って、本番運用中の保守branchと新規開発中のtrunkの2本のラインを、緊急のバグ修正は保守branchへ、仕様変更や機能追加はtrunkへと使い分ける。
これによって、品質保持と機能追加という矛盾したSW開発が可能になる。
SVNの基本機能をムービーで説明してくれているので、初心者や開発チームに新規加入した開発者へ説明する時に役立つ。
僕は上記の記事で下記の機能をもう一度復習した。
1-1.trunkからリリースする時は、必ずtagでスナップショットを取り、バージョン付けした直後にbranchを作る。
そうすれば、tagとbranchには、過去のリビジョン履歴も受け継がれる。
1-2.ファイルやディレクトリの移動や複製は、SVNコピー機能を使う。
SVNコピー機能によって、リビジョン履歴も受け継がれるので、その後の運用保守で役立つ。
1-3.マージ機能を使えば、機械的にロジックの一部を最新リビジョンへ追加できる。
マージトラッキング機能を使えば、マージのUndo作業も可能。
【2】Enterprise Architect と Subversion の連携 - かおるんダイアリー
モデリングツールEnterprise Architect(EA)とSubversionを連携する機能について説明されている。
EAはおそらくUMLモデリングツールの中では、最も使いやすく機能も豊富。
EAには元々、マスターファイルへローカルファイルのモデル(クラス図、シーケンス図等)をマージする機能がある。
上記の記事で、UMLで設計したモデルもSVNでバージョン管理できる。
ExcelやWordもSVNで差分表示できるから、同様にUMLモデルも含めて、仕様書も積極的にSVNでバージョン管理すべき。
仕様書もソースと同じくバージョン管理すべき対象なのだ。
【3】エンタープライズ環境におけるSubversionの複製アーキテクチャ - japan.internet.com デベロッパー
Subversion 1.5.0 での新機能 (WebDAV Write Through Proxy)
SVNリポジトリを安全に保管するために、バックアップするのは重要。
SVNなら、リポジトリを全てエクスポートするよりも、svnsyncでミラーリング機能を使うのが普通だろう。
つまり、開発者はマスターリポジトリへコミットすると、更にpost-hookされて別サーバーにあるSVNリポジトリへリアルタイムにコミットするように設定する。
これによって、タイムラグが生じることなく、マスターリポジトリとミラーリポジトリがリアルタイムに同期される。
だが、このミラーリング機能を更に進化させたライトスループロキシ(WebDAV Write Through Proxy)という機能がある。
最近、優秀な一部の開発チームは、Gitなどの分散バージョン管理を導入している。
分散バージョン管理の利点は、開発中のまだ検証されていないコードラインをローカルでバージョン管理できて、ビルドされていつでもリリース可能なメインラインへいつでもコミットできる点だろう。
特に最近のオープンソース開発のように、trunkにコミットできる開発者は一部のコミッタだけで、別のハッカーがソースにパッチを当てて動かしたい時に、分散バージョン管理の環境があると嬉しいだろう。
上記の記事は、ライトスループロキシというSVNの機能を使うと、複数のSVNリポジトリとsvnsyncを組み合わせることによって、更新可能なマスターリポジトリと読み取りOnlyのミラーリポジトリを作って、分散バージョン管理らしき環境を作ることができると説明している。
この方式を使って単純だが強力で高可用な性質を持つバージョン管理システムを構築することができる。
我々SW技術者は、バージョン管理というSW開発の最も根幹を成すプロセスを効率化し改善できないか、もう一度再考すべきだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
コメント