Управление подрядчиками с SVN по проектам - PullRequest
0 голосов
/ 28 ноября 2009

Что вы рекомендуете для использования SVN в качестве средства управления разработкой проекта с использованием удаленных / внешних разработчиков с точки зрения проверки кода / управления изменениями и т. Д.? Должны ли все регистрироваться в транке и давать комментарии ко всему или люди используют патчи, ветки или какой-то другой процесс для управления этим? Пожалуйста, предоставьте любые ваши предложения относительно того, чтобы небольшая группа удаленных разработчиков (5) отправляла работу в SVN, а также отдельное лицо, отвечающее за разработку проекта, которое рассматривает изменения кода и т. Д. Спасибо

Ответы [ 2 ]

2 голосов
/ 28 ноября 2009

Ответ на этот вопрос будет зависеть от:

  • Насколько вы доверяете подрядчикам?
  • Сколько усилий хочет ваша группа? положить в управление этим?

Вот несколько сценариев:

Нет доверия

  • Доступ к хранилищу только для чтения
  • Нет доступа к транку
  • Работы выполняются с патчами
  • Кто-то в вашей команде будет управлять патчи

Средний траст

  • Вехи чтения-записи
  • Подрядчики подчиняются вехе ветви.
  • Кто-то в вашей команде входит в ветку релиза

Полное доверие

  • Полный доступ к транку
  • Подрядчики, отвечающие за слияние их изменения

Что касается лучших практик, я предлагаю следующее:

  • Отслеживание этапов с выгорания диаграмма или система по вашему выбору
  • Заставьте всех комментировать (можно использовать хук Subversion для это)
  • Код Align фиксирует определенный товар / билет в системе управления как FogBugz, OnTime и т. д.
  • Большие элементы или этапы должны есть своя ветка. Слияние с багажником одна особенность / веха была подтверждено кем-то из вашей команды.

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

1 голос
/ 28 ноября 2009

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

Мы ближе к последнему. Вот наш процесс:

  • Для новой версии / функции значительного размера мы создаем отдельную ветку.
  • Разработчики могут проверить код - мы настаиваем на том, чтобы у каждого пользователя был комментарий.
  • Чтобы синхронизироваться со стволом, владелец ветки отвечает за слияние ствола со своей веткой
  • Когда функция / выпуск завершен, ветка проверяется кодом и объединяется обратно в транк
  • ветка удалена. Если работа над веткой должна продолжаться, ветка должна быть воссоздана - это связано с ограничениями SVN

Редактировать

Для уточнения:

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

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

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

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

После объединения ветка становится непригодной для использования и должна быть удалена.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...