Как вы организовываете папки ваших проектов? [закрыто]

Добрый день

Я хотел бы знать, как вы, ребята, организовываете папки вашего проекта?

У меня когда-то был начальник, который предлагал мне организовать клиентов.

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

Мой друг сказал мне, чтобы организовать Tem по технологии

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

Мы уже несколько лет используем эту структуру для множества проектов с множеством разных клиентов, и она работает очень хорошо.

Это очень похоже на ваше первоначальное предложение, но мы используем контроль версий для управления версиями. Серверные хранилища именуются как «Клиент X - Проект Y», а не как-либо еще. Это позволяет нам иметь внешних подрядчиков, работающих над одними проектами, но не имеющих доступа к другим, поскольку мы можем устанавливать разрешения в корне управления версиями.

Каждый проверяет свои рабочие копии в любом месте на своем (Windows) компьютере разработчика и использует команду SUBST для сопоставления буквы диска с этим местоположением. Таким образом, мы можем иметь жестко запрограммированные относительные пути в файлах сборки и т. Д., Которые работают в любой конфигурации. Так, например, у нас могут быть ссылки на общие библиотеки, если мы того пожелаем. Мы обычно используем ссылки / псевдонимы контроля версий для достижения этой цели.

Одним из больших преимуществ этой структуры является то, что вы можете изолировать код клиентов друг от друга. Это полезно, если вам нужно (а) отправлять им регулярные обновления исходного кода для целей интеграции, (б) привлекать внешних подрядчиков, работающих над отдельными частями кода.

Ваше второе предложение не будет так хорошо работать со сложным проектом, в котором используется более одной технологии.

Я довольно плоский

/ Проекты

По-разному, в зависимости от коробки, возникает некоторая вариация, но за этим стоит множество отдельных папок для проектов. В любом случае, реальная сделка заключается в контроле над источниками, так что это всего лишь временный местный дом.

У меня есть структура, которая выглядит примерно так:

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

Archivesсодержит старые проекты, над которыми я больше не работаю. Workсодержит связанные с работой проекты. Currentэто все текущие разработки. Затем в моем домашнем каталоге я имею ссылку Projectsна ~/Developer/Projects/Current. ~/Projectsтакже содержит символические ссылки на некоторые рабочие проекты.

У меня также есть плоская структура.

/ Проекты

Соглашаясь с Уайеттом Барнеттом, реальная сделка все равно живет в системе контроля версий.

Просто хочу добавить, что в структуре папок не должно быть ничего особенного, так как многие IDE в любом случае предоставляют ярлыки для последних проектов / файлов. А над какими проектами кто-нибудь работает? Действительно, только по определению, последние.

Кроме того, я в любом случае добавляю только последние проекты в папку верхнего уровня. Я архивирую все старые и законченные вещи в:

/ Проекты / Old_stuff

или что-то типа того. Я архивирую то, над чем я вообще больше не буду работать.

В прошлом я использовал репозитории Subversion для хранения своих исходных документов и следовал соглашению «Project-minor» для организации репозитория, которое, как я обнаружил, очень хорошо работает как для крупных, так и для небольших организаций.

Мы бы структурировали наши ветви репозитория; теги и багажник следующим образом:

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

Идея состояла в том, чтобы (и все еще остается) использовать структуру хранилища, чтобы помочь структурировать взаимодействие между командой разработчиков; ориентированная на клиента часть бизнеса и различные другие заинтересованные стороны и эксперты в данной области.

То есть: исходные документы, которые находятся в одном из каталогов «проекта», используются (и зарабатывают деньги) только один раз. Документы, которые находятся в одном из каталогов «productLines», зарабатывают столько раз, сколько продается продукт из этой конкретной линии. Документы, которые находятся в одном из «библиотечных» каталогов, зарабатывают столько раз, сколько продается любой из продуктов, которые их используют.

Это делает понятие амортизации затрат явным и помогает обеспечить поддержку повторного использования исходного документа в рамках всего бизнеса.

В идеальном мире клиентская часть бизнеса также будет использовать эту структуру для хранения презентаций и другого обеспечения продаж, чтобы разработчики могли видеть, какие ожидания клиентов были созданы, рядом с соответствующим каталогом продуктов, а коллеги, работающие с клиентами, могут отслеживать развитие. прогресс на функции и продукты, которые они продают.

Это также означает, что существует общая структура, над которой могут работать наши инструменты автоматизации сборки. (Наши сценарии компоновки обходят дерево исходных текстов в поисках папок «компоновки», в которых они находят файлы конфигурации, определяющие, как должен создаваться каждый компонент; аналогичный процесс происходит для генерации и тестирования документации). Опять же, в идеальном мире веб-сайт организации и другие маркетинговые материалы могут создаваться таким же образом.

В качестве одного последнего замечания; система непрерывной интеграции знает, что она должна инициировать сборку; статический анализ; Тест дыма и модульный тест запускаются каждый раз, когда ствол изменяется, каждый раз, когда изменяется любая ветка «tag», и каждый раз, когда изменяется любая ветка «AUTOMATED». Таким образом, отдельные разработчики могут использовать систему CI со своими персональными ветвями, что является важной возможностью, IMHO.

Я думаю, что вы имеете в виду «папка документации». Я сначала организую свои документы для сектора, потом для клиента / приложения, а в конце - для «разработки и сопровождения».

Пример: проекты

• финансовый

  • веб приложение

    • Приложение Альфа

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

    • App Beta

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

  • Настольное программное обеспечение
• Энергетика и коммунальные услуги
• БЛА БЛА