こんにちは、イマジオムの高木です。 細川さん、7of9 さん、
大変詳しいお返事をありがとうございます。 長文になりがちなので
お返事はお時間のある時でお願いします。
旧MLで投稿してすみませんでした。 次回のスレッドからは
新ML(Google Groups)を使いますが、今回はこのまま走らせて
ください。
#このスレッドが秋まで続いたりして……
細川さん:
> 弊社では Git (を使ったホスティングサイト GitHub / BitBucket) を
> 使って管理しています。
>
> たとえば、今回のような場合は、ライブラリを管理するリポジトリを
> 作ります。
>
> そして、あるアプリケーション Foo でそのライブラリを使用する
> 場合は、ライブラリの Master ブランチから Fork してローカルに
> Foo 用のブランチを作成します。
>
> こうすると、Fork したブランチ上のライブラリは他からの影響を
> 受けなくなるので、その時点での Foo を永続的にビルド可能になります。
> ただライブラリの変更は多大な影響があるので、テストコード(Delphi で
> あれば DUnitX による Unit Test)も一緒に開発しておくと良いと思います。
ありがとうございます。 [delphi-users:5245] の例(下記)で
書きますと──
# Foo …… a1,b1,c1
#
# Bar …… a2,b1,c1
#
# Hoge …… a2,b2,c1
1.リポジトリを設け、新旧のモジュールすべて(a1,a2,
b1,b2,c1)を保存する。
#どのプロジェクトでどのバージョンのモジュールを
使っているか、プロジェクトごとにモジュールが改変
されていないかは、GitHub の機能を使っていつでも
確認することができる。
#新旧のユニット間の変更内容は、ソースコードの差分を
見ることによっていつでも確認することができる。
2.新たにプロジェクト(Foo,Bar,Hoge)を起こす時には、
リポジトリから最新のモジュールをコピーして使う。
3.場合によってはプロジェクト単位でモジュールに手を
加えることもある。 その場合、当該のプロジェクトや
テスト専用のプロジェクトを使って充分なテストを行い、
バグがないことを確認してから、最新バージョンとして
リポジトリに追加する。
4.プロジェクトごとに使用するモジュールのバージョンに
ばらつきが生じるが、必要に迫られなければ最新版に
差し替えることはしない(7of9 さんの方法と同じ)
──ということですね。
この方法について、7of9 さんにお尋ねした内容と重なりますが、
4で「必要に迫られ、最新版に差し替える」場合には、やはり
「モジュールのバージョンアップによって既存のプロジェクト
コードが受ける影響」を入念にチェックする必要があるかと
思います。 この作業は大変ではありませんか?
7of9 さん:
>> 7of9 さんの方法では、アプリケーションをバージョンアップ
>> する際、必要に迫られなければモジュールを最新版に差し替えないと
>> いうことかと理解しました。 裏を返すと、アプリケーションを
>> バージョンアップするたび、個々のモジュールごとに「差し替える
>> 必要があるかどうか」を調べておられるものと思いましたが、
>> この作業は大変ではありませんか?
>
> 大変かもしれません。対象数(ソースの数 * 変更回数)が多くなると
> 確認する部分が多くなります。
やっぱり大変なんですね。
> ソース上部のバージョン履歴に(a) fix bug, (b) 機能追加や変更、の
> 区別はつけています。アップデートの対象検討の材料にします。
インタフェース仕様が変更されているかどうかを知るためですね。
> 1個のソースにアップデートが5回あると、ソース上部のバージョン
> 履歴の確認に2分はかかるでしょうね。モジュールの数がN個になると
> そのN倍(例: 15個だと30分)の時間を確認だけのためにかけます。
> 概要だけで分かりにくい場合は、VCSのコミットなどを探し、その
> 5から10倍の時間かかりますが、その状況は多くはありませんでした。
インタフェース仕様の変更は、バグフィックスほど多くないという
ことですね。
> 以下は確認手順の概要です。
>
> 1. 対象のソフトの出荷時期から対処内容を検討
> (fix bugモジュールのみ適用 or fix bug + 機能追加モジュールも適用)
> 2. リリースまでのテスト期間を確認し、モジュール更新の順番+
> テスト期間を検討
> 3. 逐次適用して、エンバグしてないことを確認
よくわかります。
>> ヒヤヒヤしながらこの作業を行っています。 この「ヒヤヒヤ」を
>> 避けることのできる方法が見つかるといいのですが……
>
> 小さな機能であれば、実装しているテストを走らせながらエンバグ
> しないことを確認します。大きな機能になると、実際にテスト期間を
> きちんととって、エンバグしないことを確認します。
>
> 一方で、共有モジュールであるため、リリースが決まる以前に他の
> ソフトでテストができています。その点から、リリース直前に適用して
> エンバグする可能性は低いのですが、慎重に適用したほうがいい
> でしょうね。
>
> 適用については、メンテを長く続けるソフトの場合、いずれかの
> 時点で適用していくことになりそうです。適用インターバルが長く
> なると、適用時にトラブルも増えるでしょうね。落ち着いた時期に
> 対処できれば、失敗も減らせると期待しています。
これも同感です。
お二方の意見を伺い──
‐モジュールのバージョンアップについて、(イ)バグフィックス
なのか、(ロ)インタフェースの仕様変更なのかを管理する
手段があるといい。
‐モジュールインタフェースの仕様変更に対し、プロジェクトの
どの部分が影響を受けるかを検索する手段があるといい。
──ことがわかってまいりました。 いつか手の空いた時、ツール化にも
チャレンジしてみようかと思います。 ここまでありがとうございました。
――――――――――――――――――――――――――――――――――――
〒316-0024 茨城県 日立市 水木町 1-11-10 高木太郎
電話:0294-52-6787
「WiMAX(ワイマックス)」ならおトクなGMOとくとくBB。
今なら高額ポイントがもらえます♪
まずはかんたん登録♪ -ポイントタウン-
https://www.pointtown.com/ptu/rd.cgi?cid=9533
----------------------------------------------------------------------