Когда делать проверки кода при непрерывной интеграции?

33

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

Таким образом, вопрос в том, когда мы делаем обзоры кода?

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

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


источник
Когда дело доходит до проверок / толчков, у большинства мест есть одно главное правило: не ломайте сборку! Т.е. не регистрируйте то, что не будет построено. Кроме этого, в большинстве мест, где я хотел получать небольшие и ограниченные чекины, но никогда не говорил ничего о сумме.
Какой-то программист чувак
но когда происходит проверка кода, прежде чем вы вернетесь, или когда вы закончите с этой функцией? Означает ли это, что у вас есть проверенный код, который вы проверяли, и исправляете ли вы проблемы, обнаруженные после проверки?
Это варьируется, но в большинстве мест требуется выполнить проверку кода в частных ветвях, прежде чем объединить их с одной из основных ветвей,
Некоторые программисты чувак

Ответы:

12

ИМО, вам следует просмотреть код до того, как он будет опубликован в магистрали, чтобы магистраль всегда имела код самого высокого качества.

OTOH, можно сказать, что «зачем беспокоиться о проверке, если автоматизация тестирования CI на нем не запускается?», Поэтому, возможно, лучше всего дать разработчикам каждую частную ветвь, которую сервер CI создаст и протестирует для них. , Таким образом, они сначала фиксируют и проталкивают туда, затем, когда он проходит, проверяют его, затем объединяются с основной линией (где он будет еще раз проходить через CI-сервер).

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

Также обратите внимание, что проверки кода не должны быть медленными или синхронными - такой инструмент, как gerrit или reviewboard или тому подобное, может сделать их асинхронными и довольно безболезненными.

(Полное раскрытие: я работал на SmartBear, создателей Code Collaborator, инструмента для проверки кода)

pjz
источник
4
Codereview-by-email - плохая практика (хотя лучше, чем ничего, по общему признанию), потому что трудно сказать, когда обзор «сделан». Получите реальный инструмент для проверки кода, такой как gerrit или reviewboard, и используйте его и прекратите рассылать патчи по электронной почте :)
pjz
1
Тем не менее, я не думаю, что это идеальный процесс, независимо от DVCS или нет. Одна из необходимостей проверки кода - не просто посмотреть на код, но на самом деле запустить код или автоматически протестировать код и посмотреть, что произойдет. Вы не можете сделать это только с помощью серии различий.
Иордания
2
+1 за предложение о проведении проверок после запуска автоматизированных тестов.
Уильям Пейн
1
Джордан: реальные инструменты просмотра кода (gerrit и т. Д.) Предоставляют больше, чем просто различия - они позволяют вам читать весь контекст, чтобы вы могли понять, на что действительно влияет изменение кода. В случае необходимости вы можете, да, скачать патч и собрать его, но, поскольку в любом случае все проходит через CI, предполагается, что ошибки, которые могут быть обнаружены автоматизацией, будут, поэтому больше внимания уделяется удобству обслуживания и крайним случаям, чем автоматизации или случайное тестирование может не заразиться.
pjz
1
Разве одна из точек CI не синхронизируется рано и часто с магистралью? Ваш подход задержит синхронизацию, которая имеет многочисленные недостатки.
Джейкоб Р.
11

Настроить парное программирование?

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

Стефан
источник
7

Вот выдержка из непрерывной доставки автора:

Джез Хамбл пишет как:

В настоящее время я пишу сообщение в блоге на эту тему. Краткий ответ таков:

  • Лучший способ просмотреть код через парное программирование
  • Это плохая идея - объединить основной канал - например, создав отдельную ветвь - в официальном процессе проверки. Это препятствует непрерывной интеграции (лучший способ снизить риск плохих изменений, чего вы действительно хотите достичь).
  • Я думаю, что Gerrit - хороший инструмент, но его нужно использовать после регистрации (так оно и есть). Часть работы старших разработчиков заключается в проверке всех проверок. Они могут, например, подписаться на канал.

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

Создание слияния с основной строкой в ​​формальном обзоре - это плохо, а создание веток для этого - очень плохо, по той же причине, что ветки объектов плохие.

Благодарность,

Еж.

Исходная ссылка: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ.

Alagesan Palani
источник
5

Я не знаю, является ли это лучшим способом сделать это ... но я объясню, как мы это делаем. Один или несколько разработчиков работают над данной веткой и фиксируют свой код так часто, как могут, чтобы не тратить время на слияние, которое не произошло бы в противном случае. Только когда код готов, он передается в голову. Теперь это для коммитов и веток / головок.

