Каковы эффективные методы управления владением программами в системах контроля версий?

Question

Используя SVN или Git, мне пришла в голову мысль использовать структуру каталогов в качестве заполнителя метаданных. Каждая команда будет иметь каталог в общем хранилище для своего кода. Чем больше я думаю об этом, тем хуже кажется эта идея. Причина, по которой мне это кажется плохой, заключается в том, что команды не являются статичными объектами. Команды могут исчезнуть, разделиться, рекомбинировать и даже получить новое имя. Я знаю, что смотрю на использование уникального идентификатора и, возможно, внешней базы данных. Я, вероятно, даже сталкиваюсь с репозиторием для каждой команды для надлежащего управления правами доступа. В ситуации с 200 или более командами лучше ли мне поддерживать владение внешней базой данных или есть какие-то инструменты и практики, из которых я мог бы поучиться?

Answer 1

Вот моя лучшая попытка указать вам правильные направления. Вообще говоря:

Организуйте свой исходный код в соответствии с компонентами вашей системы обычным способом. Убедитесь, что каждому компоненту можно настроить управление доступом независимо (например, в git, это означает, что отдельные репозитории для каждого компонента, как сказал Макис).

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

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

Если у вас нет компонентной архитектуры, централизованных учетных записей пользователей или контроля доступа для вашей VCS, то оставьте эту проблему, пока не исправите более важные.

Answer 2

Git не очень хорошо работает с правами доступа. Чтобы даже начать обрабатывать его, вам нужно использовать gitosis, а затем написать код в хиты git. У меня был вопрос относительно этого.

Тогда вам понадобится, как вы сказали, база данных для обработки информации о том, какой пользователь может получить доступ к какому-либо репозиторию. То есть вам нужно будет разбить материал на отдельные репозитории в git, так как вы не можете защитить отдельные файлы или каталоги в git. Я написал короткую заметку в блоге об этом некоторое время назад. Суперпроекты могут помочь в будущем, но эта концепция все еще находится в стадии разработки и не очень четко определена.

В более изящных (и дорогих) инструментах SCM, таких как Rational ClearCase, у вас есть для этого лучшие инструменты. Например, вы можете создавать компоненты и определять права пользователей для каждого компонента. К сожалению, даже эти инструменты требуют обширных обновлений вручную, если что-то сильно изменится. Но если права пользователей - это все, что вам нужно, было бы гораздо выгоднее написать свои собственные инструменты, чем покупать одного из этих монстров.

Answer 3

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

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

Answer 4

Если это отдельный проект, просто предоставьте ему собственный репозиторий.

Answer 5

ОК, так что, если я правильно понял ваш вопрос, то у вас есть
1. Несколько программ
2. Несколько команд, которые работают над исходным кодом
3. Необходимо отслеживать, какие команды работают над каким кодом

Вы не указываете, работает ли каждый раз только на одной программе или эта программа может работать совместно несколькими командами.

Я не пользователь GIT или SVN, мой основной опыт связан с производительностью, но я постараюсь изложить некоторые лучшие практики, которые должны работать для любой системы SCM крупного уровня предприятия

1. Иметь ветвь кода основной линии - это будет ваша «чистая» область.
2. Создать ветку песочницы для каждой команды
3. Использовать четкие соглашения об именах

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

Так что с точки зрения расположения хранилища, тогда что-то вроде этого

• код
  • магистральный
    • program1
    • program2
  • команда
    • teamA
      • program1
    • teamB
      • program2

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

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

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

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

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

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

Некоторые полезные ссылки в этой сложной области:)
Моделирование жизненного цикла программного обеспечения
Лучшие практики в SCM
SCM intro - репозитории
SCM интро - филиалы

Answer 6

Дайте каждой команде свой собственный репозиторий.

Answer 7

Метаданные, которые вы хотите сохранить, будут сохранять информацию, касающуюся файлов и членов команды, которые работали с ресурсами. Предполагая, что у вас есть зрелая семантика обработки ресурсов в вашем хранилище, например комментарии о регистрации и т. Д., Одной из стратегий может быть идентификация просматриваемых метаданных и их индексация с использованием некоторого инструмента индексирования / API. Существует множество информации, доступной из метаданных репозитория, которую можно извлечь и проиндексировать. Если вам нужен более точный контроль, вы можете использовать настраиваемые перехваты предварительной фиксации, чтобы заставить участников команды размещать необходимую информацию при регистрации. Хранилище метаданных, которое вы бы имели, дало бы хороший контроль для запросов / поиска пользователей и ресурсов. Индексация может выполняться скриптом ежедневно / еженедельно.

Answer 8

Читая ваш вопрос, у меня возникла идея, которая может быть полезна для вас (или нет, это просто внезапная идея, которая внезапно появилась в моей голове; -):

1. Как и в случае инструмента linux 'devtodo', вы можете создать файл в каждом каталоге для метаданных. (Для devtodo файл называется .todo)
2. Этот файл метаданных может быть файлом базы данных nosql , с членами команды в данный момент.
3. Этот файл метаданных может быть в контрольной версии.
4. Этот файл метаданных может быть объединен (как операция sql join) с другими файлами, то есть со всеми членами вашей команды.
5. Может быть задан набор сценариев или псевдонимов оболочки для более частого использования командной строки nosql.

В нескольких строках: связать файлы базы данных в вашем git или svn с вашими метаданными; и без серверов баз данных.