В прошлом я использовал репозитории 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.