カテゴリー: TFS/Azure DevOps Server

まだまだ続いてます。
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のワークスペースをどうすればいいのかがすぐにわからない子でしたので(;´Д｀)）

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

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

まずは注意事項ですが、ここから以降の内容はあくまで個人的に関心のある内容を勝手にまとめたものですので、実際に導入される際には上記ホワイトペーパーおよびマイクロソフトへの問い合わせにて確認願います。

Lab Management関連は当面自分が使う予定がないので割愛させて頂きます（マテコラ

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

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

○SQL Server 2012 Standardの１インスタンスをTFS2012のＤＢとして使用可能（除くExpress）
　TFS 2012 ExpressはSQL Server 2012 Expressを使用するので対象外になります。

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

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

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

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

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

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

最初はC#プロジェクトでチェックインを実行します。


なぜか、ビルド定義の選択肢に「CI-Build-CPlus」がありません。
「CI-Build-CSharp」を選択して実行すると、正常にビルドが実行されました。

次にNative C++プロジェクトでチェックインを実行します。


今度はビルド定義の選択肢に「CI-Build-CSharp」がありません。
「CI-Build-CPlus」を選択して実行すると、こちらも正常にビルドできました。

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

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

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

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

TFS2012とVS2012をUpdate1環境にしたところ、今までは怒られなかったビルドで警告が出てました。


「格納フォルダーをクロークする必要があります。」と出ています。
ちなみに、クロークは「除外」のことです。
除外しろと言われてもどこを．．．？？

とりあえず、メッセージに記載されているリンク先を参照してみます。
英語にページに飛びますが、右上の言語を「日本－日本語」に変更すれば日本語ページに移動できます。
すると、こんなことが書いてありました。


「必要なフォルダーをすべて含める」のはいいとして、「必要なフォルダーのみを含める」と言われても、必要でないフォルダーって？？

念のため、ビルド定義を見ると、


RTM版ではエラーになりませんでしたが、Update1では「入力が必要である」という警告になっていました。

無い頭をひねってみましたが考えても何も思いつかないので、新しいビルド定義から学ぶことにしてみました。


なんと、最初から「クローク」状態の定義が追加されています！！

ということで、結論は「RTM版でデフォルトのままビルド定義を作成したものをUpdate1に移行した場合、ワークスペースの定義にクローク対象を追加する必要がある」ということです。（「警告メッセージを無視する」という手もありますが、警告とはいえエラーをそのままにするのは精神衛生上よくないかと）

ちなみに、クローク対象として「/[プロジェクトフォルダ]/Drops」が追加されていますが、これはクラウドで稼働しているTeam Foundation Serviceを使ったチームプロジェクトでビルド定義を作成した場合、ビルド出力を格納するフォルダーになります。

個人的な想像ですが、Team Foundation Serviceのビルド定義で「Drops」フォルダを含めた場合、ビルドに必要のないファイル、しかもある程度大きなファイル(.exe／.dllなど)がビルドサーバに転送されることになり、ビルド実行速度／リソースに影響があるのでこの制約が追加されたのではと思います。

オンプレミス環境では「Drops」は使用しないと思いますので、何も考えずにクローク対象として「Drops」を追加しても問題ないと思います。

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

「Microsoft Visual Studio Team Foundation Server 2012 Build Extensions」を使ってAntのBuild.xmlを記述するときに、ビルドに関する情報を使いたい時があります。
（ビルド時のフォルダとか、ビルド時に採番された番号など）

Antの中でechoを使って出力してもいいのですが、ビルド実行時のパラメータを変更することで簡単にログへ出力することができます。

事前にAntを実行するビルド定義を作成し、作成したビルド定義をVisual Studio Shellから実行する時にパラメータを一部変更します。
「パラメータ」タブを選択し、「ログの詳細度」から"Detailed"か"Diagnostic"を指定してから実行します。（ここで指定した内容は１回だけ適用されます）

ビルドが終了すると、ログにAnt実行時のコマンドラインが出力されます。

コマンドライン引数の中で、「-D」で指定されているものがTFSからAntに渡される情報になります。（-D[パラメータ名]=[値]という形式です）

使用例としては、「BuildNumber」をJarファイルのメタ情報として埋め込んでおけば、後でどのビルドで生成したものかが簡単に判別できます。

注意点ですが、残念ながらEclipse+Team Exploere Everywhere(TEE)からではこの手順が使えませんので、Visual Studio Shellから実行してください。
（Eclipseから実行した場合、「パラメータ」タブがありません。TEEを使用するためにVisual Studio Shellは必須ではありませんが、1環境に1台ぐらいはインストールしておいたほうが便利だと思います。）