プロジェクトフォルダーをどのように整理しますか？[閉まっている]

こんにちは

プロジェクトフォルダをどのように整理していますか？

かつて私は、顧客別に組織することを勧めてくれる上司がいました。

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

私の友人はテクノロジーでテムを整理するように私に言った

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

あなたも？プロジェクトフォルダーを整理する賢い方法はありますか？

これは私たちが使用してきたものです：

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

私たちはこの構造を何年もの間、多くの異なる顧客との複数のプロジェクトに使用してきましたが、非常にうまく機能しています。

最初の提案と非常に似ていますが、バージョン管理を使用してバージョン管理を管理しています。サーバーリポジトリは、他の名前ではなく「Customer X-Project Y」という名前になります。これにより、一部のプロジェクトで外部の請負業者が作業できるようになりますが、バージョン管理ルートで権限を設定できるため、他のプロジェクトにはアクセスできません。

全員が（Windows）開発マシンのどこにでも作業コピーをチェックアウトし、SUBSTコマンドを使用してドライブ文字をその場所にマップします。そうすることで、ビルドファイルなどにハードコード化された相対パスを含めることができます。これは、すべてのユーザーのセットアップで機能します。そのため、たとえば、必要に応じて共有ライブラリへのリンクを作成できます。通常、バージョン管理リンク/エイリアスを使用してこのトーを実現します。

この構造の大きな利点の1つは、顧客のコードを相互に分離できることです。これは、（a）統合のためにソースの定期的な更新を送信する必要がある場合、（b）コードの選択した部分で作業する外部の請負業者がいる場合に便利です。

2つ目の提案は、複数のテクノロジーを使用する複雑なプロジェクトではうまく機能しません。

私はかなりフラットです：

/プロジェクト

ボックスによってはそこに到達するいくつかのバリエーションがありますが、その背後にはプロジェクト用の個々のフォルダーがたくさんあります。とにかく本物の取引はソース管理に住んでいるので、これは単なる一時的な地元の家です。

私は大まかに次のように見える構造を持っています：

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives作業していない古いプロジェクトが含まれています。Work仕事関連のプロジェクトが含まれています。Currentすべての現在の開発です。次に、ホームディレクトリで、にシンボリックリンクProjectsし~/Developer/Projects/Currentます。~/Projectsいくつかの作業プロジェクトへのシンボリックリンクも含まれています。

私も平らな構造をしています。

/プロジェクト

ワイアット・バーネットに同意すると、とにかくソース管理は本物です。

多くのIDEがとにかく最近のプロジェクト/ファイルへのショートカットを提供するため、とにかくフォルダー構造について特別なことはないはずです。とにかく誰がいくつのプロジェクトに取り組んでいますか？本当に、定義によってのみ、最近のものです。

また、とにかく最近のプロジェクトをトップレベルのフォルダーに追加するだけです。古いものや完成したものをすべて次の場所にアーカイブします。

/ Projects / Old_stuff

またはそのようなもの。私が一般的に二度と取り組んでいないものをアーカイブします。

過去に、Subversionリポジトリを使用してソースドキュメントを保存し、リポジトリ組織の「プロジェクトマイナー」規則に従いました。これは、大小の組織の両方で非常にうまく機能することがわかりました。

リポジトリブランチを構築します。次のようなタグとトランク：

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

実際のソースツリー内では、次のような構造（のようなもの）を使用します。

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

アイデアは、リポジトリの構造を使用してエンジニアリングチーム間のコミュニケーションの構造化を支援することでした（現在もそうです）。ビジネスの顧客対応部分およびその他のさまざまな利害関係者とドメインの専門家。

言い方をすれば、「プロジェクト」ディレクトリの1つにあるソースドキュメントは、一度しか使用されません（そしてお金を稼ぎます）。「productLines」ディレクトリの1つにあるドキュメントは、その特定のラインの製品が販売されるたびにお金を稼ぎます。「ライブラリ」ディレクトリの1つにあるドキュメントは、それを使用する製品が販売されるたびにお金を稼ぎます。

これにより、コストの償却という概念が明確になり、ビジネス全体でソースドキュメントの再利用のサポートを構築できます。

理想的な世界では、ビジネスの一部に直面している顧客もこの構造を使用してプレゼンテーションやその他の販売資料を保存するため、開発者は関連する製品ディレクトリと並んで作成された顧客の期待を確認でき、顧客に直面している同僚は開発を追跡できます販売している機能と製品の進歩。

また、ビルド自動化ツールが動作できる共通の構造があることも意味します。（私たちのビルドスクリプトは、各コンポーネントのビルド方法を指定する構成ファイルを見つける「ビルド」フォルダーを探してソースツリーを歩きます。ドキュメントの生成とテストでも同様のプロセスが発生します）。繰り返しますが、理想的な世界では、組織のWebサイトやその他のマーケティング資料を同じ方法で構築できます。

最後のメモとして。継続的インテグレーションシステムは、ビルドをトリガーする必要があることを知っています。静的分析; トランクが変更されるたびに、「タグ」ブランチが変更されるたびに、および「自動」ブランチブランチが変更されるたびに、煙テストと単体テストが実行されます。このようにして、個々の開発者は個人システムで重要な機能であるIMHOでCIシステムを使用できます。

あなたは「ドキュメントフォルダ」を意味すると思います。私は最初にセクター向けに文書を整理し、顧客/アプリケーション用に、最後に「開発と保守」用に整理します。

例：プロジェクト

• 財務

  • ウェブアプリケーション

    • アプリアルファ

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • アプリベータ

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • デスクトップソフトウェア
• エネルギーとユーティリティ
• BLA BLA