Опишите ваш рабочий процесс использования контроля версий (VCS или DVCS)
Я хотел бы изучить рабочий процесс других людей при использовании vcs или dvcs.
Пожалуйста, опишите вашу стратегию для решения следующих задач:
- Реализовать функцию
- Исправление ошибок (при разработке и развертывании приложения)
- Обзор кода
- Рефакторинг кода (пост-код-обзор)
- Включить патчи
- Выпуская более новую версию вашего приложения (для ПК, для Интернета, для мобильных устройств, вы бы по-другому относились к ним?)
Не стесняйтесь организовать свой ответ, не сгруппированный по задачам, а сгруппированный по тому, что вы считаете уместным, но, пожалуйста, организуйте его по VCS/DVCS (пожалуйста, не смешивайте их).
Спасибо.
2 ответа
Главная особенность, которую все VCS используют для различных задач, о которых вы упоминаете, - это ветвление: способность изолировать усилия по разработке в духе совместной работы. Поскольку это центральная VCS, несколько разработчиков могут сотрудничать в одной ветви с пессимистической или оптимистической блокировкой файлов для разработки параллельной истории.
Но будучи VCS имеет два основных влияния на ветвление:
- Это имеет тенденцию препятствовать фиксации, поскольку после фиксации файла он сразу же влияет на рабочую область других представлений с той же конфигурацией (то есть "работает в той же ветке").
~ Процесс "публикации" является активным, с немедленными последствиями,
~ в то время как "потребляющая" часть (обновление вашего рабочего пространства) является пассивной (вы вынуждены иметь дело с изменениями, опубликованными другими сразу же после обновления вашего рабочего пространства) - Это хорошо работает для линейного рабочего процесса слияния (т. Е. "Только слияние из ветви A в ветвь B, не смешивая слияния в обоих направлениях" - от A до B до A до B...). Слияния тривиальны, все модификации из A просто переносятся в B
Сейчас:
Реализация функции
Любая VCS сделает это, создав ветку, но что меня очень удивило, так это то, что ветвь "функции" не легка:
* функция может стать слишком сложной
* это может быть готово к следующему выпуску
* только некоторая его часть может быть объединена с основной веткой разработки
* это может зависеть от других функций, которые еще не полностью выполнены
Поэтому вам нужно быть осторожным в том, как вы управляете своей веткой функций и своими коммитами: если они тесно связаны с одной и той же функцией, все будет хорошо (вы объединяете все это с вашей основной веткой разработки, когда вам это нужно), В противном случае частичное объединение с этими инструментами будет непростым.
Исправление ошибок
Разница между исправлением ошибок во время разработки и после выпуска заключается в том, что в первом случае вы часто можете делать это линейно в одной и той же ветке, так как в последнем случае вам придется создать ветку с исправлением ошибок и решить, какие ошибки вы будете делать необходимо перенести в вашу текущую ветку разработки.
Обзор кода
Лучше всего использовать его с внешними инструментами ( например, Crucible) и широко использовать такие функции VCS, как обвинение или аннотации, чтобы лучше назначать исправления кода после проверки.
Рефакторинг кода (пост-код-обзор)
Если рефакторинг незначительный, он может продолжаться в той же ветке. Но если он большой, необходимо настроить специальную ветвь с модульным тестированием перед началом указанного рефакторинга.
Включить патчи
Тот же комментарий, что и последний пункт. Если патч большой, нужно создать ветку.
Выпуск новой версии вашего приложения
VCS только поможет вам выпустить ваше приложение, потому что это не инструмент управления выпуском.
Вам нужно будет предварительно определить версию, которую нужно выпустить (метку), но после этого начинается процесс развертывания, который включает в себя:
- остановить то, что в данный момент работает
- копирование новых файлов
- их развертывание (обновление базы данных sql, webapp, ...)
- создание всех конфигурационных файлов (с правильными значениями, адресами, номером порта, путями,...)
- перезапуск (и если ваша система состоит из нескольких компонентов, перезапустите их в правильном порядке!)
Ключевые вещи с VCS и управлением выпуском:
- они не очень хорошо приспособлены для хранения исполняемых двоичных файлов, а это значит, что они нужны вам для создания вашего приложения, а не для хранения получившегося исполняемого файла
- они не всегда приветствуются в производственной среде (где ограничения безопасности ограничивают доступ для записи, а также количество инструментов, работающих на этих платформах, в основном инструменты мониторинга и отчетности)
Механизм релиза также влияет на бинарные зависимости:
- для внешних бинарных зависимостей вы, вероятно, будете использовать такие механизмы, как maven, чтобы получить исправленные ревизии внешних библиотек
- но для внутренних зависимостей, когда вы разрабатываете не одно приложение, а несколько, которые зависят одно от другого, вам необходимо знать, как ссылаться на двоичные файлы, создаваемые другими приложениями (внутренние двоичные зависимости), и они обычно не сохраняются в вашей VCS (особенно на этапе разработки, где вы можете создавать множество различных выпусков для других ваших приложений)
Вы также можете выбрать зависимость от источника (и получить все источники других внутренних проектов, которые вам нужны), и VCS хорошо приспособлена для этого, но не всегда возможно / практично перекомпилировать все.
Основное отличие DVCS (Distributed Control Version) от VCS заключается в том, что он сделан (по самой природе своей распределенной работы) для выполнения одной вещи и одной хорошей вещи:
объединить
Таким образом, вы можете рассмотреть задачи, которые вы упоминаете, с этой точки зрения.
Ветви все равно будут сделаны, но не все они будут видны другим разработчикам. Многие из них не покинут ваш локальный репозиторий.
Быть DVCS имеет два основных влияния на слияние:
- Вы делаете столько раз, сколько хотите. Эти коммиты не сразу видны другим (т. Е. "Им не нужно будет объединять их сразу после следующего обновления их рабочего пространства")
Процесс публикации пассивен: ваши репозитории могут игнорировать ваши действия.
~ "потребляющая" часть является активной: вы можете изучить то, что было передано вам, прежде чем объединить это с вашей веткой, и решить, что и с кем вы хотите объединить (и не только потому, что вы все работаете над тем же самым). ветка"). - он хорошо работает для любого рабочего процесса слияния (частичный, перекрестный, рекурсивный, ...) DAG (направленный ациклический граф), часто используемый для записи истории этими DVCS (по крайней мере, Git и Mercurial), позволяет легко найти то, что имеет уже слились и нашли общего предка. Это одно важное различие между SVN и его аналогами DVCS, но есть и другие.
Сейчас:
Реализовать функцию
Как я подробно описал в своем ответе CVCS (Central VCS), трудность, стоящая за ветвью " Feature ", заключается в том, что многие подфункции в конечном итоге переплетаются.
Именно здесь DVCS будет сиять, поскольку позволит вам реорганизовать их локальную (как в "еще не отправлено") историю (наборы изменений для Mercurial, SHA1 фиксирует ofr Git), чтобы упростить частичное слияние или создание ветвей подфункции.
Исправление ошибок
Вы можете почти создать ветку за исправление ошибки, если хотите. Идея состоит в том, чтобы убедиться, что исправление ошибки идентифицируется простым линейным набором коммитов, слитых обратно в ветку разработки (или ветку обслуживания, если она выпущена).
Я предпочитаю убедиться, что сначала перебазировал ветку исправления ошибок поверх ветки разработки (чтобы убедиться, что мои исправления по-прежнему совместимы с любой работой, которая могла быть выполнена параллельно в указанной основной ветке), прежде чем объединять эту ветку dev с одна исправленная ошибка (слияние ускоренной перемотки вперед: теперь основная ветка ссылается на все исправления)
Обзор кода
Функция вины или аннотации все еще существует, чтобы помочь назначить задачи во время проверки кода, но на этот раз все разработчики не обязательно находятся на одном сайте (так как это *Distributed *VCS), а не с той же схемой идентификации (например, не использует тот же LDAP).
DVCS способ организовать проверку кода - это внести новые изменения в специальное хранилище с проверкой кода, которое будет:
- отклонить эти коммиты, если они не отвечают требуемым критериям качества
- принять их (объединить их с репозиторием с проверкой кода) и перенести их в новый репозиторий (например, используемый для различных испытаний)
Рефакторинг кода (пост-код-обзор)
Они выполняются в локальном репо разработчика, в ветке (поскольку его легко объединить)
Включить патчи
Тот же процесс, что и в предыдущем разделе.
Выпуская более новую версию вашего приложения (для ПК, для Интернета, для мобильных устройств, вы бы по-другому относились к ним?)
Фактический процесс выпуска просто инициируется специальной идентифицированной (теговой) версией вашего программного обеспечения. (остальная часть "процесса управления выпусками ", то есть часть развертывания и настройки, подробно описана в ответе CVCS)
Вопрос с DVCS:
"Из какого репозитория придет официальная версия вашего программного обеспечения?"
Вам необходимо создать "центральное" или, скорее, "официальное" хранилище, которое будет играть роль:
- репо для версий, которые будут выпущены
- репо для новых репозиториев хотел внести свой вклад
Таким образом, он может служить как для целей выпуска, так и для новых целей разработки.