私は今までスタンドアロンの単一システムとしてアプリケーションを開発しています。今、私は自分の作業領域を一元化し、それをチームとして開発する必要があります... Visual Studio 2008 および SQL Server 2005 のチーム環境をセットアップする方法に関する素晴らしいヒント。私は TFS には興味がありません。前もって感謝します ...
3 に答える
VisualSVN は非常に良い選択です。これは Windows で動作し、非常に信頼性が高く、さまざまなリポジトリやフォルダーへのアクセス許可を持つユーザーを設定できます。Visual Studioとシームレスに連携できるようにしました。
自分で作業するときにソース管理を使用していないことを暗示していますか? 私はそれに対してお勧めします。プロジェクトの唯一の開発者であっても、常にソース管理を使用してください。
それとは別に、ソース管理に Gitを使用するという@IanNortonの推奨事項に2番目に同意します。Mercurialも良い選択肢ですが、あまり人気はありません。 Subversionも良い選択肢です。これらはすべて、非常によく似たシェル統合 Windows クライアントを持っています。
また、継続的インテグレーション ビルドにはTeamCityのようなものをお勧めします。理想的には、自動化されたビルドとテスト ランナーがチェックインのたびに実行されるようにして、コードに問題があるかどうかをすぐに確認できるようにする必要があります。 -テストデータの構築)。
私は TFS には興味がありません。
愚かな-特に、TFSを使用することがあなたにとって良い理由を明らかにしたからです。
これをはっきりさせましょう - TFS はあなたにとって重要な 2 つのことを行います:
- ソース管理。
- 計画を含む WORK 項目の追跡 (そしてまもなく 2011 年には SCRUM が完全にサポートされます)
- 継続的な統合。大きくなったら、項目 4 を追加します。
- テスト。すべてを継続的に実行できるわけではなく、TFS は Visual Studio で手動テスト計画などをサポートしています。
「私は TFS が好きではない」と言っているほとんどの人は、TFS が実際にもたらすものについて無知であることと同じです。すべてが完璧だと言っているわけではありませんが、TFS を使用しないことが私たちが下した最悪の愚かな決定である 18 か月のプロジェクトを終了したところです ;)
それらすべてを適切に保護する必要があります-優れた方法論(いいえ、申し訳ありませんが、ソース管理システムだけでは不十分です)、継続的な統合、およびプロジェクトを計画してタスクを割り当てるシステム。
データベースでは事態が複雑になります。SQL 2012 にアップグレードすることを強くお勧めします。新しい localdb モードは、継続的な統合には無価値です。
ところで、私の最後のプロジェクトでは、SVN の問題との戦いで数週間を失いました (ほとんどの場合、愚かなサーバーが間違ったバージョンを最新のものとして配信しました - そして、私たちは悪いバージョンを元に戻すために本当の戦いをしました ;)
環境は次のようになります。
- 仮想マシンをプルアップできる多数のサーバー。開発者はそれらのいくつかを必要とする場合があります。
- ビルド サーバーは SSD が大好きであることを忘れないでください - パフォーマンスのために ;)