Что касается обзора кода, мы используем Sonar в качестве нашего инструмента непрерывной интеграции (и Maven / Jenkins для взаимодействия с Sonar), чтобы предоставлять нам свежие результаты тестов, покрытие кода и автоматический анализ кода каждое утро (сборки выполняются ночью), чтобы мы могли разработчики могут тратить максимум один час каждое утро, чтобы исправить свои проблемы / запахи кода. Каждый разработчик берет на себя ответственность (тоже гордясь!) За функцию, которую он пишет. Теперь это автоматический анализ кода, который отлично подходит для выявления потенциальных технических / архитектурных проблем, но что более важно, это проверить, правильно ли выполняют эти новые реализованные функции то, что от них хочет бизнес.

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

Таким образом, у нас есть два обзора кода, один автоматический и один «человеческий», и мы стараемся избегать добавления непросмотренного кода в ветку HEAD. Сейчас ... Это иногда случается по разным причинам, мы далеки от совершенства, но мы стараемся поддерживать справедливый баланс между качеством и стоимостью (время!)

@pjz также дает хороший ответ и упоминает инструменты проверки кода. Я никогда не использовал их, поэтому ничего не могу сказать по этому поводу ... хотя в прошлом у меня был соблазн работать с Crucible, так как мы уже используем JIRA .

Jalayn
источник
Интересная идея, что обзоры должны быть запланированы на определенное время / день ...
Уильям Пейн
@WilliamPayne спасибо. Еще одна вещь, которая нам подходит, - это планирование встреч по проверке кода, чтобы в календаре было ясно, что мы «заняты». Это помогает предупредить людей, что, хотя мы здесь ... мы на самом деле нет :-)
Jalayn
4

Я думаю, что основная концепция, которая поможет, это концепция «Постановки».

Да, вы не хотите проверять код, который не работает. Но вы также должны часто проверять код. Означает ли это совершенство? ;) Нет. Просто используйте несколько областей и DVCS, как Git.
Таким образом, вы вносите изменения (локально) и часто фиксируете их во время тестирования и разработки, пока тесты не пройдут. Затем вы нажимаете на промежуточную область для просмотра кода.

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

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

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

Майкл Даррант
источник
3

Разъедините обзор кода и непрерывную интеграцию!

Почему вы их объединили?

Николай Фоминых
источник
2

Мы используем git flow для наших репозиториев и проводим обзоры кода, когда дело доходит до слияния с ветвью разработки.

Все, что находится в разработке, полно, развернуто и проверено кодом.

У нас также есть CI, настроенный для наших ветвей разработки и мастерства.

sevenseacat
источник
2

Я действительно, действительно, действительно думаю, что вам понадобится DVCS (например, Mercurial, Git), чтобы сделать это естественно. С CVCS вам понадобится ветвь и надежда на то, что у вашего бога нет адского слияния.

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

Первый способ сделать это, особенно если у вас нет программного обеспечения для управления репозиториями, которое может помочь в публикации личных репозиториев (например, bitbucket, github, rhodecode), - это иметь роли иерархической интеграции. На следующих диаграммах лейтенанты могут просматривать работу разработчиков и назначать диктатора основным интегратором, который проверяет, как лейтенанты объединили работу.

введите описание изображения здесь

Другой способ сделать это, если у вас есть программное обеспечение для управления репозиторием, это использовать рабочий процесс, подобный следующему:

введите описание изображения здесь

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

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

PS: кредит на изображения перейдите на git-scm.com

dukeofgaming
источник
1
Люди в github используют запросы на выборку для проверки кода, и, по словам Скотта Чакона , Зака Холмена и других, это работает хорошо .
Спойк
1

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

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

Уильям Пейн
источник
1

Означает ли это, что мы должны проверять код, когда функция завершена, но этот непросмотренный код попадет в хранилище?

Намного выше я видел, как это было сделано по крайней мере в трех проектах, в которых интенсивно использовалась непрерывная интеграция, и, насколько я помню, это работало как шарм. Эта практика известна как обзоры кода после фиксации - ищите в Интернете этот термин, если вас интересуют подробности.

  • С другой стороны, единственный случай, когда я был в проекте, пытаясь «жениться» на предварительных проверках кода с CI, оказался довольно болезненным. Хорошо, когда все прошло гладко на 100%, все было в порядке - но даже редкие перерывы (например, когда основной и резервный обозреватели были недоступны, скажем, в течение нескольких часов) создавали заметный стресс. Я также заметил, что моральный дух команды несколько пострадал - было слишком много конфликтов.
комар
источник
-2

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

Непрерывная интеграция популярна в процессе экстремального программирования. Разработка, основанная на тестировании, добавляет парное программирование, которое фактически является частью процесса проверки кода, что делает непрерывную интеграцию простой в реализации. Само по себе Extreme Programming представляет собой непрерывный процесс проверки и интеграции кода. Обзоры кода существуют везде.

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

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

Учиться каждый день
источник