前回のチケット駆動開発
「4.割当てられたチケットを担当者が着手する状態：accepted」
から、ソースを改修〜コミットするまでを少し細かく見ていきます。

例えば、下図のようなソース管理フローで開発を行っているとします。


運用ルールとして、 問題点として、 3.は本番ライブラリー以外を使用することも可能ですが、
バックアップを管理する上でもソース管理者はやはり必要です。

今回はSubVersionを利用して、ソース管理者を必要としない開発を目指します。

前回の下図、担当者が着手するところから始まります。


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



ロックを選択します。


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


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


ソースを改修して・・・


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


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


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


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


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


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


なお、先ほどのロック取得のところで、「ロックの強制取得」がありました。
チェックをすると、ロックを取得することができます。
ルール違反ですが、担当者がお休みなど緊急時に使用できます。

前田さんは、対象のプログラム３本を全て修正しました。


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


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


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


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


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


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


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


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


ソース反映中。


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


このように、ソースを改修する場合はSubVerionをメインとして考えれば
同じソースを改修しあうこと（競合）がなくなるのでソース管理者が必要なくなります。

運用ルールはただ一つ「ソースを改修する前はロックを取得しましょう」だけです。

また、ソース管理台帳もうまくtracを利用すれば、廃止出来るかも知れません。

以上で終了です。

(記事を書いた日：2014/05/19)