TFS 2010の使用経験:(制御システム。権利とポリシー)

画像

前回、ブランチの作成、 TFS 2010の使用経験:(制御システム 。ブランチ。作成およびその階層のオプションの1つについて書きました。 このパートでは、制御システムとの作業をより詳細に拡張し、ブランチおよびCheckInポリシーのコードへのアクセスを制御する手段に焦点を当てます。



ブランチ内のアクションにアクセス許可を設定する



そのため、次のステップでは、ブランチへのアクセス権を設定し、コードが常に高品質になるように特定のアクションを禁止します。 ClearCase UCMにはそのような可能性はありません。たとえば、ファイルがチェックアウトにある場合は配信しない(サイトブランチまたは統合ブランチにマージする)、ブランチからのマージを禁止するなどの権限設定のみがあります。開発者から別の開発者のスレッドへ。 ただし、これらの設定はすべてすべてのユーザーに適用されます。 もちろん、システム管理者は異なる権限を持つ複数のグループを作成できますが、そのような設定はサーバー側でのみ使用でき、前述したように、システム管理者はこれを行うことができません。

TFS2010では、ブランチへのアクセス権を個別に構成することができます。たとえば、インテグレーターに統合ブランチとサイトブランチでMergeを許可することができますが、開発者は禁止する必要があります。

そして、プロジェクト管理者はこれを行うことができます(たとえば、プロジェクトリーダーやプロジェクトマネージャー)。 権利を設定するためのすべての可能なオプションについては説明しません。 たとえば、開発者がサイトブランチおよび別のブランチで変更を加えることを禁止し、自分のブランチでのみ作業する可能性の1つだけを示します。

そのため、すべての変更は、単一のアクセスポイント(インテグレーター)を介してサイトブランチにマージされます。インテグレーターは、コードの品質を担当します。 これを行うには、Integratorsユーザーグループを作成し、統合ブランチとサイトブランチでいくつかの操作を実行できるようにし、他のすべてのユーザーがこれらの操作を行うことを禁止しました(図1および図2を参照)。

画像

図1-サイトおよび統合ブランチに対するインテグレーターの権利



画像

図2-サイトおよび統合ブランチに対する開発者の権利



また、開発者とインテグレーターが他の人のブランチを登って変更することを禁止する必要があります。たとえば、インテグレーターがTrollik開発者ブランチに変更を加えることを禁止しました。図3を参照し、コードだけを見る権利を彼に残しました。 画像

図3-開発者ブランチのインテグレーター権限



当然、lamerokとTrollikの開発者自身が、ブランチへのフルアクセス権を付与する必要があります。 私は欲しいものを手に入れました、今はルールに従うシステムがあります:

  1. 他の人のブランチのコードを変更することはできません
  2. サイトおよび統合ブランチのコードを変更する権限を持つのはインテグレーターのみです
  3. 誰でも任意のブランチからコードを読むことができます




チェックインポリシー



そのため、開発者はサイトのブランチ自体に変更をマージすること、およびブランチにないコードを変更することを禁止しました。 ここで、低品質のコードのチェックインを防止する必要があります。

この操作は既にワークフロー管理セクションを参照しており、制御システム自体に関連する必要がないため、ClearCaseにはこのような機会はありませんが、TFSは統合システムであるため、ここで実行できます。

自分のブランチでも、開発者は品質標準に準拠したコードを持っていることを常に確認する必要があります。 ただし、設定を行う前に、空のプロジェクトを追加して、作業ができるようにします。

その後、チェックインポリシーを構成できます。 これを行うには、チームエクスプローラーでプロジェクトをクリックし、マウスを右クリックして、[チームプロジェクトの設定とソース管理]を選択します(図4を参照)。 画像

図4-チェックインポリシー設定の選択



4つのオプションから選択する機会が与えられます。



もちろん、コードの品質が非常に心配なので、すべてを選択します。図5を参照してください。 画像

図5-チェックインポリシー



BuildおよびCodeAnalysisポリシーを順番に追加します。 コード分​​析については、Microsoftが推奨する最小限のものを選択します。私は獣ではありません。開発者には少なくとも創造性のためのスペースが必要です。図6を参照してください。 画像

図6-CheckInコード分析ポリシー



次のステップ-テストポリシーを追加する必要があります。ここでは、状況はもう少し複雑です。 現在、テストのリストはありません。 作成する必要があります。 まず、ファイルMyClass.csに追加します。 これはプロジェクトにあります。数値が0より大きい場合はtrueを返し、それ以外の場合はfalseを返す簡単なメソッドです(図7を参照)。

画像

図7-メソッドクラスMyClass



その後、MyMethodメソッドのテストを作成し、このテストをテストのリストに追加できます。 これを行うには、ソリューションにテストプロジェクトを追加する必要があります。ソリューションの上に立って、[追加]-> [新しいプロジェクト]-> [プロジェクトのテスト]メニューを右クリックしてください。 この操作の後、テストファイルが表示され、ソリューションの項目リストにテストの設定が表示されますが、ファイルには単一のテストまたはテストリストが含まれていません。テストをまだ作成していないため、テストプロジェクトが作成されたため、右を使用して簡単にこれを行うことができますマウスをメソッドの上に立って、図8を参照してください。

画像

図8-単体テストの作成



単体テストは自動的に行われ、デフォルトでは失敗します。 さらに、このユニットテストはテストファイルTestSolution.vsmdi-> All Loaded Testsにあります。 ただし、各チェックイン操作の前に実行されるテストのリストを作成する必要があります。 ソリューションでTestSolution.vsmdiファイルをクリックして、このようなリストを作成します。 TestForCheckInPoliticsと呼び、ユニットテストをこのリストに移動します(図9を参照)。 画像

図9-CheckInポリシーのテストのリストを作成する



テストのリストができたので、制御下で追加する必要があります。 これを行うには、テストファイル(TestSolution.vsmdi)を確認します。 その後、ポリシーに追加できます。 これを行うには、図5に示すウィンドウでテストポリシーを選択し、CheckInポリシーのテストファイルとテストのリストを指定します。図10を参照してください。 画像

図10-CheckInポリシーのテストリストの選択



さらに、開発者が割り当て時にのみコードを変更することを確実にするために、最後のポリシー-CheckInをワークアイテムにリンクすることも確立します。

CheckInポリシーが構成された後、コードのチェックを試みます。 図11からわかるように、完全な大失敗に見舞われました。 画像

図11-チェックインポリシーが機能した



すべての政治家が一度に働いた、我々は一貫して状況を修正しようとします。

最初に、ソリューションプロジェクトのCodeAnalysisをオンにして、CheckInポリシー(Microsoftが推奨する最小値)に設定したのと同じルールを設定します。次に、図12からわかるように、ビルドを行い、単体テストを実行し、ファイルを再度チェックしますテストが失敗し、ワークアイテムとの接続を示していないため、これを行うことはできません。 画像

図12-チェックインポリシー違反



単体テストに合格するように変更し、作業を作業項目に接続します(図13を参照)。

画像

図13-作業項目へのリンク



これでシステムがファイルをバックアップできるようになり、チーム全体が開発者ブランチに問題なくビルドされたコードが常に含まれ、すべての単体テストに合格したため、システムの残りの部分の作業に影響を与えないことを確認しました。

[ポリシーの上書き]チェックボックスをオンにすることでポリシーをバイパスできますが、この場合は理由を記入する必要があり、プロジェクトマネージャーまたはリーダーは違反を説明する悪意のある手紙を受け取ります。

このようなプロセスは、チームが不正な変更を繰り返し行うのを繰り返してきました。 当初は、すべてが急いで行われていましたが、チームはそれに慣れ、開発されたソフトウェアのエラーがはるかに少なかったため、チームは少し遅かったです。 一般に、チーム開発、およびTFSバージョン管理システムの変更の交換は、別の投稿の別のトピックです...

便利なリンク:

Visual Studio Team Foundation Serverを使用したチーム開発:リファレンス



All Articles