SubVersionを使ったバージョン管理の実際
前回のチケット駆動開発
「4.割当てられたチケットを担当者が着手する状態:accepted」
から、ソースを改修〜コミットするまでを少し細かく見ていきます。
例えば、下図のようなソース管理フローで開発を行っているとします。

1.問題発生内容を台帳に記入
担当:マネジャー
2.関連ソースを調査して、本番ライブラリより貸出ライブラリにソースコピー
本番ライブラリのソースはリネーム(バックアップ用)しておく
担当:ソース管理者
3.開発するタイミングでソースをコピー
担当:実装者
4.テスト完了後、ソースを貸出しライブラリにコピー
担当:実装者
5.貸出ライブラリより、本番ライブラリに移動
担当:ソース管理者
6.台帳に完了を記入
担当:マネジャー
運用ルールとして、
1.本番ライブラリにソースが無ければ、貸出中
2.貸出中のソースが改修中かどうかは台帳を見て判断する
3.ソースのバックアップは本番ライブラリで管理する
問題点として、
1.ソース管理者が必要。
2.改修中かどうかが台帳を見ないと把握できない。
3.ソースのバックアップが本番ライブラリに存在する。
4.管理が複雑なので事故が起きやすい。
3.は本番ライブラリー以外を使用することも可能ですが、
バックアップを管理する上でもソース管理者はやはり必要です。
今回はSubVersionを利用して、ソース管理者を必要としない開発を目指します。
前回の下図、担当者が着手するところから始まります。

改修対象ソースをロックします。対象のソースを選択して、

ロックを選択します。

コメントがあれば、入力します。
改修するソースをロックする概念はAS/400にはありません。
ロックすることにより、ソース改修の競合を防ぎます。

アイコンが変わりました。

ソースを改修して・・・

保存します。アイコンが変わりました。
他ソース2本もロック取得済です。

ここで、別の実装者がロックを取得するとどうなるでしょうか?

大島さんは、前田さんのヘルプのためソースを改修しようと思いロックをかけました。

当然、ロックがかかっていたため失敗します。

誰がロックをかけている確認するには、「SVNリポジトリーエクスプローラー」からプロパティを選択します。

ロック保持者が前田さんになっているのが分かります。

なお、先ほどのロック取得のところで、「ロックの強制取得」がありました。
チェックをすると、ロックを取得することができます。
ルール違反ですが、担当者がお休みなど緊急時に使用できます。
前田さんは、対象のプログラム3本を全て修正しました。

改修が終わったので、ソースをコミットします。

コミットのコメントにチケットIDを入力します。

先にロックをしているので、コミットが失敗することは無いと思います。
(ロックをしていないと競合が起こる可能性があります)

リビジョン28でコミットされました。 リビジョン番号を覚えておきます。

tracのステータスを「解決:resolved」に変更します。
この時、先ほど控えておいたリビジョン番号を入力します。

チケット番号から検索をするとチケットに紐付いているリビジョン番号が分かるので
リビジョン番号をクリックすると

チケットに対応して修正したソース(ここでは3本)と、修正した内容が一目でわかります。

最後に、修正した内容をAS/400に反映します。

ソース反映中。

ちゃんと、レコードレベルで改修した日付が変わっています。

このように、ソースを改修する場合はSubVerionをメインとして考えれば
同じソースを改修しあうこと(競合)がなくなるのでソース管理者が必要なくなります。
運用ルールはただ一つ「ソースを改修する前はロックを取得しましょう」だけです。
また、ソース管理台帳もうまくtracを利用すれば、廃止出来るかも知れません。
以上で終了です。
(記事を書いた日:2014/05/19)
「4.割当てられたチケットを担当者が着手する状態:accepted」
から、ソースを改修〜コミットするまでを少し細かく見ていきます。
例えば、下図のようなソース管理フローで開発を行っているとします。
バックアップを管理する上でもソース管理者はやはり必要です。
今回はSubVersionを利用して、ソース管理者を必要としない開発を目指します。
前回の下図、担当者が着手するところから始まります。
改修対象ソースをロックします。対象のソースを選択して、
ロックを選択します。
コメントがあれば、入力します。
改修するソースをロックする概念はAS/400にはありません。
ロックすることにより、ソース改修の競合を防ぎます。
アイコンが変わりました。
ソースを改修して・・・
保存します。アイコンが変わりました。
他ソース2本もロック取得済です。
ここで、別の実装者がロックを取得するとどうなるでしょうか?
大島さんは、前田さんのヘルプのためソースを改修しようと思いロックをかけました。
当然、ロックがかかっていたため失敗します。
誰がロックをかけている確認するには、「SVNリポジトリーエクスプローラー」からプロパティを選択します。
ロック保持者が前田さんになっているのが分かります。
なお、先ほどのロック取得のところで、「ロックの強制取得」がありました。
チェックをすると、ロックを取得することができます。
ルール違反ですが、担当者がお休みなど緊急時に使用できます。
前田さんは、対象のプログラム3本を全て修正しました。
改修が終わったので、ソースをコミットします。
コミットのコメントにチケットIDを入力します。
先にロックをしているので、コミットが失敗することは無いと思います。
(ロックをしていないと競合が起こる可能性があります)
リビジョン28でコミットされました。 リビジョン番号を覚えておきます。
tracのステータスを「解決:resolved」に変更します。
この時、先ほど控えておいたリビジョン番号を入力します。
チケット番号から検索をするとチケットに紐付いているリビジョン番号が分かるので
リビジョン番号をクリックすると
チケットに対応して修正したソース(ここでは3本)と、修正した内容が一目でわかります。
最後に、修正した内容をAS/400に反映します。
ソース反映中。
ちゃんと、レコードレベルで改修した日付が変わっています。
このように、ソースを改修する場合はSubVerionをメインとして考えれば
同じソースを改修しあうこと(競合)がなくなるのでソース管理者が必要なくなります。
運用ルールはただ一つ「ソースを改修する前はロックを取得しましょう」だけです。
また、ソース管理台帳もうまくtracを利用すれば、廃止出来るかも知れません。
以上で終了です。
(記事を書いた日:2014/05/19)