nDiki : バージョン管理

バージョン管理 - version management / version control

バージョン管理チェックリスト

管理対象

管理対象は何か?

  • ソフトウェアは管理されているか?
  • □ ドキュメントは管理されているか?
  • □その他のリソースは管理されているか?

ソース

ソフトウェア、ドキュメント、その他のリソースについて以下はそれぞれどうか?

ビルド

ソフトウェア、ドキュメント、その他のリソースについて以下はそれぞれどうか?

  • ビルド番号(バージョン番号、リリース番号)の規約はどのようなものか?
  • ビルドに対応するソースにタグを打っているか?
  • □ タグ名の規約はどのようなものか?
  • ビルドはどこに保存されているか? バージョン管理システム上か? それともファイルシステム上か?
  • ビルド手順は?
  • ビルドは自動化されているか? (ソフトウェア、ドキュメント、パッケージ)
  • □ 複数の人がビルドできるようになっているか (一人の人だけではコミット忘れが起きやすい)。
  • ビルド番号がダイアログ、 --version オプション等で表示できるようになっているか? 文書に含まれているか?
  • □ 組織内を含め、他人と共有するビルドは正しくビルド番号がふられるようになっているか? ビルド番号のインクリメントは手順に含まれているか?
  • □ release candidate build / release build をビルドするのは誰か?
  • ChangeLogNEWS はきちんとメンテナンスされているか?

配布物

バージョン管理システム

  • バージョン管理システムには何を使うのか?
  • □ 関係者全員が使えるようになっているか?
  • □ コミットログの書き方は? (ChangeLog 式? 日本語は OK/NG ?)
  • □ コミットの単位のルールは? (こまめOK? それともある程度の変更のタイミングで?)

バックアップ

ガイドライン

  • □ 上記で確認した点は明文化されているか?
  • □ 誰かの頭の中にしかないルールはないか?
  • □ そのガイドラインは関係者が全員閲覧可能か?

スポンサード リンク

2004年4月2日 (金)

[ WiKicker ] 久しぶりにメンテナンス

CVS のリポジトリにチェックインしていなかったファイルが沢山あった。 コードの変更内容を確認しつつチェックイン。

WiKickerRCSバージョン管理をしているのだが、NaneyOrgWiki だと一部のページでかなりリビジョンが上がってきている。 それらはだいたいコメントフォームによる追記によるもの。

ということで以前から検討していた「追記だけの場合はチェックインしなようにする」オプションを追加する予定。

DiKicker の方も未実装のコードを実装しようとしたが、記憶が薄れてしまっているので今日はやめておく。

スポンサード リンク
[ 4月2日全て ]

2005年8月24日 (水)

Module::Buildソースパッケージング

ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

  • アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
  • 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
  • アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
  • UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

Module::Build

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::BuildPerl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

  • Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
  • META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

[ 8月24日全て ]

2007年7月31日 (火)

Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない

GNU AutotoolsExtUtils::MakeMaker (とその仲間たち)で make dist するのがあたり前になっている自分には、気持ち悪い。

ビルドの自動化とソースパッケージ作成の自動化・バージョン管理のセットアップは、最初の仕事だと思うのだが。

[ 7月31日全て ]

2007年9月25日 (火)

Visual C# 2005 Express Edition ではどれを Subversion リポジトリに突っ込めば良いか?

Visual C# 2005 Express Edition で Windows アプリケーションテンプレートによる構成は下記 (名前を Example で作成した場合)。

ファイル名対象
Example.slnoソリューションファイル (テキストファイル)
Example.csprojoプロジェクトファイル (XML ファイル)
Example.suoソリューションユーザオプションファイル (バイナリファイル)
Program.csoC# ソースファイル
Form1.csoC# ソースファイル
Form1.Designer.csoC# ソースファイル
Properties/AssemblyInfo.csoC# ソースファイル
Properties/Resources.Designer.csoC# ソースファイル
Properties/Settings.Designer.csoC# ソースファイル
Properties/Resources.resxoリソースファイル (XML ファイル)
Properties/Settings.settingso設定ファイル (XML ファイル)
bin/*
obj/*

バージョン管理する必要があるのは「対象」のファイルで良いのかな? Form1 などはすぐ名前変更になるけれど。

参考

追記

2007年12月4日
  • Properties/Resources.Designer.cs を追加。
[ 9月25日全て ]

2010年10月20日 (水)

今日のさえずり: ロック方式のバージョン管理機能やっぱりお肌にあわない

2010年10月19日

2010年10月20日

[ 10月20日全て ]

2013年1月4日 (金)

CVS リポジトリGit リポジトリに cvs2git で移す

しばらく放置していたこの nDiki のコード(DiKicker)に手を入れようと思うのだけれど、CVS で管理し続けるのもなぁと思い、これを機会に Git に移行させることにした。移行は cvs2git で。ローカルで自分だけでバージョン管理していたものだし、ブランチも切ってなくてタグを売ってあるだけなので一番ちょろいケースか。

Debian GNU/Linux sid 上に cvs2svn Debian パッケージインストール。以下の手順でコンバートした。

オプションファイルを作る

Git リポジトリ上できちんとユーザ名とメールアドレスが入るようにしたいため、オプションファイルを使うようにする。

 zcat /usr/share/doc/cvs2svn/examples/cvs2git-example.options.gz > cvs2git.options

で雛型をコピーして以下を書き換え。

  • ctx.username = 'cvs2svn' のところを naney に。
  • author_transforms に 'naney' : ('WATANABE Yoshimasa', 'naney@naney.org'), を追加
  • run_options.set_project で CVS リポジトリのパスを r'/home/naney/path/to/cvsroot', のように指定。

git fast-import 用のファイルを生成

以下のコマンドで。

 cvs2git --options=cvs2git.options

Git リポジトリを作成しインポート

 mkdir <プロジェクト名>
 cd <プロジェクト名>
 git init
 cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git fast-import

で QGit や git log などで、どのようにインポートされたかを確認。trunk のラインから、タグ毎に分岐したコミットができてそこに CVSROOT/ 以下が差分として入っているという形になっているのが特徴的。CVSROOT/ は特にいらないので、数が多くないし手でタグ打ち直すかなあという感じ。

git fast-import したままだと作業ツリーが空なので git checkout して master を checkout するなりすれば、後は普通に Git 上でバージョン管理をしていくことができる。

あっさり移行できたので一安心。

[ 1月4日全て ]

2015年5月13日 (水)

レクサー・リサーチ開発同窓会

naney:17034996273

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグス ダイニング 神楽)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 WikiNaney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

[ 5月13日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.152287s / load averages: 1.05, 1.03, 1.19
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker