TFS2012

2013年4月 7日 (日)

TFSの分岐について:分岐に対するビルド定義

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

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

でも、ビルド定義の中で、どの分岐に対して実行するかという定義はありません。
ではどうするかというと、ビルド定義の中の「ソース設定」で切り分けます。
016
(今回使用した環境がTFServiceだったので、「$/BranchTest/Drops」があります。ローカルのTFServerの場合にはありません)

デフォルトではTFSのチームプロジェクトのルートフォルダが登録されていると思いますが、それを分岐したブランチに変更します。
→分岐時に作成したワークスペースで指定したソース管理フォルダと同じになります。
018
(「$/BranchTest/Drops」は残ったままだとビルド実行時にエラーになりましたので削除しました)

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

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

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

2013年4月 6日 (土)

TFSの分岐について:マージで競合が発生したとき

前回の続きです。

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

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

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

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

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

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

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

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

TFSの分岐について:マージ

まだまだ続いてます。
DEVELOPMENTブランチに対する変更をMAINブランチにマージしてみます。
まずはDEVELOPMENTブランチに対して変更を入れます。
<変更前>
001_3
<変更後>
002_2

ソース管理エクスプローラーを起動します。
前準備として、ソース管理エクスプローラーで使用するワークスペースを「BranchTest-MAIN」(MAINブランチ)に切り替えておきます。
004_2
切り替えを忘れていると、実際にマージを実行したときにこんなエラーで怒られます。
005_2

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

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

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

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

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

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

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

TFSの分岐について:作業中ワークスペースの確認

複数のワークスペースが定義された環境で作業をしていると、どのワークスペースで作業をしているのかがわからなくなることがあります。
こんなときは、チームエクスプローラーで「保留中の変更」を表示します。
017
こっそり、作業中のワークスペースが表示されています。
また、ここでワークスペースを切り替えることもできます。
※「保留中の変更」の検索対象を切り替えるだけなので、通常切り替えることはしないと思います。
018

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

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

TFSの分岐について:ワークスペースの作成

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

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

003

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

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

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

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

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

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

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

TFSの分岐について:分岐作成

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

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

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

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

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

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

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

TFSの分岐について:MAINブランチをどうするか

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

この計画に従うと、まずはMAINブランチを作成し、初期ソースを格納します。次にMAINブランチからDEVELOPMENTブランチへ分岐します。
・・・ですが、今まで分岐なんて考えていなかった場合、「MAINブランチなんて作ってない!」だと思います。(ええ、自分のそうです^ ^;)
となると、TFSに登録された状態はこうなっていると思います。
(チームプロジェクト「BranchTest」に対して、ソリューション「BranchTest」とプロジェクト「BranchConsole」「BranchTestLib」を登録しています)
001_2
新規作成時なら、一度削除してMAINフォルダを作成後、ソリューションをMAINフォルダの下に格納されるように再登録もできると思いますが、既に開発が進んでいると対応が難しいと思いますので、ソリューションフォルダをそのままMAINブランチと思い込むことにします。

次は、分岐の作成です。

2013年4月 5日 (金)

TFSでの分岐について:基本的な考え方

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

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

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

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

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

2013年1月 8日 (火)

TFS2012ライセンスメモ

明けましておめでとうございます。
つたないブログですが、本年もよろしくお願いします。<(_ _)>

ふとTFS2012のライセンス情報を確認しようとしたところ、2010の情報はよく出てくるんですが、2012についてはあまり出てこなかったので、ちょっとメモ代わりに作成します。
(出てこない理由として、ホワイトペーパー「Visual Studio 2012とMSDNのライセンス ホワイトペーパー」にきれいにまとまっているからかもしれませんが。)

まずは注意事項ですが、ここから以降の内容はあくまで個人的に関心のある内容を勝手にまとめたものですので、実際に導入される際には上記ホワイトペーパーおよびマイクロソフトへの問い合わせにて確認願います。
Lab Management関連は当面自分が使う予定がないので割愛させて頂きます(マテコラ


ここからはまとめたメモになります。
○サーバライセンス1つにつき、1台のサーバに割り当てることができる
 ここで「1台」の対象になるのは「アプリケーション層」です。
 SQL Serverとかビルドサーバを別サーバにインストールしても、アプリケーション層のインストールサーバが1台であれば、ライセンスは1つでよいということです。

○以下のソフトは「任意の数」の「コンピュータ」(サーバではない)で実行できます。
 ・ビルドサービス
 ・SharePoint Extensions
 ・Project Server Extensions
 ・チームエクスプローラー
 チームエクスプローラーが任意のコンピュータにインストールできるのは押さえてませんでした^ ^;

○SQL Server 2012 Standardの1インスタンスをTFS2012のDBとして使用可能(除くExpress)
 TFS 2012 ExpressはSQL Server 2012 Expressを使用するので対象外になります。

○上記SQL Serverライセンスを行使した場合、TFS2012のSQL Server Reporting ServicesはSQL Server CAL不要。
 TFSのレポートのみ利用するユーザは、TFS CALすら不要!

○MSDNライセンス(Professional以上)が付与されたユーザーが1人以上いる場合、VSをビルドサービスの一部としてインストール可能
 MSDNライセンスですのである意味当たり前ですが、「全員」ではなく「1人以上いる場合」というのが有難いなと思います。

○こんな使い方であればTFS CALは不要(但し、Windows Server CAL/SharePoint CAL/SQL Server CAL[TFS付属ライセンス以外で使用した場合]は必要)
 ・作業項目の入力/表示/編集のみ
 ・TFSのレポートにアクセスする
 ・SCOM(System Center Operations Manager)を使用してTFSにアクセスする
 ・Feedback Client for TFSを使用してTFSにアクセスする
 ・TFSの外部に手動で頒布されて静的データを表示する
 ・チームプロジェクトやプロジェクトコレクションの作成などのシステム管理を目的として最大2つまでのデバイスまたは2人までのユーザーがTFSにアクセスする

○TFS Web Accessの機能のうち、TFS CALだけでは使用できない機能
 ・バックログとスプリントの計画ツール
 ・フィードバックの要求と管理機能
 これらの機能を使用する場合、MSDNライセンス(Ultimate/Premium/Test Professional以上)が必要です。
  ※ProfessionalはNG
  参考情報:MSDNの「Web アクセス許可による機能
  (この資料内で「フル」として割り当てできる機能が「TFS CALだけでは使用できない機能」)

○TEE(Team Explorer Everywhere)の「インストール」はライセンスフリー。
 接続ライセンスは今までの内容の通り。(VSとかからアクセスするのと変わらない)
 TFS Web Accessのフル機能を使用しないのであれば、TFS CALとWindows Server CALで使用可能。

といった感じのようです。

まとめた後の感想ですが、
 「Visual Studio 2012 Premium with MSDNサブスクリプション以上が欲しいw」
 TFS Web Accessのバックログとスプリントの計画ツールとかが使えるのはやはり大きいと思います。たとえアジャイル開発ではなくウォーターフォール開発だったにしても、作業状況をこれだけ容易に確認できる機能は使いたいです。
 さらに、VS自体の純粋な機能差も含めて考えるとPremiumがPremiumすぎます!!
 
 仕事で購入を検討するのであれば、Premiumは選択肢として挙げるべきと思います。

 (でも、この前会社でProfessional購入したばっかりなんですよね...( ;∀;))

2012年12月23日 (日)

1つのチームプロジェクトで複数言語を使用した場合のゲートチェックイン TFS2012 Update1版

ALM Advent Calender」22日目への参加記事になります。

以前に
・「1つのTFSプロジェクトで、.NETとJavaの共存は可能か?
で、1つのチームプロジェクトでJavaと.NETプロジェクトのそれぞれに対してゲートチェックインを設定した場合の動作について記載しましたが、TFS2012 with Update1で改めて確認してみました。

今回、少しだけパワーアップして、
 ・Native C++プロジェクト
 ・C#プロジェクト
 ・Javaプロジェクト
の3つを1つのチームプロジェクトとして登録し、それぞれのプロジェクト用にゲートチェックイン用のビルド定義を作成しました。
010

011

最初はC#プロジェクトでチェックインを実行します。
012
なぜか、ビルド定義の選択肢に「CI-Build-CPlus」がありません。
「CI-Build-CSharp」を選択して実行すると、正常にビルドが実行されました。

次にNative C++プロジェクトでチェックインを実行します。
013
今度はビルド定義の選択肢に「CI-Build-CSharp」がありません。
「CI-Build-CPlus」を選択して実行すると、こちらも正常にビルドできました。

最後にJavaプロジェクトでチェックインを実行します。
014

???、対象のビルド定義が「CI-Build-Java」のみです。
このまま実行すると、正常にビルドできました。

ということで、結論は「複数言語を使用した場合のゲートチェックインでも問題ない」ですが、ビルド定義の選択条件についてはよくわかりません。
→修正した(シェルブ対象となった)ファイルが格納されているフォルダと、その上位(親とか)のフォルダをビルド対象とするビルド定義が選択肢に上がっているような気がしますが、確認できる情報が見つかってません。

無料ブログはココログ