Несколько хранилищ SVN или одно хранилище компании
Должен ли у нас быть один репозиторий для всей компании, который содержит много проектов разработки, или репозиторий для проекта? Есть идеи по опыту / лучшей практике?
12 ответов
Лично я бы определенно предпочел отдельный репозиторий для каждого проекта. Есть несколько причин:
Номера ревизий. Каждый репозиторий проекта будет иметь отдельную последовательность ревизий.
Зернистость С репозиторием на проект вы просто не сможете сделать коммит в разных проектах с одинаковым номером ревизии. Я предполагаю, что это скорее преимущество, а кто-то скажет, что это недостаток.
Размер хранилища. Насколько велик ваш проект? Есть ли у него двоичные файлы под контролем исходного кода? Бьюсь об заклад, это имеет. Следовательно, важен размер - каждая версия двоичного файла увеличивает размер хранилища. В конце концов это становится неуклюжим, и его трудно поддерживать. Должна поддерживаться детальная политика хранения двоичных файлов и дополнительное администрирование. Что касается меня, я все еще не могу найти, как я мог полностью удалить двоичный файл (переданный некоторым глупым пользователем) и историю его содержимого из хранилища. С репозиторием на проект было бы проще.
Организация внутреннего хранилища. Я предпочитаю мелкозернистые, очень организованные, автономные, структурированные репозитории. Существует диаграмма, иллюстрирующая общий (идеальный) подход процесса обслуживания хранилища. Я думаю, вы согласитесь с тем, что просто НЕВОЗМОЖНО использовать подход "все проекты в одном репо". Например, моя первоначальная структура репозитория (должна быть у каждого репозитория проекта):
/project /trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releasesАдминистрация репо. "Репозиторий на проект" имеет больше возможностей в настройке доступа пользователей. Это сложнее, хотя. Но есть и полезная функция: вы можете настроить репозитории для использования одного и того же файла конфигурации
Репо Поддержка. Я предпочитаю резервное копирование репозиториев отдельно. Кто-то говорит, что в этом случае невозможно объединить информацию из одного репо в другое. Зачем тебе это нужно? Случай, когда требуется такое слияние, показывает, что первоначальный подход к управлению исходным кодом неверен. Эволюция проекта предполагает последующее разделение проекта на подмодули, а не наоборот. И я знаю, что для этого есть подход.
SVN: внешние. Подход "Репозиторий на проект" поощряет использование SVN: Externals. Это нормальная ситуация, когда зависимости между проектом и подмодулями устанавливаются через программные ссылки, которыми является svn: externals.
Вывод Если вы хотите сохранить контроль над исходным кодом простым, используйте один репозиторий. Если вы хотите сделать управление конфигурацией программного обеспечения ПРАВО:
- Используйте подход "хранилище на проект"
- Ввести отдельную роль менеджера конфигурации программного обеспечения и назначить в него члена команды
- Наймите хорошего администратора, который справится со всеми трюками Subversion:)
PS. Между прочим, несмотря на то, что я все время работаю с SVN и мне это нравится, подход "репозиторий на проект" - вот почему я считаю системы DCVS более привлекательными с точки зрения организации репозитория. В DCVS репо это проект по умолчанию. Нет даже вопроса "один против множества", это было бы просто бессмыслицей.
Я обнаружил, что наличие единственного хранилища Subversion помогает в:
- Прозрачность: легче следить за тем, что происходит, и находить код даже в проектах, в которых вы, возможно, не участвуете напрямую.
- Обслуживание: нет необходимости создавать репозитории каждый раз, когда вы хотите создать новый проект, и вы можете удалять целые проекты, не опасаясь потерять запись из Subversion.
- Обслуживание: необходимо создать резервную копию только одного хранилища.
РЕДАКТИРОВАТЬ: Дополнительные причины:
- Глобальные идентификаторы ревизий - имея глобальные идентификаторы ревизий, это:
- Проще общаться (например, в запросе на проверку кода, просто укажите идентификатор редакции, без необходимости указывать, какой проект).
- Проще гарантировать атомарность, когда проекты зависят друг от друга.
- Проще увидеть порядок коммитов в разные проекты.
Я настоятельно рекомендую не использовать репозиторий для каждого проекта. В одном репозитории subversion вы можете перемещать и копировать данные, и они сохранят свою историю. Если вы решите, что какой-то фрагмент кода, который был запущен как бэкэнд-инструмент, объединяется с внешним интерфейсом, и они находятся в разных репозиториях, это не та операция, о которой Subversion будет знать ничего. Это будет как если бы вы добавили что-то в интерфейс из ниоткуда. Это также означает, что вы не можете выполнять слияния, если вам нужно временно поддерживать две версии связанного кода.
Вы заметите, что все примеры в книге svn предполагают, что все находится в одном репозитории.
Есть отдельный вопрос, использовать ли /trunk/project1, /trunk/project2, /branch /project1-r1 или использовать /project1/trunk, /project1/branch /r1, /project2/trunk. Как правило, второе легче отслеживать.
Лучшая причина не помещать все в один репозиторий состоит в том, что управление доступом трудно выполнить более детально, чем на уровне репозитория. Возможно, да, но не так просто. В настоящее время у нас есть два основных хранилища:
- SVN / код для всех программных разработок, требует Jira билет для фиксации
- svn / ops для любого конфига, настройка скриптов, сторонние тары, что угодно, jira не требуется
Это будет зависеть от того, насколько взаимозависимы ваши приложения / проекты в организации, а также насколько велики базы кода. Таким образом, все сводится к тому, как определить "проект" в вашей организации. Общая кодовая база, общие компоненты, общие команды, общие циклы выпуска могут влиять на структуру ваших репозиториев.
Для простоты я определяю проект как имеющий независимую кодовую базу, временную шкалу выпуска и / или принадлежность к одному инструменту / приложению. В этом случае я предпочитаю иметь один репозиторий на проект. Таким образом, вы получаете больше свободы для определения и реализации политик / ограничений доступа для каждого проекта.
Если бы у меня было одно хранилище, вздутое со временем... Мне также может понадобиться беспокоиться о времени проверки рабочего пространства и т. Д., Особенно если весь код проектов смешан. Если приложение / инструмент / проект завершено / отложено / устарело / перенесено, может быть больше контроля над аспектами администрирования, если существует разделение на уровне проекта.
Структурирование репозитория проекта на основе его уникальных потребностей также может быть проще, если для каждого проекта существует один репозиторий. Каждый проект может иметь определенные потребности, которые могут повлиять на политики управления конфигурациями (ветвление, тегирование, соглашения об именах, CI и т. Д. Включены), которым следуют для каждого проекта. Это не значит, что вы не можете выполнять всю эту работу с папками в одном репозитории. Вы можете. Просто проще иметь чистое разделение - вот и все.
Возможно, вы захотите учесть все эти факторы, чтобы оценить административные накладные расходы, с которыми вы можете столкнуться, в зависимости от вашей конкретной настройки.
Тем не менее, если все проекты имеют небольшой размер и являются взаимозависимыми, требующими перекрестных ссылок, перекрестного отслеживания, перемещения внутри друг друга и т. Д., То лучше использовать одно хранилище и одну папку на хранилище.
У меня был бы репозиторий для проекта, просто для того, чтобы номера ревизий были для каждого проекта. Вы можете настроить обслуживание SVN так, чтобы все проекты были доступны из одной точки доступа с использованием Apache и DAV SVN (с директивой SVNParentPath).
Пока очень хорошие, проницательные ответы, но я просто хочу добавить свои два цента:
Я думаю, что это зависит от размера вашего проекта. Мы испробовали оба подхода, но в итоге остановились на одном большом хранилище.
Минусы:
- Ветвление может быть сложным, так как может быть задействовано много папок и файлов.
- Хранилище может стать ОГРОМНЫМ
- Вы должны проверить весь репозиторий (или хотя бы отдельные ветки), чтобы создать свое решение.
- Немного меньше контроля над архитектурой проекта (см. Плюсы)
Плюсы:
- Все проекты имеют одинаковую историю хранилища
- Ветвление для всего хранилища
- Гораздо меньше администрирования (отдельные разработчики могут создавать новые проекты без помощи системного администратора)
- Лучший обзор и возможности мониторинга коммитов репозитория
ИМХО (и в отношении нашего конкретного проекта) плюсы перевесили минусы.
Решение может быть основано на сложности проекта. Если вы начинаете огромные усилия, которые будут отделены от всего остального, над чем вы будете работать, и над ним будет работать большая команда разработчиков, возможно, имеет смысл дать ему отдельное репо.
Для групп, работающих над несколькими небольшими проектами одновременно, один репозиторий предоставляет простой механизм для управления всем в одном месте (резервное копирование, поиск и т. Д.). Центральное хранилище также делает само хранилище более "конкретным", поскольку оно не будет удалено после завершения проекта или его отмены.
Все зависит от того, сколько у вас есть проектов, размер вашей организации, насколько связаны проекты, и так далее. Если вы являетесь частью большой команды с парой дюжин проектов, репозиторий для каждого проекта будет довольно громоздким для администрирования.
В зависимости от того, какую работу выполняет ваша организация, можно выбрать один репозиторий для каждого клиента. Там, где я работаю, в настоящее время у нас есть четыре репозитория: один для проектов, которые являются полностью внутренними для нас, один для программного обеспечения, которое мы продаем, и два, которые полностью специфичны для конкретных клиентов, для которых мы производим специальное программное обеспечение, применимое только для них. Это попытка найти "лучшее из двух миров" решение - у нас нет одного огромного хранилища, которое содержит все и имеет номер редакции в миллиардах (я, конечно, преувеличиваю!), Но при этом у нас нет десятков маленьких маленьких репозиториев. валяется с одним проектом в каждом.
Если вы используете Subversion, вы можете иметь несколько репозиториев в одном домене с несколькими проектами в каждом.
Так бы это выглядело так
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Project1 может адресовать интерфейсный код и содержит подпроекты, такие как admin/ и web/ Project2 будет backend и содержит различные инструменты и приложения для мониторинга
Если вы используете что-то вроде Git, каждый репозиторий должен быть отдельным проектом.
Для своей организации я пошел на полпути, создав несколько репозиториев для разных "областей" кодирования. Я заранее знал, что каждый репозиторий будет содержать проекты, которые будут достаточно отделены друг от друга.
Я работаю в компании, которая работает для многих клиентов со строгими правилами. На данный момент у нас около 130 разработчиков. У нас есть основной проект, который адаптирован к потребностям каждого клиента. И у нас есть одно огромное хранилище SVN. Было бы больно в заднице, если бы нам пришлось проверить всю ветку, но наша стратегия состоит в том, чтобы вывести проекты из общей ветки и оставить работу только для команд переключения.:) Таким образом, все можно хранить в одном хранилище.
Моей единственной заботой было разделение репозитория на несколько репозиториев, если это необходимо, в случае аутсорсинга части работы или продажи целого проекта до тех пор, пока я не нашел это: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories
Поэтому я думаю, что svn switch облегчает долгую проверку (один выключает только нужные проекты), но у нас может быть один репозиторий. Но, если все еще необходимо, можно извлечь набор компонентов в отдельный репозиторий.
Я сделал оба, и в обоих случаях я иногда хотел бы выбрать другой метод...
Я остановился на одном репозитории, это хорошее решение. Обратите внимание, что если бы я был в более крупной компании, я бы пересмотрел.