Як ви організовуєте папки своїх проектів? [зачинено]

Доброго дня

Мені хотілося б знати, як ви організовуєте папки свого проекту?

Я колись мав начальника, який пропонує мені організувати Замовниками.

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

Ми використовуємо цю структуру для багатьох проектів з багатьма різними клієнтами вже багато років, і вона працює дуже добре.

Це дуже схоже на вашу первинну пропозицію, але ми використовуємо контроль версій для управління версією. Репозиторії серверів названі як "Клієнт X - Проект Y", а не що-небудь інше. Це дозволяє нам мати зовнішніх підрядників, які працюють над одними проектами, але не мають доступу до інших, оскільки ми можемо встановити дозволи в корені управління версіями.

Усі перевіряють свої робочі копії куди хочуть на своєму (Windows) верстаті розробників та використовують команду SUBST для того, щоб позначити букву диска до цього місця. Таким чином, ми можемо мати жорстко закодовані відносні шляхи у файлах збірки тощо, які працюють у всіх налаштуваннях. Так, наприклад, ми можемо мати посилання на спільні бібліотеки, якщо цього хочемо. Зазвичай ми використовуємо посилання / псевдоніми управління версіями для досягнення цього завдання.

Одним з великих переваг цієї структури є те, що ви можете ізолювати код клієнтів один від одного. Це корисно, якщо вам потрібно (а) надсилати їм регулярні оновлення джерела для цілей інтеграції; (b) мати зовнішніх підрядників, які працюють над обраними частинами коду.

Ваша друга пропозиція не буде настільки добре працювати зі складним проектом, який використовує більше однієї технології.

Я досить плоский:

/ Проекти

Деякі варації потрапляють залежно від коробки, але позаду цього є просто багато індивідуальних папок для проектів. Справжня угода живе в контролі джерел, так що це лише тимчасовий місцевий дім.

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

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

Archivesмістить старі проекти, над якими я більше не працюю. Workмістить проекти, пов'язані з роботою. Currentце все сучасне розвиток. Потім у своєму домашньому каталозі я посилаюсь Projectsна ~/Developer/Projects/Current. ~/Projectsтакож включає посилання на деякі робочі проекти.

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

/ Проекти

Погоджуючись з Wyatt Barnett, у будь-якому разі реальна угода живе в контролі джерел.

Просто хочу додати, що в структурі папок так чи інакше не повинно бути нічого особливого, оскільки багато IDE так чи інакше надають ярлики до останніх проектів / файлів. І скільки проектів хто-небудь працює? Воістину, лише за визначенням, останні.

Також я лише додаю останні проекти в папку верхнього рівня. Я архівую всі старі та завершені матеріали в:

/ Проекти / 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

Ідея полягала в (і досі є) використати структуру сховища, щоб сприяти структуруванню зв'язку між інженерною командою; частина бізнесу, що стоїть перед клієнтами, та різні інші зацікавлені сторони та експерти в галузі.

На доцільність: вихідні документи, які розміщуються в одному з каталогів "проекту", використовуються (і заробляють гроші) лише один раз. Документи, що знаходяться в одному з каталогів "productLines", заробляють гроші стільки ж разів, скільки продається продукт з цього конкретного рядка. Документи, що знаходяться в одному з каталогів "бібліотек", заробляють гроші стільки разів, скільки продаються будь-які продукти, які ними користуються.

Це робить поняття амортизації витрат явним і допомагає розбудувати підтримку повторного використання вихідних документів у бізнесі.

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

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

Як одна фінальна примітка; система безперервної інтеграції знає, що їй потрібно викликати збірку; статичний аналіз; тест на дим і тестовий запуск блоку кожного разу, коли змінюється ствол, кожен раз, коли будь-яка гілка "тегів" змінюється, і кожен раз, коли будь-яка гілка "АВТОМАТИЧНА" гілка. Таким чином, окремі розробники можуть використовувати систему CI зі своїми персональними відділеннями, важливою здатністю, IMHO.

Я думаю, що ви маєте на увазі "папку документації". Я організовую свої документи для сектору спочатку, потім для клієнта / заявки, наприкінці для "розробки та обслуговування".

Приклад: Проекти

• Фінансові

  • Веб-додаток

    • Додаток Альфа

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

    • Бета-версія додатка

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

  • Настільне програмне забезпечення
• Енергетика та комунальні послуги
• BLA BLA