1

SOに関するFARの投稿を読みすぎて、分析麻痺に陥っています!

私は Visual Studio 2010 を使用しており、多くの小さなプロジェクトがあり、その多くはライブラリ/共有プロジェクトを参照しています。

共有コードに変更を加えた場合、依存プロジェクトをチェック/再構築する必要があることはあまり気にしません...これを支援するために、できるだけ早く TeamCity を配置しますが、今のところ、コードを修正するだけです次回はプロジェクトに取り組みます。多くのプロジェクトは「一度書いたら忘れる」ものなので、更新する必要はありません。

チームは現時点では非常に小さいですが (ME!)、今年初めに新しい開発者が期待されていますが、それでも非常に小さな社内チームであり、それが違いを生む場合はプロジェクト サイクルが速くなります。

現時点では、ディスク上に非常にフラットなフォルダー構造があるため、すべてのslnファイルはディスク上の「開発」フォルダーにあります。次に、VS プロジェクトごとにフォルダーがあります。これにより、共有が非常に簡単になりpackages、nuget.

database scriptsすべてを SVN (VisualSVN) にインポートしようとしています。 、docs、UAT testsなどの追加を開始したいと思います。

  • フラットな構造を維持し、ルート レベルで単一のトランク/ブランチ/タグを使用する必要がありますか?
  • 構造を に展開してan SVN folder-per-solution を持ちtrunk/src、trunk/docsのようなものを管理nuget packagesしsvn:eternalsますか?
  • 私はこれをハイブリッドにan SVN folder-per-solutionしdocsて、VS ソリューションを使用しますか?

注: 私は SVN を入れているので、Java 開発を持ち込むことができますが、ソース コードは単一の方法で管理できます。docs/sql sripts などをそこに入れたい DB チームとも共有します。DB と Java のそれぞれに個別のリポジトリを作成する予定ですが、それぞれに「同様の」フォルダ構造が必要です。

注 2: SVN のユーザー経験はありますが、管理者の経験はありません。新しい開発者はまったく経験がないので (彼らは AS/400 のバックグラウンドから来ています)、ソリューションが単純であればあるほど良いのです! 私は見てきましたがrepo per project and svn:extenals、それは素晴らしい解決策ですが、常に管理と保守を行う必要があります (自分の仕事だけでなく! 笑)

「そこに行って、GTTSをやった」という人からのアドバイスは非常にありがたいものです。

OK、次のローカル ソリューション構造ができました。

すべての sln/suo ファイルが同じフォルダーにあります。
私のプロジェクト フォルダ/ファイルはすべてサブフォルダです。

これにより、プロジェクトの共有が非常に簡単になります...しかし、非常に面倒で、何かを見つけるのは難しいです:(

「参照」プロジェクトを管理するために svn:externals を使用する必要があるので、それらを分岐/タグ付けできますか?
ビルドされた DLL のみを参照する必要がありますか? また、それを実行するために必要なすべての管理を参照する必要がありますか?
VS2010 に自分のフォルダーを管理させて、たくさんの "nuget" フォルダーなどがあることを気にしないでください。

非常に非常に混乱しています...適切な答えはありますか？:(

注: CI 機能を提供するために、できるだけ早く TeamCity (または類似のもの) をミックスに追加します。CI に関する深刻な (そして無料の) 推奨事項も高く評価されています。

4

1 に答える 1

1

これは、私が仕事や個人的なプロジェクトで使用する構造です。

SVN 構造:

  • 根
    • 共有コード
    • 製品A
      • トランク
        • branch_of_shared_code
        • productA プロジェクト
        • 製品ソリューション
      • 枝
        • 支店1
          • branch_of_shared_code
          • productA プロジェクト
          • 製品ソリューション
      • タグ
        • ...
    • 製品B
      • ...

定期的に (ニーズに正確に依存する場合)、共有コードのメイン ブランチからのすべての変更は、共有コードの製品のブランチにマージされます。共有コードへの変更は、製品のブランチで行われてから再びマージされるか、メイン ブランチで行われてから製品にマージされます。

製品ソースの内容:

完全なパッケージを構築するために必要なものはすべてソースと見なされます。たとえば、DB スクリプトがある場合、それらはソースの一部です。テストも。ドキュメントについては、通常、ドキュメントを構築するためのすべてのソースを含む別のプロジェクトをソリューションに追加し、出力ディレクトリに結果を生成します。次に、インストーラーを作成するプロジェクトは、生成された配布物にそれを含めます。

企画：

これには議論の余地があるかもしれませんが、私はタスク リストをソースの隣に保存し、それらをブランチ/マージすることを好みます。タスクがブランチで完了した場合、マージされるまでトランクでは完了しません。より一般的な計画は、ソースの隣に保管するのに適している場合とそうでない場合があります。

ディスク上:

まず第一に、すべての製品の作業コピーを保存するのではなく、オンデマンドでチェックアウトできるような方法でリポジトリを操作することを信じています。もちろん、変更ごとに作業コピーをチェックアウト/削除するのは現実的ではないため、現時点で頻繁に作業しているすべての製品のディレクトリがあり、その中に作業中のブランチ (トランクなど) をチェックアウトします。残りの製品は、すぐに開発される予定がない場合はチェックアウトする必要はありません。

于 2013-02-13T12:12:01.357 に答える