Зафиксировать раннюю фиксацию часто с помощью обзоров кодов?

Ответ 1

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

Ниже приведена иллюстрация для всей итерации:

И очень короткое объяснение:

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

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

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

Ответ 2

Все существующие ответы предлагают распределенный SCM. Этого достаточно, но не обязательно. До существования Distributed SCM все еще можно было это сделать.

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

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

Только объединить обработанные кодом ветки обратно в основную ветвь.

Распределенные системы SCM имеют много преимуществ, и я не хочу звучать так, как будто я против них, но если вы не используете их, то нет оправдания не использовать ветки для каждого разработчика.

Ответ 3

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

Git и Mercurial (hg) являются хорошими примерами распределенных SCM

Ответ 4

Во-первых, какое программное обеспечение для контроля версий вы используете?

В зависимости от вашего программного обеспечения RCS вы можете одновременно достичь обеих целей. Например, если вы используете Subversion, каждый разработчик может совершать ранние и часто собственные ветки разработки. Экспертные оценки могут потребоваться до того, как любые ветки развития будут объединены в багажник. Другие системы RCS могут, скорее всего, сделать что-то подобное.

Изменить: Я забыл упомянуть, что если вы действительно используете стратегию "совершить раннюю и часто" с Subversion (с или без ветвей разработки), разработчикам необходимо убедиться, что они update их рабочая копия с изменениями, переданными на туловище, одинаково часто. Эта проблема возникла у моей команды некоторое время после того, как мы перешли из VSS в Subversion. Мы не привыкли к 3-сторонним слияниям, и разработчики редко обновляли свою рабочую копию (иногда менее двух раз в день), что обычно требовало значительного количества ручного слияния. В конце концов все привыкли запускать svn update всякий раз, когда делается фиксация (у нас есть крюк после фиксации, который обновляет RSS-канал с новыми коммитами) или, как минимум, каждый час или около того. В результате большая часть слияния обрабатывается автоматически, и количество ручной работы, требуемой для слияния ветки разработки, возвращается обратно в туловище, как правило, тривиально. Это также связывает diff между магистралью и ветвью развития как можно меньше, что упрощает обзор кода (так как мы обычно фокусируемся на diff между ветвью и туловищем при просмотре кода).

Ответ 5

Используйте систему управления распределенной версией. Один из самых больших недостатков централизованного контроля версий заключается в том, что он мешает "совершать ранние действия, совершать часто". Распределенные системы поощряют его.

Ответ 6

Вы должны взглянуть на этот Google TechTalks от Linus Torvalds: http://www.youtube.com/watch?v=4XpnKHJAok8

Линус объясняет, почему Distributed SCM (например, Git или Hg) снижает психологический барьер для совершения, тем самым позволяет разработчикам "совершать ранние, фиксировать часто" (используя ветки, благодаря так просто в git).

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

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

Просто скажи что-то вроде "Это не я, это Линус говорит это!", это должно многое помочь:)

Ответ 7

Не могу прокомментировать, так что стратегия с разными уровнями ветвей (ответ Паскаля) велик. Однако я думаю, что одна вещь, которую вы хотели бы прояснить, - это то, что "commit" равно "release". Это не должно.

То, что мы делали с одной командой на проект, заключалось в том, что разработчики фиксируют, когда готовы, однако фиксация не должна прерывать модульные тесты жёсткости (аналогично политике с "проверкой единиц измерения" в рабочем процессе из превосходного ответа Pascal). У нас есть тестовый сервер, который работает прямо из репозитория и обновляется после каждой фиксации (мы делаем веб-приложения - это равносильно созданию вашей программы каждый фиксатор или каждый день). Каждый может получить доступ к этому серверу, включая PO и заинтересованные стороны - фактически любой желающий может играть с ним и предоставлять обратную связь.

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

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

Что касается обзоров кода, требующих времени - хорошо, это время хорошо потрачено, время инвестировано в более высокое качество продукта. Ну стоит того.

Ответ 8

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

Pair-программирование обеспечивает то же значение, что и просмотр кода, позволяет отлично передавать знания и помогает начинающим программистам (а иногда и опытным программистам!) быстро учиться. Конечно, это приносит свои собственные проблемы... ни один из них не может быть непреодолимым.

Ответ 9

Используйте ветвление.

Пример:

Devs работают над своей веткой на ветке функций. Просмотрите изменения при объединении с веткой развития магистрали. Слияние в ветвях dev с ветвью освобождения при выпуске релизов.

Ответ 10

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

Не уверен, что это будет работать с вашей обзорной доской, но что-то, что вы, возможно, захотите рассмотреть.