TFS Service の Team Project + Git をVisual Studio で使う
はじめに
TFSに分散バージョン管理が導入されるかと思ったら Git をバージョン管理に利用可能となりました。ただあまり情報がないようなのでVisual Studio で Git を使う情報がなかったのでまとめてみました。このエントリでは、TFS Service にチームプロジェクトを作成し、コミットするまでを説明してます。
環境
- Visual Studio 2012 update2
- Windows 8
- Team Foundation Service
- Visual Studio Tools for Git 0.8.5.1
TFSバージョン管理と違うところ
TFSバージョン管理だとTFSで管理しているタスクと関連付けさせる事ができますが Visual Studio Tools for Git では今のところ対応していない模様。
手順はここからになります。
TFS Service にTeam Projectを作成する
New Team Project + Git をクリックします。
プロジェクトの作成画面が出るのてプロジェクト名を入力。
あと、Version Control には Git を選択しましょう。
そして Create Project。
2分程度待つと。。できました！Navigate to Project をクリックするとプロジェクトのホームページへ移動します。
プロジェクトのホームページの CODE をクリックします。
すると 「git clone してね」的な事が書かれています。
ローカルリポジトリにコードをコミットする
Visual Studioを起動し、チームエクスプローラからTFS Serviceに接続します。
接続すると先ほど作成したプロジェクトがGitのアイコンで表示されます。
これをダブルクリックします。警告が表示されるため内容を確認の上、OKをクリックします。
Visual Studio Tools for Git をインストールしていない場合はこのメッセージが表示されるためリンクをクリックしダウンロードとインストールを行います（インストール手順は割愛）
インストール後、Visual Studio を再起動し、チームエクスプローラを開くと「Clone」が表示されます。
TFSService に作成したチームプロジェクトのローカルリポジトリを作成する事ができるので「Clone」をクリック
Cloneしたローカルリポジトリをダブルクリックすると Git をインストールするように表示される。Installをクリック。
msysgitVS.exe がダウンロードされるので実行。
Web Platform Instraller が起動して Git for Windows(x86)インストール画面が開くのでインストール。
インストール完了後、Visual Studio のチームエクスプローラでチームプロジェクトを開くと、Install～が消えます。
管理する新規プロジェクトを作成します。作成先は先程 clone したGitリポジトリのパス。「Add source control」にチェックを入れてください。
作成後、チームエクスプローラのchanges を表示すると新規作成したプロジェクトがローカルリポジトリに追加された状態になります。
このままだと master にcommitするため新しいブランチを作成します。
が、どうやら空っぽのリポジトリからは new branch作成できない（Create Branchがクリックできない）のでReadme.txt を作成して、commit します。コマンドの確認も兼ねてコマンドプロンプトから実行します。ローカルリポジトリでコマンドプロンプトを開きます。このサンプルだとC:\Users\hogehoge\Source\Repos\MyStatusReceiver になります。
> git add ReadMe.txt > git commit ReadMe.txt -m "first commit"
Visual Sutdio に戻ってチームエクスプローラの changeを再度開いて
Branch master▼の▼をクリックして、new Branch を作成します。
作成完了！
commit します。
次に作成した branch から master へマージします。
リモートリポジトリへコミット
Branches で、Unpublished Branches で master を右クリックします。
で、Publish
TFS Service で見ると commit されています。
以上です。
TFSの作業項目と連動するのは欲しいなぁ。これから使っていくので色々TIPSが増えていく場合は都度エントリ書いていきます！
ALM Advent Calendar 2012 開発と運用を繋ぐために ~DevOpsを考える~
ALM Advent Calendar 2012 #TFSUG : ATND ラストのエントリです。
@kaji_3 こと、かじです。SIerでエンジニアしてます。
ALM Advent Calendar のラストです。TFS ではなくALM Advent Calendar となった事で幅広いエントリになり、大変勉強になりました。自分としてはネタを出しきったので来年に向けて研鑽していきます。今日は、ALM と一緒に語られる事が多い DevOps について考えている事をまとめます。
コンテキスト
- 受託開発
- エンタープライズ
- 継続的デリバリーが出来ていない現場
DevOps と 成果物請負受託開発 & 運用
DevOpsは「Develop」＝「アイデア→動くソフトウェア」、「Operation」＝「インシデント→解決策」という2つの作業を顧客価値向上のためコラボレーションする事です。詳細はALMってなに？をご参照ください。
DevOps という言葉は「顧客ビジネスの価値向上」をゴールとしていれば自然と辿り着く気がしますが、成果物請負型開発は顧客ビジネスの価値向上がゴールではないためSIerへの浸透は時間がかかる気がします。（ちなみに、顧客のビジネス価値向上=対価安くする事、ただ働きと考えている人は頭冷やしてください。）
Operation を考慮しなければ詰む
DevOpsの浸透に時間がかかるとは言え運用を考えずに開発すれば、インシデント対応時の調査に不都合が発生し顧客と運用担当者から指摘がきます。指摘によっては自社の評価が悪くなり継続的に仕事を頂けず自社の価値が減ります。なので、「運用のしやすさ」を考慮するのは当然だと思うのですが。。
開発時になんで運用の事を考えられないか
「運用の事を考慮して」は当然の事なのですが出来ていない現場をちょくちょく見ます。非機能要件の定義不足、運用要件の定義不足、タイトなスケジュールによる実装対象から外れたなどが直接的な原因ですが、根本は「運用した事がないから」ではないかと考えてます。経験があれば情報収集に困るアプリケーションは作りたくないと考えるはずですが、必要とされるスキルと知識が異なるため開発チームに所属する人は運用経験がない場合がよくあります。そんな人に運用を意識してもらうために幾つかやっていた事をあげてみます。
開発チームでやっていた事
保守開発では運用チームから人を引っ張ってくる
機能拡張の時に現在システムを運用している人に設計、テスト設計のレビューをして貰いました。運用時に考慮しなくてはいけない事は設計時に盛り込みますが、システムの癖（顧客がよくチェックする箇所、システムエラーが発生しやすい箇所など）に対応するため運用の方の知識は重要でした。
動作確認環境を使い不具合調査シミュレーション
ログ出力レベルなどの設定を運用時と同一のテスト用環境を構築し、画面間の遷移や機能間の連携のテストを実施しました。そこでシステムエラーなどが発生し、調査しずらい箇所については課題管理してログ出力レベルの見直し等を実施しました。
本当にやりたかった事
保守運用時も開発時と同じツールを使う
開発時、顧客の受入テスト以降は受入テストが運用と考えるとDevOpsの模擬練習のようなもので、顧客のフィードバックをシステムに適切に反映していると思います。ここで学んだリズムがツールによって支えられている場合、例えば、チケット管理でバックログ、バグを管理→バージョン管理にチケット番号を反映してリリース管理となっているとこのツールを使ったよいサイクルはツールがなくなると崩れてしまいます。しかし、運用になると顧客環境でチケット管理（インシデント管理）される事が多いためこの旨いサイクルが崩れてしまいます。開発時に使っている環境をそのまま顧客環境で再現するもの手ですが、他社との連携が難しくなります。そのため、ローカルな環境にツールを準備するのはDevOpsを考慮するとよろしくないはずです。Team Foundation Service は私の考えている同じツールを使うという所に見事にマッチしていると思います。クラウド上でデータを管理するため顧客との調整は必要と思いますが、システムの特性によっては可能と思います。
そんな理由で来年はTeam Foundation Service を業務で利用したいのですがセキュリティとか考えなくてはいけない事が多いのでどなたか事例を教えて頂けると幸いです!!
ALM Advent Calendar 2012 TFSからの通知メールをカスタマイズする #tfsug
ALM Advent Calendar 2012 #TFSUG : ATND 15日目のエントリです。
@kaji_3 こと、かじです。SIerでエンジニアしてます。
今日はTFSのメールによる通知、プロジェクト警告の設定と、カスタマイズについてです。
作業項目の変更、ビルドイベントなどのTFSからの通知をメールで受け取る事ができます。ゲートチェックインが導入できないプロジェクトで自動ビルドが失敗した場合などに便利ですね。ただ、失敗時にメールを受け取るのも寂しいのでメールにメッセージを込めるのもありかと。ということでカスタマイズしてみましょう。
このエントリの結論
カスタマイズしてこんな通知を受け取ることができます。
環境
- Visual Studio 2012 Update 1
- Team Foundation Server 2012 Update 1
送信側の設定
インストール時に設定していない場合は、「Team Foundation Server 管理コンソール」を起動し「アプリケーション層」→「通知の設定」をクリックします。
送信用メールに必要な設定を行います。
TFS2012から認証が必要なSMTPサーバへ送信するための設定が画面から可能になっていますねー
（ここでメール送信をテストする機能が欲しい。。）
受信側の設定（チームメンバー）
Visual Studio を起動し「チーム」→「プロジェクト警告」をクリックします。
Web アクセスのプロジェクト警告が表示されます。
「自分用の警告の送信先（編集）」をクリックして送信先メールアドレスを設定します。
あとはどんな通知を受け取るか設定します。
高度な警告の管理ページを見ればわかりますがデフォルトでの「ビルドが完了したとき」と「ビルドの終了」の違いは以下の通り。
- ビルドが完了したとき
- 自分が要求していないビルドも含む
- ビルドの終了
- 自分が要求したビルドのみ
チームとしての設定
個人用設定の画面の「高度な警告の管理ページ」をクリックします。
（コントロールパネル経由で行く方法が正しいのかも知れませんが手間なので紹介しません）
高度な管理ページの「チーム個の警告」の対象となる警告を選択します。今回は「ビルド個の警告」です。
新規作成から画面に従っていけば作成できますでの省略します。
本文のカスタマイズ
TFSからのメールはXLSで元データから加工されます。そのテンプレートは以下の場所にあります。
C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\TFSJobAgent\Transforms\1041
送信形式ごとにテンプレートがあります。
（どの形式になっているかは、高度な管理ページから参照できます）
今回は、「ビルドが完了したとき」に「HTML」で送信する設定がされているとして「BuildCompletedEvent.xsl」を編集します。
（AAをメールにつける場合、フォントを指定する必要があるのでHTMLにする必要があります）
XSLのため、慣れていないと厳しいですが見ているとビルド失敗の条件分岐がわかります。
<xsl:when test="tb:Build/@Status = 'Failed'">
これを使ってテンプレートを以下のように編集します。編集時は管理者権限が必要になるので注意。
TFSTips/BuildCompletedEvent.xsl at master · kaji-3/TFSTips · GitHub
んで、ビルドエラーをしてみると。。。。
こうなります！！
どうぞ楽しいTFSライフをお送りください！
Visual Studio Advent Calendar 2012 コードスニペットを使ってみよう！
Visual Studio Advent Calendar 2012 : ATND 10日目のエントリです。
@kaji_3 こと、かじです。SIerでエンジニアしてます。
コードスニペット便利ですね！
最近まで「コードスペニッド」、今まで「コードスニペット」って言ってて恥ずかしい思いをしました！今日はコードスニペッドについてまとめてみます。
コードスニペッドって？
皆様当然知っているとは思いますが。。
と入力してタブキーを押すと
と展開される入力補助機能です。自分で作成したコードスニペッドを登録する事もできます。
チーム開発において
少し大きな開発チームになるとコード規約を作成して、何々を使うときにはこう記述して、何々を作成する時はああ記述してください、アナウンスする事になったりします。そういったルールや規約は静的コード解析でチェックする、レビューでチェックするというものありますが最初からルールどおりのコードが手軽にできるのが一番です。そこでコードスニペット！
ちょっと手間ですが、コードスニペットを作成し、各メンバーのVisual Studio に登録して使ってもらうのがよいかと思います。
コードスニペットの作成の仕方
しかしコードスニペットはちょっと手で書くのは大変です。そのため以下の拡張機能を利用します。
Snippet Designer extension
簡単ですが手順を説明しておきます。
0. 準備
Snippet Designer extension
をダウンロードしてインストールします。
1. 対象部分の切り出し
スニペットに切り出す箇所を選択します。
そこで、右クリックすると表示される「Export a Snippet」をクリックします。
2. 初期設定の入力
スニペット編集画面になります。スニペットの編集画面と、スニペットのプロパティが表示されます。初期設定として以下の３つを入力します。
- エディタの「Snippet」
ファイルの名称を指定します。
- プロパティの「Descirption」
スニペットの概要を指定します。コードスニペットマネージャーで表示されます。
- プロパティの「Shortcut」
スニペットを呼び出すためのショートカットキーを指定します。
3. 編集項目の入力
スニペット呼び出し時、編集可能な箇所を指定します。編集可能にしたい箇所を選択し右クリックして表示される「Make Replacement」をクリックします。
するとエディタの下部に編集用項目が増えます。
4. 保存と利用
保存先は、デフォルトで表示される「My Code Snippets」に保存します。これで「Shortcut」と指定した文字＋tabキーで使うことができます。
便利なスニペットに期待するところ
さていかがでしょう。コードスニペットがこれで大分使いやすくなるはずです。ただ、利用するときに「My Code Snippets」に登録するか、スニペットマネージャーを利用して登録しなくてはいけないのが手間ですね。ソリューションのどこかに保存しておいたら自動でそのスニペッドが利用できるようになるといいなーと思います。
おまけ
私が作成した簡単なスニペットを github で公開しています。参考にどうぞ！
kaji-3/VisualStudioCodeSniped · GitHub
ALM Advent Calendar 2012 ツールを使わなかった、あるシステムのライフサイクル
ALM Advent Calendar 2012 #TFSUG : ATND 6日目のエントリです。
@kaji_3 こと、かじです。SIerでエンジニアしてます。
いつもは技術系ですがALMということで今回は趣向を変えて、ツールを使わなかったとあるシステムのライフサイクルを振り返りつつ、どうあるべきだったか考えてみようと思います。
誕生
とある業務システム。本番運用開始と同時に新規開発での多発する仕様変更と品質の問題に疲弊したメンバーがリタイヤした現場。
稼働直後にプロジェクトへアサインされた訳ですが色々な課題がありました。
バージョン管理されていないソース、設計書
VSSが存在していましたがテストが完了したものから管理台帳に記載してVSSにチェックインするという謎ルールでした。
ビルドサーバがない
「yy.dll」「xx.exe」が50個。常に最新のソースでビルドしなくては危険極まりないのにビルドサーバが存在せず、うっかり古いソースでビルドしてデグレ発生という事故を防ぎたい所ですが専用機がありません。
要望、課題、不具合の管理台帳がない。
バックログは大小100近くありました。一つのバックログはテキストファイルや変更要望書という形で単独で存在しており、まとまったものはありませんでした。
新規開発直後は人員も多く人力で品質、ミスを防いでいるかもしれませんが人数が減るとどうしても手薄になるのですぐに自動化、ツールの導入をした方がいいです。私は知識と権限の不足からどの課題にも何も対応せず運用していましたが、どの課題についても一度は障害を伴った事故を発生させ、ビルドサーバ、管理台帳を顧客と調整し作ることになりました。
青年期
3年が経過しました。大規模な改修を半年に一回。計6回実施。顧客も保守メンバーも慣れてきました。そしてシステムも安定稼働し、顧客にも余裕が産まれて改善が始まりました。
過去バックログの「実績工数」
過去の保守開発のどのバックログにどの程度の規模対応したかを参照し、新しい保守開発の工数見積をするよう顧客から要望がでました。過去の保守案件は「参考」程度にはしていましたが、トータルでどれだけのコストだったかのみしか記録していない事、個々のバックログに対してどの程度コストがかかったかが記録されていなかった事から実績からの見積はできませんでした。
（TFS2012ではタスクに実績時間をつける項目はないのでカスタマイズする必要があります）
バックログと改修範囲のトレーサビリティ
業務のルールも満遍なく改修される事はなく、集中的に改修が入る箇所は決まってきます。そしてバックログの種類によって影響範囲も決まってきます。この影響範囲をベンダーの調査工数削減のため、過去保守案件の実績から見える化をする要望が出てきました。
各種台帳の肥大化
課題管理台帳のレコード件数が1000を越え、インシデントを管理していた別の台帳も2000件ぐらいになってました。Excelで1000件を越える行数ファイルではとても作業になりません。
実績工数は概算になり、トレーサビリティは記録しておらず、台帳だけはAccessにツールに変更しました。この時点でTFSを知っていたらコストがかかっていても移行しましょう！と顧客に提案していたかもしれませんが運用手順も固まっていて移行コストは大きかったのではないかと思っています。
晩年期の課題
更に年月が経ちついに再構築の話が出てきました。初期メンバーは全て抜けて再構築時の事を知らないメンバーのみとなりました。
長年運用しての課題が人の記憶にしか残っていない
課題台帳はレコードが大きすぎるという事から、顧客リーダー変更時に一度破棄されました。その結果長年付き合ってくれたメンバーの中だけにシステム運用時の課題、設計上の歪みが残る事になり新システムには反映されませんでした。
時間の経過で発生する課題に対応するために
正直ツールではなくプロジェクトの運用がよろしくなかったと思っています。しかし、TFSを入れていたら変わっていた「かも」しれません。目的があってのツールですが未熟なプロジェクトならツールの背景にある思想を学ぶことで良いプロセスになる事もあるのではないのでしょうか。TFSやALMの思想について聞いて「いいかも」と思ったら勉強しつつ導入してみてはいかがでしょう。
TypeScript を保存時にコンパイルする
環境
- Web Essentials 2012
- Visual Studio 2012
セットアップ
Web Essentials 2012 をインストールします。
Web Essentials 2012 extension
Visual Studio の「拡張機能と更新プログラム」から追加してください。
「ツール」→「オプション」→「Web Essentials」
Web Essentials の項目に「TypeScript」があります。
これの「Compile TypeScript on save」を True にしてください。
これだけ。
