Компоновка SVN — лучшая практика
-
16-09-2019 - |
Вопрос
В CVS у нас есть проект с несколькими каталогами.Существует ночная сборка, которая должна извлекать данные из разных каталогов одного и того же проекта CVS, чтобы построить ночную сборку.Так что мне следует иметь это в виду, и мне придется изменить сценарий сборки, чтобы проверять данные из разных репозиториев, если мы перейдем на SVN.
Я прочитал соответствующий SVN QA, но у меня есть собственный вопрос, на который мне нужен ответ.
Я могу сделать:
/trunk
/tags
/branches
/3rdparty
Где все, что мы разрабатываем, исходит из /trunk, а все сторонние приложения, которые мы не меняем, попадают в /3rdparty.
Все хорошо, теперь сценарий ночной сборки должен пометить транк, извлечь тег, извлечь необходимые сторонние материалы в соответствующие каталоги, а затем запустить процесс сборки.
Результат сборки (скомпилированный материал) может оставаться на монтировании NFS в течение некоторого времени, поэтому команда интеграции может вернуться на 2 недели назад и воссоздать проблемы.
Все ли мои базы покрыты?
Решение
Красная книга SVN здесь включает много информации о макетах для различных типов проектов и о том, как ими управлять.
Вы также можете использовать перехватчики/триггеры/внешние устройства для получения данных из независимого репозитория под названием «3rd party».Таким образом, когда разработчик получает один репозиторий, он получает и третью часть.Существует множество способов разделить задачи, но представить единое репо из компонентов.
Удачи
Другие советы
Возможно, стоит использовать механизм сборки, например Гудзон или круиз-контроль.Рабочий процесс немного другой — теги создаются после сборки, но вы можете получить дополнительные модули, которые дадут вам некоторый контроль над этим.Дело в том, что вся работа по разработке выполняется за вас, и вы получаете достойную структуру для своих ночных сборок, а также хороший веб-интерфейс для управления и мониторинга всего.
Лично я бы поместил некоторые внешние определения в магистраль, чтобы подключить соответствующие сторонние библиотеки в соответствующие места.Таким образом, когда вы меняете версию сторонней библиотеки, вы вносите изменения в магистраль и вам не нужно изменять сценарии сборки.Это также означает, что вы можете создавать более старые версии, просто проверив соответствующий транк/тег/ветвь.Будьте осторожны — делайте это только на багажнике, разбрасывание их вокруг может привести к убийству.
Я бы также разместил репо примерно так:
project
/trunk
/branches
/tags
3rdparty
Просто потому, что это дает вам больше возможностей для добавления большего количества проектов верхнего уровня в какой-то момент.Это позволяет вам управлять разными проектами совершенно независимо - и вы по-прежнему можете использовать внешние ссылки для ссылки на правильные версии от одного к другому, если есть зависимости - это прекрасно останавливает изменения в одном проекте, незаметно разрушая/изменяя зависимые проекты.
Это можно сделать и с использованием отдельных репозиториев, и это нормально, но в этом случае я бы с самого начала поместил отдельный раздел стороннего репозитория в отдельный репозиторий.
Почему бы вам не переместить стороннее устройство в багажник?когда каждый ваш филиал копия сторонней компании попадает в филиал.И, очевидно, вы не будете менять сторонние материалы в ветке, потому что ваша ветка написана на основе существующих сторонних материалов.
Я не уверен, стоит ли отмечать то, о чем вы говорите.Вы имеете в виду номер версии?Если это номер версии, передайте его через скрипт и отметьте build.
Если «несколько каталогов» представляют собой отдельные компоненты, версии которых вы хотите создавать независимо, вам следует иметь каждый из них в отдельном репозитории, чтобы их можно было помечать отдельно.Но если это все один самостоятельный проект (т.если вы обычно будете размечать и разветвлять все компоненты вместе), то вы, вероятно, сможете поместить весь код в один и тот же репозиторий.
Вам следует рассмотреть возможность использования внешние факторы для сторонних артефактов.
Мой сценарий проверяет магистраль, изменяет файлы (корректирует номера версий в файлах AssemblyInfo.cs и т. д.), а затем помечает их.Если вам не нужно каким-либо образом изменять файлы, то сначала пометить тегами тоже будет хорошо.
В остальном, по крайней мере, мне ваша установка кажется хорошей.