Compartilhar via

【MSC FollowUp】ひとりプロジェクト（デモ環境）の成果発表 - ソース管理と変更セット

  • Artigo

こんにちは。今回は、レポートではありません。Team Foundation Server （以下、TFS）で管理しておくと、ソースコードの状況を詳細なレベル（それこそどのコード行がだれによってどう変更されたか・・・）から粗いレベル（このバグを修正したときに変更されたものはどれか・・・）まで、状況を知りたいときに知りたい粒度で知ることができるようになります。

今回は、ひとりプロジェクトで作成されたソースコードの管理状況から、そんな知りたいことがどう知ることができるのか？を見ていきましょう。

まずは、ソース管理されているとこんな状況がわかります。

 image
上のスクリーンショットは、ソース管理エクスプローラというもので、チーム エクスプローラからアクセスできるものですが、こちらを見ると、ソースコード全体の『今』を知ることができます。

『今』とは、

  • リポジトリに格納されている最新のソースコード
  • 自分の開発クライアント PC 上のソースコードとリポジトリの最新のソースコードとの差異
  • 誰がどのファイルを触っているか/ロックしているか

といったことです。これから自分が変更しようとしているファイルが他の人によって変更中だとするとどうでしょう。その後、その人の変更した箇所を自分の変更したものとマージする必要がある可能性が高いことを示しているわけです。また、自分の開発マシン上のソースコードがリポジトリの最新のものと比べて古い場合も同様に、いつかマージして差異を解決する必要があることを示しています。この状況を知ることは、非常に貴重です。なぜなら、『覚悟』が決まるからです。後で、マージする覚悟だったり、この変更は後回しにする覚悟であったりするわけです。これがわからないと「怖くて触れない」ですよね？これも一つの見える化ですね。

さて、ソース管理エクスプローラでは、そのままソリューションやファイルをダブルクリックして、開くこともできます。リポジトリと開発マシンとの差異もわかりますので、通常は、開発マシンのソリューションファイルをダブルクリックして Visual Studio を起動したり、Visual Studio を起動し、ソリューションを開いたりすると思いますが、このソース管理エクスプローラからソリューションを開く方が、安全・安心です。

さて、開発中には、もちろん過去どのような変更を行ったのかを知りたくなることもあるでしょう。たとえば、コード中に不可解なものを見つけたときや、過去にどのような修正方法をしたのかノウハウを知りたいときなどですね。そんなときは履歴を一発！

image

ポイントは、TFS では変更セット単位で管理されていることです。この修正を行ったときには、このファイルだけではなく、他のファイルにも変更されていることがあるわけです（単体テストを実践しているならば、単体テスト用のコードにも変更されている可能性は高いわけですしね）。これらを変更セットという『塊』ようするに開発のトランザクションの単位で知ることもできるわけです。ノウハウを知るにはもってこいですね。image

さらに、この変更セットは、 バグやタスクといった作業項目と関連づけることもできるのです。

image

当然、作業項目の詳細な情報もクリック一発です (^^)

image

で、リンクの情報を見ると、先ほどの変更セットがあるのでクリックすると・・・（以下略）。要するに、ソースコードからもバグやタスクといった作業項目からも双方向に情報を追跡できるのです。

これは非常に価値があります。開発者は、前述のようにソースコードからアプローチすることが多いでしょう。しかしながら、プロジェクトマネージャやテスト担当者は、ソースコードの内容よりもバグやタスクの状況を知りたいわけです。この価値観であったりコミュニケーション粒度のギャップがしばしば開発者と他のチームメンバーのいざこざの原因になったりするわけですが、この関連付けができているだけでそういった課題が解決できてしまうわけです。

では、最後に TFS 2008 から加わった新しい機能を紹介しておきましょう。これも、ソースコードの状況を見える化してくれる非常にお役立ち機能です。履歴は、何をやったかベースで情報を一覧表示してくれますが、これからご紹介するものは、ソースコード全体のどこを誰がどう書いたかを見える化してくれます。

 image

ソースコードの左側に、誰がいつ、このブロックを書いたのかを示しているのがおわかりいただけるとおもいます。左端には、番号が振ってありますね？これは変更セットの番号です。先ほど履歴のところでご紹介したのと同様にこの番号をクリックすると、関連するソースコード一式とそれと関連付けられているバグやタスクの情報などが把握できるわけです。

では、こういう仕組みがないと皆さんどうしているのでしょうか？おそらく、バージョン管理ツールのコメント欄にバグのIDとか対処方法とかを記述することになるでしょう。この行を変えたよというのは「差分で見てね」とか「ソース内にコメントを記述する」なんてことをしているかもしれません。

これらは、人に完全に依存してしまいますよね？コメントの書き方は個人差がでますから。

だったら、チェックアウト－チェックインのモデルの範疇で、バグやタスクと関連付けるだけで、その情報がほぼ自動で記録できる方がミスもなくていいですよね？

今日は、そんなソースコードの管理ついてのお話でした。

関連投稿:

 

T. N