Структура Mercurial Repository с мощными корпоративными коммуникациями, управлением конфигурацией и требованиями к тестированию

Я - еще один пользователь Subversion, пытающийся переучиться на Дао распределенного контроля версий.

Когда я использовал 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
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

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

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

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

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

Важно отметить, что для продуктов, над которыми я работаю, обычно требуется ДЛИННОЕ время для проведения тестов измерения и характеристики производительности; от 20 до 200 часов; генерирование от нескольких ГБ до нескольких ТБ обработанных результатов испытаний / промежуточных данных (которые должны храниться и привязываться к конкретной конфигурации системы, чтобы можно было измерить улучшение производительности во времени). Эта проблема делает управление конфигурацией важным фактором, а также предъявляет некоторые требования к централизации, поскольку обычно вычислительные ресурсы, необходимые для выполнения измерений производительности и тестов характеристик, ограничены; (небольшой кластер из 64-128 ядер).

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

Теперь мой вопрос: как я могу воспроизвести все вышеперечисленное (и улучшить его, если это возможно) с Mercurial.

--редактировать:

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

Ответ Споя превосходен, но я думаю, что стоит добавить несколько вещей, которые слишком велики для комментариев.

Филиальная организация

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

Если вам bespokeProjectTwoнужна специальная версия chartingбиблиотеки, то вы должны перейти charting, добавить новые средства и использовать ее в bespokeProjectTwo. Новые средства (и их ошибки) не будут использоваться другими проектами, которые будут ссылаться на стандартную chartingбиблиотеку. Если в основной chartingбиблиотеке исправлены ошибки, вы можете объединить эти изменения в ветке. Если другие проекты также нуждались в этих средствах, вы можете либо заставить эти проекты использовать специальную ветку, либо объединить ветку в основную линию и закрыть ветку.

Кроме того, ничто не мешает вам иметь политику структурирования имен веток для предоставления определенных средств, таких как ветки AUTOMATION.

Справочная организация

Нет никаких причин, по которым вы не можете хранить исходный каталог в точности так же, как в Mercurial. Единственное отличие состоит в том, что тогда как в Subversion у вас есть один монолитный (src)репозиторий, в Mercurial лучше разбить на репозитории, которые логически сгруппированы. Из вашей исходной древовидной структуры я бы, вероятно, выделил каждое из следующих в качестве отдельных репозиториев:

src-+
      +-(developmentAutomation)
      +-libraries-+
      |           +-(log)
      |           +-(statistics)
      |           +-(charting)
      |           +-(distributedComputing)
      |           +-(widgets)
      +-productLines-+
      |              +-(flagshipProduct)
      |              +-(coolNewProduct)
      +-project-+
                +-bigImportantCustomer-+
                |                      +-(bespokeProjectOne)
                |                      +-(bespokeProjectTwo)
                +-anotherImportantCustomer-+
                                           +-(anotherBespokeProject)

Это позволяет любому продукту или заказному проекту использовать любую комбинацию библиотек в любой редакции. Посмотрите на mercurial sub-repositories для простого способа управлять тем, какие библиотеки используются для любой данной версии продукта или проекта.

Workflow

Альтернативой предлагаемому рабочему процессу Spoike (разработчик извлекает данные из благословенного репо, работает локально, выдает запрос на извлечение и, наконец, интегратор извлекает эти изменения и объединяет их) было бы использование системы непрерывной интеграции в качестве посредника.

Как и прежде, разработчик извлекает из благословенного репо и работает локально, но когда он закончил, он снова извлекает из благословенного репо и объединяется, прежде чем перейти в необъявленное репо. Любые изменения в неподтвержденном репо затем проверяются (либо вручную, либо автоматически) и перемещаются в благословенное репо, только если они одобрены.

Это означает, что интегратор должен только принять или отклонить изменение, но не выполнять слияние. ^{По моему опыту, для разработчика, написавшего код, почти всегда лучше выполнить слияние, чем для кого-то другого.}

Как предлагается в ртутной книге, для автоматизации этой процедуры могут использоваться хуки :

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

Другие вопросы

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

Хорошо, пытаюсь ответить на это просто.

Что тебе нужно знать

Первое, что вам нужно знать: Mercurial - это распределенный контроль версий и обладает некоторыми свойствами, о которых вам следует знать, перечисленными ниже.

• Источник взят из одного репозитория, где этот репозиторий можно клонировать. Все клонированные репозитории могут обмениваться кодом друг с другом посредством синхронизации (с помощью команд pull и push, доступ к которым может быть ограничен).
• Каждый пользователь, имеющий копию кода, имеет клон репозитория. Если они хотят разветвляться, они могут сделать это в своем локальном клоне. Это означает, что вам не нужно организовывать, как каждый пользователь должен переходить. Они могут сделать это для себя.
• Теги создаются в Mercurial коммитом (что аналогично жестким тегам в git). Это означает, что вам не нужен каталог внутри структуры репозитория для тегов.

• Обычная модель, с которой люди работают в DVCS (которая используется в github и bitbucket), состоит в том, чтобы сделать это полуцентрализованным.

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

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

Настройка репозитория на проект

Таким образом, обычная настройка заключается в том, что для каждого проекта есть следующее:

• Публичный репозиторий только для чтения, за который отвечает интегратор. Это "благословенно".

  Т.е. все пользователи могут извлекать / извлекать контент, но не имеют доступа к нему.

• Каждый пользователь может иметь свой собственный общедоступный клон репозитория.

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

• Каждый пользователь может иметь свои собственные клоны хранилища.

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

Организация исходного кода

Что касается того, как организовать сам исходный код проекта - это то, что вам нужно продумать. Если артефакт должен контролироваться источником, поместите его в контроль источника. Лично мне не нравится идея проверять артефакты, создаваемые сборкой или средой выполнения (из-за высокого риска конфликтов слияния на этих типах артефактов), такие как двоичные файлы или файлы журналов.

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

Вы упоминаете, что у вас есть тестовые данные, которые необходимо привязать к какой-либо версии кода. Теперь это немного сложнее, потому что DVCS-системы, такие как Mercurial и Git, имеют тенденцию замедляться, когда вы регистрируете данные, которые ОГРОМНЫ. По моему опыту, это становится действительно невыносимым после 5 ГБ двоичных файлов (ваш milage может отличаться, поэтому вы должны проверить, как это работает для вас). Однако я бы порекомендовал вам поместить сгенерированные данные в его собственный репозиторий и попросить тестовую систему соответствующим образом пометить их при регистрации (и / или создать текстовые файлы для тех же целей метаданных).

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