正式には、 「ソフトウェア構成管理」 (Software Configuration Management: SCM) と言います。 「ラショナル統一プロセス」 (Rational Unified Process: RUP) では、 「構成および変更管理」 (Configuration and Change Management: CCM) などとも呼ばれます。 では「構成」とはなんでしょう？
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t
SW開発には、たくさんの落とし穴や地雷がある。 地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。 アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。 仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。 顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。 以下メモ書き。 【1】顧客要求を安易に受けてしまう人の良いSE－ ＠IT自分戦略研究所 スコープのずれがコスト増にすぐにつながる。 アジャイル開発の肝はスコープ管理だ。 スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。 スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがあ
ソースコードなどのプロジェクトの成果物を管理する手段として、バージョン管理とかソフトウェア構成管理と言うものがありますが、この２つの違いというのは意外と知られていないものです。 というか、厳密な定義がないに等しく（各書（各所）によって同じ言葉を異なった意味合いで用いていることがあるため）非常に紛らわしかったりします。 ここでは、一般的だと（私の主観で...）思う定義（をさらに簡略化して）にて、整理したいと思います： バージョン管理（Version Control）： ソースコードなどのファイルを「いつ、誰が、なんのために、なにを、どのように」改訂したのかを版（リビジョンやバージョン）として記録し、構成の把握などに役立てること。 ソフトウェア構成管理（Software Configuration Management）： プロジェクトの成果物の構成を正確に記録し、必要に応じて過去の構成であっ
チケット駆動開発とプログラムの品質に関するメモ書き。 【1】チケット駆動開発でソースが綺麗になる 以前のプログラミングは、ソース1行とコメント1行をペアに書くのが普通だった。 実際は、プログラミング設計書の該当箇所をそのままソースにコメント化して、そのコメントに合わせて実装する開発スタイル。 又、障害修正が発生するたびに、修正日と障害管理No、パッチの範囲を示すコメントを入れていた。 たくさんの人のパッチが入るたびに、コメントが増えて、ガラクタがソース中にどんどん増えていく。 最終的に、本番稼働中のソースはたとえコメントであろうとも、コメントを削除するだけのリファクタリングすらできなくなる。 おそらくこの開発スタイルは、汎用機＋Cobol時代に作られたものだろう。 昨今のプログラミングスタイルでは、ソース中に処理説明や修正箇所のコメント化はしない。 仕様に関するコメントは全てチケットへ書く
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
チケット駆動開発の戦略part1として、BTSを構成管理ツールとして使うアイデアをメモ。 #走り書きは後でまとめる。 元ネタは、下記の記事。 チケット駆動開発 ITpro Challenge のライトニングトーク Tracの最大の利点はSubversionとの連携にあり 【1】トレーサビリティ Redmineのチケット管理をずっと続けると、要件からソースコードまでのトレーサビリティをすごく意識する。 実際の運用は下記になっている。 要件・仕様書・テスト仕様書のリンク、説明書き、作業履歴 ←→チケット ←→SVNリビジョン 何度も思うことは、本番リリース後のシステム開発は、リアルタイムに保守されない仕様書よりも、バグ有りで動くプログラムが正しいことだ。 しかも、お客も、バグありの機能を知った上の運用フローを組んでいる。 設計者は、XPのように、動くプログラムを正として、プログラムから機能仕様
■1. はじめに 前回の記事では、オープンソースでのバージョン管理の一例として、Subversion／TortoiseSVN／AnkhSVNの紹介と簡単な利用方法について説明した*1。 *1 前回の記事が執筆～公開されている間に、Subversionの最新バージョン1.5.0が公開されている。これからSubversionを試す方は、下記の最新バージョン（2008年7月23日時点）で試してみるとよいだろう。 ・Subversion 1.5.0 ・TortoiseSVN 1.5.0 ・AnkhSVN 2.0.4757 バージョン管理を利用せずに開発することに懲りた中村君、玉田君は、その後社内でSubversionを導入することを推し進め、社内の開発標準フレームワークの開発・運用を任されるまでに成長していた。 中村君「ほんとSubversionって便利だよな。いま思うとバージョン管理なしでどうや
Subversionを使ったブランチモデル、バージョン管理戦略がだいぶ分かってきたのでまとめてみる。 ＃走り書きなので後でロジカルにまとめる。 元ネタは下記の記事。 複数のアジャイルチームでのバージョン管理 【1】Subversionブランチが作られるタイミングは、2つある。 一つは、本番リリース直後に作るリリースブランチ。 他方は、突然やってきた大きな機能追加に対応するタスクブランチ。 【1-1】リリースブランチは普通で頻繁に作る。 リリースブランチのライフサイクルは、下記の通り。 これがVer1.0, 2.0とバージョンアップするたびに作られる。 Create：本番リリース直後にtrunkから切られたTagから作る。 ↓ Update：緊急のバグ修正を反映する。当然、trunkにもマージする。 ↓ Delete：次のバージョンが本番リリースされた直後に廃止される。 ここで重要なポイント
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
スペインのCodiceは現地時間2008年3月24日に，クロスプラットフォーム対応のソフトウエア構成管理（SCM：Software Configuration Management）製品「Plastic SCM 2.0」を発表した。同時に複数のソフトウエア開発作業を進める場合に，より効率的に質の高いソフトウエアを開発できるようにする。 Plastic SCMは，地理的に離れた場所での並行開発プロジェクトを簡素化するほか，管理者と開発者がプロジェクトの進行を容易に把握できるインタフェースを提供するとしている。バージョン管理，マージ追跡，名称変更機能や，各種視覚化ツールを備える。 新たな開発作業の追加と管理が簡単に行えるほか，数千のブランチを効率的に管理できる。また，オープンソースのデータベースFirebirdを使用しているため，SQL ServerやMySQLデータベースと容易に統合すること
CVSが最も便利に使われた理由は何だろうか。個人的にはWinCVSの果たした役割が大きかったように思える。そしてSubversionが最も利用されている理由も同様に、TortoiseSVNというWindowsベースのエクスプローラに入り込むソフトウェアがあったからこそだと思う。 分散型リポジトリがいかに優れていようとも、便利なクライアントソフトウェアの存在は欠かすことができない。そこでこれだ。 今回紹介するオープンソース・ソフトウェアはTortoiseHg、Mercurialを便利にするエクスプローラ拡張だ。 TortoiseHgはTortoiseSVN同様、エクスプローラのコンテクストメニューを拡張する形で利用するソフトウェアだ。リポジトリの作成やクローンも右クリックからできるようになる。 コミットメッセージなどに日本語は利用できないようだが、設定すれば使えるようになるかも知れない。同様
2007年は各プロジェクトにおいてSubversionを利用してきた。便利ではあったが、サーバを立てる必要があるのが面倒には感じていた。 サーバを立てる必要なく、しかしバージョン管理は行いたい。そんなわがままをすっきり解決してくれるのがこのソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはMercurial、分散型バージョン管理システムだ。 MercurialはMac OSX、Windows、Linuxとそれぞれ提供されているクロスプラットフォームなソフトウェアで、サーバ集約型ではないバージョン管理を行う。 はじめにいずれかのPCでリポジトリを作成し、その後は各クライアントがcloneという形でリポジトリをコピーする。そしてそれぞれコミットをし、完了したらpushする。別なクライアントではそれをアップデートすれば反映される。 ごくシンプルな仕組みではあるが、タグ、ブランチ、Dif
前回の記事ではSVKの基本的な操作方法を説明しました。最終回の今回はSubversionのリポジトリと連携しながら、SVKの使い方を説明します。 リモートのSubversionのリポジトリとして、本連載第2回目で説明した方法でSubversionのリポジトリを作成します。リポジトリを作成しただけではファイルがない状態です。今回はテスト用のデータを用意しました。ファイルをダウンロードしてc:\tmp\ディレクトリに展開してください。展開後、次のコマンドを実行して、Subversionのプロジェクトにインポートします。 テスト用のデータ（sample.zip） C:\> cd c:\tmp\gihyo C:\tmp\gihyo> svn import http://localhost/svn/MyProject/ -m "test project" 認証領域: <http://localhos
OSDir.com Arch の Tom Lord とのインタビュー: バージョン管理システムについて Software / OSDir Original Date: Sep 24, 2004 - 09:20 AM by Steve Mallett バージョン管理システムはどんなプログラマにとっても切実な必要のあるツールだ。 近年 Subversion において、この分野で多大の進歩がなされているが、 世の中にはさらに異なるバージョン管理システムが存在する。しかも、 こうしたシステムの仕事について、これまでの定義を完全に書き換えるものだ。 Tom Lord は、その Arch Revision Control System の作者である。 OSDir は Tom にインタビューして、Arch にまつわる物語を聞いてみた。 そして Arch が他の (たぶん読者が現在使用している) ものと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く