ソフトウェア開発の課題5 パターンによるソフトウェア構成管理読了

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

作者: ステファン・P・バーチャック,ブレッド・アップルトン,宗雅彦
出版社/メーカー: 翔泳社
発売日: 2006/10/24
メディア: 単行本（ソフトカバー）
購入: 4人クリック: 91回
この商品を含むブログ (35件) を見る

パート1 バックグラウンド

ソフトウェア構成管理とパターンの概念とその必要性の説明。そうですねとしか返せない正論が延々と続いていて全然面白くなかったので、ほとんど流し読み。

パート2 パターン

パート2に入ると、GoF本みたいな普通のパターンカタログ。今まで無意識に行っていたことを明確に定義づけてくれたので、今後の指針の助けにすることができる。
でも、こっちのほうがよりポリシーとしての位置づけが強い感じ。ポリシーのカタログみたいな感じかな。
SCMって本当に、管理者はポリシーありきでインフラを整備して、利用者はインフラありきでポリシーを享受するかたちということだからなのか。EclipseとかのIDEを使うことで、利用者に意識させることなく浸透させるものでもあるし。

Mainline

開発の背骨になるコードラインのこと。ポリシーとしてもMainline。

Active Development Line

もっとも活発に変更されるために用意されるコードラインのこと。Mainlineだったり、Branchだったりすることもある。これもポリシーの話。

Private Workspace

いくらMainlineとかを持っても、個々の開発者が直でMainlineを変更したら意味ないよね、という話。SVNならワーキングコピーと呼ぶもののこと。

Repository

コードを共有する場所として定義された場所のこと。あまりに当たり前の概念すぎて、はじめに読んだときは理解できなかった。

Private System Build

開発者のPrivate Workspaceでビルドを行いましょうという話。これも当たり前の話かな。

Integration Build

よくいう、継続的統合のこと。このあたりから実行できてない…。

Third Party Codeline

サードパーティのコードを管理するコードラインのこと。確かにそこまでやったほうが安全だけど、まだ必要性にかられたことがない。覚えておくだけ覚えておこう。

Task Level Commit

コミットの粒度についてのポリシー。タスク単位でコミットするべしという話。このレベルだと開発者の意識に絡んでくるからできてない。コミット時に通知するようにしておけば、コミット粒度の意識が生まれるという話を聞いたことがあるけど、そういうことなのか。あ、あとはコミットコメントを入れるという、ルールを定義すればいいのか。逆に、コミットコメントを書けないレベルならその粒度ではコミットすべきてはないという話で。

Codeline Policy

ポリシーを明確にして、きちんと開発者に浸透させましょうというポリシー。これが一番重要。

Smoke Test

コミット後にも動くか、ざっくり確認しましょうという話。Active Development Lineで実行するには、ちょっとコストがかかりすぎる印象。メンテナンス・コードラインで、っていう話なのかな。

Unit Test

できてない。かっこわるい。やりたいよなー。素振りから始めようか。

Regression Test

日本のIT業界だとUnit Testはやらなくても、これは必ずやるんだよな。リリース後で、顧客の目に見えるところでのことだから？目に見えない、根っこの段階で対処したい。

Private Version

開発者ごとでのコードラインのこと。本当に開発者ベースで用意するのはちょっと現実的じゃないから、実現するとしたら開発者のローカル環境にリポジトリを用意するという感じかな。

Release Line

リリース後のメンテナンス用branchのこと。リリース直前、もしくは直後に用意する。

Release-Prep Code Line

リリース準備用のコードラインのこと。リリース準備が必要な場合にリリース前に用意する。また、リリース後はこのコードラインをRelease Lineとすることができる。
ただし、Mainlineとの同期はつねに必要なため、分離時期が早いRelease-Prep Code LineはマージのコストがRelease Lineよりも大きい。
また、適切であれば、リリース準備結果をMainlineに適宜フィードバックする。