Опишите рабочий процесс использования системы управления версиями (VCS или DVCS) [закрыто]


Я хотел бы изучить рабочий процесс других людей при использовании vcs или dvcs.

пожалуйста, опишите свою стратегию для решения следующих задач:

  • реализовать функцию
  • исправление ошибок (во время разработки и развертывания приложения)
  • Просмотр Кода
  • код рефакторинга (post code-review)
  • включить патчи
  • выпуск новой версии вашего приложения (desktop, web, mobile, вы бы их лечили по-другому?)

Не стесняйтесь организовывать свой ответ, не сгруппированный по задачам, но сгруппированный по тому, что вы считаете актуальным, но, пожалуйста, организуйте его по VCS/DVCS (пожалуйста, не смешивайте их).

спасибо.

2   51   2010-04-24 19:31:34

2 ответа:

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

но быть VCS имеет два основных влияния на ветвление:

  1. он имеет тенденцию препятствовать фиксации, потому что один раз файл фиксируется, он сразу же влияет на рабочее пространство других представлений с той же конфигурацией (т. е. "работает на той же ветке").
    ~ Процесс "публикации" является активным, с немедленными последствиями,
    ~ в то время как" потребляющая " часть (обновление вашего рабочего пространства) является пассивной (вы вынуждены иметь дело с изменениями, опубликованными другими сразу после обновления вашего рабочего пространства)
  2. он хорошо работает для линейныйслияние рабочий процесс (т. е. "только слияние из ветви A в ветвь B, а не смешивание сливается в обоих направлениях" - A-B - A-B...). Слияния тривиальны, все модификации от A просто переносятся на B

теперь:

реализация функции

любой VCS сделает это, сделав ветку, но что меня очень удивило, так это то, что ветка" feature " нелегка:
* функция может стать слишком сложной
* он может быть готов вовремя для следующего выпуска
* только некоторая его часть может быть объединена обратно в основную ветку разработки
* это может зависеть от других функций, которые еще не полностью выполнены

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

исправление ошибок

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

Просмотр Кода

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

код рефакторинга (post code-review)

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

включить патчи

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

выпуск новой версии вашего приложения

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

  • мешает то, что в настоящее время работает
  • копирование новых файлов
  • развертывание их (обновление базы данных sql, Арр, ...)
  • создание экземпляра всех конфигурационных файлов (с правильными значениями, адресами, номерами портов, путями,...)
  • перезапуск (и если ваша система состоит из нескольких компонентов, перезапуск их в правильном порядке!)

ключевые вещи с VCS и управлением выпуском являются:

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

механизм выпуска также оказывает влияние на бинарные зависимости:

  • для внешних двоичных зависимостей вы, вероятно, будете использовать такие механизмы, как maven, чтобы получить фиксированные ревизии внешних библиотеки
  • но для внутренних зависимостей, когда вы разрабатываете не только одно приложение, но и несколько, которые зависят друг от друга, вам нужно знать, как ссылаться на двоичные файлы, созданные другими приложениями (внутренние двоичные зависимости), и они обычно не будут храниться в вашем VCS (особенно на этапе разработки, где вы можете создать много различных выпусков для других приложений, чтобы иметь возможность использовать)

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

основное отличие с A DVCS (распределенный контроль версий) от VCS, заключается в том, что он сделан (по самой природе своей распределенной работы), чтобы сделать одну вещь, и одну вещь хорошо:

слияние.

таким образом, вы задачи, которые вы упоминаете, можно рассматривать под этим углом.
Ветки все равно будут сделаны, но не все они будут видны другим разработчикам. Многие из них на самом деле не оставят ваш local хранилище.

будучи DVCS имеет два основных влияния на слияние:

  1. вы совершаете столько раз, сколько вы хотите. Эти коммиты не сразу видны другим (т. е. "им не придется объединять их сразу после следующего обновления своего рабочего пространства")
    ~ the публикации является пассивным: ваши толчки могут быть проигнорированы другими РЕПО.
    ~ "потребляющая" часть является активной: вы можете изучить то, что было подтолкнуто к вам раньше объедините это с вашей веткой и решите, что вы хотите объединить и от кого (а не только потому, что вы все работаете над "той же веткой").
  2. он хорошо работает для любого рабочего процесса слияния (частичный, перекрестный, рекурсивный,...) В DAG (направленный ациклический граф) часто используется для записи истории этих DVCS (по крайней мере, Git и Mercurial) позволяет легко найти то, что уже было объединено, и найти общего предка. Это один важно разница между SVN и его аналогами DVCS, а есть другие.

теперь:

реализовать функцию

Как я подробно в моем CVCS (Центральный VCS) ответ, сложность ветви "функция" заключается в том, что многие подфункции будут в конечном итоге переплетены.
Именно здесь DVCS будет сиять, поскольку они позволят вам реорганизовать свою локальную (как в "еще не нажатой") историю (наборы изменений для Mercurial, SHA1 совершает ofr Git), чтобы облегчить частичное слияние или создание ветвей подфункций.

исправление ошибок

вы можете почти создать ветку на исправление ошибок, если хотите. Идея состоит в том, чтобы убедиться, что исправление ошибки идентифицируется простым линейным набором коммитов, Объединенных обратно в ветку разработки (или ветку обслуживания, если это выпущено).
Я предпочитаю сначала сделать ребаз ветвь исправления ошибок в верхней части ветви разработки (чтобы сделать конечно, мои исправления по-прежнему совместимы с любой работой, которая могла быть выполнена параллельно на указанной основной ветке), перед объединением этой ветви dev с исправлением ошибок (быстрое слияние: основная ветвь теперь ссылается на все исправления)

Просмотр Кода

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

способ DVCS организовать обзор кода заключается в том, чтобы подтолкнуть новые изменения к специальному РЕПО обзора кода, которое будет:

  • отклонить эти коммиты, если они не отвечают требуемым критериям качества
  • примите их (объедините их с РЕПО code-review) и переместите их в новое РЕПО (например, для различных тестов)

код рефакторинга (post код-обзор)

они выполняются на локальном РЕПО разработчика, в ветке (так как это так легко объединить его обратно)

включить патчи

тот же процесс, что и в предыдущем разделе.

выпуск новой версии вашего приложения (desktop, web, mobile, вы бы относились к ним по-другому?)

фактический процесс выпуска просто инициируется специальной идентифицированной (теговой) версией вашего программного обеспечения. (остальная часть " процесса управления выпуском", то есть часть развертывания и конфигурации подробно описана в CVCS ответ)
Вопрос в том, с DVCS:
"из какого хранилища будет получена эта официальная версия вашего программного обеспечения?"

нужно создать "центральный" или скорее "официальный" репозиторий, который будет играть роль:

  • РЕПО для версий, которые будут выпущены
  • РЕПО для новых репозиториев хотел внести свой вклад

Так что он может служат оба для целей освобождения, но и для новых целей развития.