カテゴリー: TFS2012

前回のADユーザ即時反映で、PowerShell実行時のユーザにはジョブ「AllJobs」に対してRead/Queueのアクセス権が必要であること、通常はTFS管理者に権限が割り当てられていると書きましたが、ユーザ追加の都度TFS管理者がシェルを実行するのが面倒なときは、開発者に権限を与えることができます。

“TFSのジョブへのアクセス権変更” の続きを読む

1つ書き忘れてました(^-^;

分岐を使用した場合、TFSのビルド定義はそれぞれの分岐に対して別々に作成することになります。
（DEVELOPMENTブランチに対する修正なのに、MAINブランチに対するビルドの実行は無意味ですから）

でも、ビルド定義の中で、どの分岐に対して実行するかという定義はありません。
ではどうするかというと、ビルド定義の中の「ソース設定」で切り分けます。


（今回使用した環境がTFServiceだったので、「$/BranchTest/Drops」があります。ローカルのTFServerの場合にはありません）

デフォルトではTFSのチームプロジェクトのルートフォルダが登録されていると思いますが、それを分岐したブランチに変更します。
→分岐時に作成したワークスペースで指定したソース管理フォルダと同じになります。


（「$/BranchTest/Drops」は残ったままだとビルド実行時にエラーになりましたので削除しました）

また、「プロセス」でビルド対象とするブランチ内のソリューションファイルを指定します。

これで、それぞれの分岐に対するビルド定義が作成できます。
「MAINブランチは定時ビルドだけにして、DEVELOPMENTビルドはゲートチェックインと定時ビルドを組み合わせて行う」といったこともできます。

ここまで出来れば、安心して分岐が使えるのではないかと思います。

前回の続きです。

マージしたときに、マージした修正した内容が競合することがあります。
ありそうな例としては、こんな感じでMAINブランチにマージされたときです。


RELEASEブランチとDEVELOPMENTブランチで同じ処理に対して別々の修正を行ったときです。この例では、DEVELOPMENTブランチからMAINブランチにマージを行った時に競合となります。
TFSで競合を検知した場合、「競合の解決」画面が表示されます。

排他的に採用するときは「ターゲット分岐バージョンを保持する」もしくは「ソース分岐バージョンを保持する」ボタンを押します。

内容を確認しながら手動マージするときには「マージツールで変更をマージする」ボタンを押すと、編集画面が表示されます。

どちらか片方の修正部分をそのまま使用するときは、使用する側のチェックボックスをONにします。（両方のチェックボックスをONにすることも可能です。結果は下半分のエディタ画面に反映されます。）
どちらでもなく、独自の修正を行う場合は、下半分のエディタ部分で直接修正することも可能です。
調整が終わったら、「マージの許可」ボタンを押すと「競合の解決」画面に戻ります。


（「競合の解決」画面から、調整が終了したファイルはなくなっています）

その後、チームエクスプローラーの「保留中の変更」でチェックインします。

これで、分岐に関する基本的な操作は終了です
RELEASEブランチに対する操作についても、DEVELOPMENTブランチと同じになります。
（管理対象が異なるだけ）

VSSでは、追加開発中に障害対応が重なるとどうしようと悩んでましたが、これだけできれば安心して対応できます。

[2013/04/07追加]
分岐に対するビルド定義について追加しました。継続的インテグレーション(CI)までできないと安心できないですね^ ^;

まだまだ続いてます。
DEVELOPMENTブランチに対する変更をMAINブランチにマージしてみます。
まずはDEVELOPMENTブランチに対して変更を入れます。
＜変更前＞


＜変更後＞

ソース管理エクスプローラーを起動します。
前準備として、ソース管理エクスプローラーで使用するワークスペースを「BranchTest-MAIN」（MAINブランチ）に切り替えておきます。


切り替えを忘れていると、実際にマージを実行したときにこんなエラーで怒られます。

「BranchTest-Dev」（DEVELOPMENTブランチ）フォルダを右クリックし、「分岐とマージ」－「マージ」を選択します。

マージウィザードが起動されます。

「次へ」ボタンを押すと、マージ対象にするバージョンの選択になります。

意図的に特定の変更セットだけをマージすることもできますが、ここではデフォルトの「最新バージョン」で進めます。

最後の画面で「完了」ボタンを押します。

しばらくすると、ウィザード画面が閉じて、ソース管理エクスプローラーに戻ります。
マージ自体はこれで終了しているのですが、MAINブランチ側がチェックアウトされた状態になっているので、チームエクスプローラーの「保留中の変更」でワークスペースを「BranchTest-MAIN」に切り替えてチェックインします。

これでマージは終了です。
次はマージで競合が発生したときについてです。

複数のワークスペースが定義された環境で作業をしていると、どのワークスペースで作業をしているのかがわからなくなることがあります。
こんなときは、チームエクスプローラーで「保留中の変更」を表示します。


こっそり、作業中のワークスペースが表示されています。
また、ここでワークスペースを切り替えることもできます。
※「保留中の変更」の検索対象を切り替えるだけなので、通常切り替えることはしないと思います。

しかも、ソリューションファイルを開いたときに、そのソリューションファイルがどのワークスペース配下にあるかによって、自動的にワークスペースが切り替わります。

次はDEVELOPMENTブランチで変更した内容をMAINブランチにマージしてみます。

TFSでは、TFSサーバ側で管理しているプロジェクトフォルダと、作業を行うコンピュータのローカルフォルダをマッピングするために「ワークスペース」というものを定義します。
※別プロジェクトのワークスペースまで消さないでくださいね

ソース管理エクスプローラー、もしくはチームエクスプローラーの「保留中の変更」からワークスペースの管理画面を開きます。

デフォルトだとコンピュータ名がワークスペース名となったワークスペースが１つ作成されていると思います。

一度このワークスペースを削除し、改めてMAINブランチ用のワークスペースを作成します。

設定後、最新ファイルの取得確認が表示されますので、「はい」で取得します。

これで、MAINブランチ用ワークスペースが作成できました。

同様に、DEVELOPMENTブランチ用ワークスペースも作成します。

ちなみに、なぜブランチごとにワークスペースを作成するのかですが、TFS/VSがワークスペースの定義を基準にしていろんな管理を行うためです。
たとえばですが、複数のソリューションを同じワークスペースで作業した場合、とあるソリューションで変更し、チェックインしようとしたときに、別ソリューションの変更中ファイルも合わせてチェックインしてしまいます。
これではブランチを作る意味がないので、ブランチごとにちゃんとワークスペースを作成するようにしましょう。

次は、作業中ワークスペースの確認についてです。

前回からの続きで、分岐を作成します。
今回はDEVELOPERブランチを作成してみたいと思います。

分岐はチームエクスプローラーから作成します。
MAINブランチ（と思い込んだフォルダ）を右クリックし、「分岐とマージ」－「分岐」を選択します。

すると、分岐のターゲット名とかを指定する画面が表示されます。

このままだと、どのブランチかわからないのでターゲットを「$/BranchTest/BranchTest-分岐」から「$/BranchTest/BranchTest-Dev」に変更して「OK」ボタンを押します。
すると、ワークスペースのマッピングを指定する画面が表示されますので、マッピングするローカルフォルダを入力して「マップ」ボタンを押します。
（ローカルフォルダの名前も、ブランチ内容がわかるフォルダ名で指定したほうがいいと思います）

しばらくすると、DEVELOPERブランチが作成された状態（フォルダが作成され、よくわからないマークがついた状態）になりますが、まだチェックインされていないので、チェックインしてしまいます。
（ちなみに、MAINブランチである「BranchTest」のアイコンが分岐アイコンに変更されてます）

チェックインが終了すると、DEVELOPMENTブランチである「BranchTest-Dev」のアイコンも分岐アイコンに変更されます。

次は、ワークスペースの作成についてです。

前回の「TFS 分岐ガイド」にある「基本」分岐計画によると、
　・最初にMAINブランチを作成
　・開発を行うときにはDEVELOPMENTブランチを作成、そこで開発差分をコントロール
　・開発が完了したらMAINブランチに開発内容をマージ
　・顧客にリリースするものが固まったときにRELEASEブランチを作成
　・リリースしたものにバグがあったときはRELEASEブランチに対して修正を行う
　　修正したもののうち、製品として取り込むべきものがある場合にはMAINブランチにマージする
といった感じになっています。
（TFSのゲートチェックインと自動テストを使えば、単一案件の開発はMAINブランチだけでコントロールすることもできると思いますが、今回はDEVELOPMENTブランチを作成することにします）

この計画に従うと、まずはMAINブランチを作成し、初期ソースを格納します。次にMAINブランチからDEVELOPMENTブランチへ分岐します。
・・・ですが、今まで分岐なんて考えていなかった場合、「MAINブランチなんて作ってない！」だと思います。（ええ、自分のそうです^ ^;）
となると、TFSに登録された状態はこうなっていると思います。
（チームプロジェクト「BranchTest」に対して、ソリューション「BranchTest」とプロジェクト「BranchConsole」「BranchTestLib」を登録しています）




新規作成時なら、一度削除してMAINフォルダを作成後、ソリューションをMAINフォルダの下に格納されるように再登録もできると思いますが、既に開発が進んでいると対応が難しいと思いますので、ソリューションフォルダをそのままMAINブランチと思い込むことにします。

次は、分岐の作成です。

今までVSSだったこともあり、そろそろちゃんとした分岐を使った修正について勉強しようと思い、確認したことをいろいろと残していこうかと。
（と言っているうちにUpdate2出てしまって、Gitも確認したくなってますが^ ^;）

個人的にですが、分岐は「何かしらの修正を行うときに、今までの内容を保全し、安心して別の追加開発／変更を行うための管理方法の一つ」だと思っています。
それだけであればフォルダ管理でもVSSでも対処できると思いますが、当然複数人での開発／管理作業（履歴・差分照会／案件との紐づけなど）の効率を考えると、ちゃんとしたバージョン管理システムを使うことになります。

バージョン管理システムはCVS／Subversion／Gitなどなどありますが、大抵のシステムは「分岐／ブランチ」という方法で追加開発／変更を行えるようになっています。
何かしらの開発／変更が発生したとき、修正元となるベース（トランク／Mainブランチ）からソースファイルを分岐し、分岐先に対して変更をかけ、必要であれば分岐先から分岐元に修正内容を反映させる（マージ）ことになります。

どういう開発のときにどういった分岐をさせるとよいのかは千差万別のようですが、一例として「TFS 分岐ガイド」なるものがあります。
最新版はVS2012版のv2.1ですが、英語しかありません。
日本語はVS2010版のv1がありますので、（自分もですが）勉強したいけど英語は読めませんという方は日本語でも大丈夫かと思います。

次からは、分岐ガイドの「基本」分岐計画を参考にさせてもらいながら、実際にVS上でどうすれば分岐が作れるかを書きたいと思います。
（自分は、最初の分岐をどう作るかとか、VSのワークスペースをどうすればいいのかがすぐにわからない子でしたので(;´Д｀)）