Непрерывная интеграция: какая частота?


20

Я всегда запускал сборки после каждого коммита, но в этом новом проекте архитекторы просто попросили меня изменить частоту на «одну сборку каждые 15 минут», и я просто не могу понять, почему это будет веской причиной против » опираясь на каждый коммит ".

Прежде всего, некоторые детали:

  • Проект Objective-C (iOS 5)
  • 10 разработчиков
  • каждая сборка на самом деле занимает ~ 1 мин и включает сборку и модульное тестирование.
  • Сервер интеграции - Mac Mini, поэтому вычислительная мощность здесь не является проблемой.
    • мы используем Jenkins с плагином XCode

Мои аргументы заключались в том, что если вы строите каждый коммит, вы можете прямо сейчас увидеть, что пошло не так, и исправить ошибки напрямую, не беспокоя других разработчиков. Плюс наш тестер менее обеспокоен ошибками UT таким образом. Его аргументы заключались в том, что разработчики будут наводнены сообщениями об ошибках сборки (что не совсем верно, поскольку Jenkins можно настроить на отправку почты только для первой прерванной сборки), и что показатели не могут быть выполнены должным образом, если частота из сборок слишком высока.

Итак, что вы думаете по этому поводу?


Вы уверены, что ваше время сборки составит ~ 1 мин за 2 или 3 месяца, когда 10 разработчиков будут постоянно добавлять больше кода, включая модульные тесты, в ваш проект?
Док Браун

Было бы интересно изучить аргументы архитекторов для запроса изменения; ваши очки хороши, но они решают актуальную проблему?

Ответы:


32

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

Построить на каждом коммите это правильно.

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

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


16
+1. Ответ на досадно частые сообщения «сбой сборки» состоит в том, чтобы не ломать сборку досадно часто.
Suszterpatt

3
В спокойное время - третий вариант Дженкинса, "Опрос SCM", предназначен именно для этого. Он будет обновлять / запускать тесты только при обнаружении изменений в хранилище. Например, у нас есть одно задание для запуска каждые 5 минут, если есть какие-либо изменения (модульные тесты), и второе задание для запуска каждые 3 часа, если есть какие-либо изменения (интеграционные тесты). Оба тихие ночью / выходные, потому что никто ничего не совершает.
Изката

5

Буквально нет смысла делать сборку каждые 15 минут, если ничего не изменилось. Но в равной степени нет и недостатка, афаик, Дженкинс будет только по электронной почте в случае неудачи и затем успеха, а не все между (например, 10 неудач).

Мы делаем это на каждом коммите. Однако мы проводим опрос каждые 15 минут и проверяем наличие изменений, возможно, именно об этом говорят ваши коллеги.

Вы ожидаете, что ваши 10 разработчиков будут делать чаще, чем раз в пятнадцать минут? Это звучит как довольно высокая оценка. 10 dev означает, что через каждые 150 минут один и тот же человек снова совершает, то есть 2,5 часа. Таким образом, в ваш средний день каждый разработчик совершает 3 раза. Лично я делаю один коммит ~ 2 дня ... иногда больше, иногда меньше.


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

3
@NimChimpsky: вы делаете один коммит каждые 3 дня? Если это правда, я предлагаю вам серьезно пересмотреть свою стратегию коммитов. Всякий раз, когда вы собираетесь сбросить что-либо в предыдущее состояние, вы потеряете до 3 дней работы! Как вы описываете изменения за 3 полных дня в нескольких словах в вашем журнале изменений? Это звучит очень абсурдно. Лично я делаю коммит всякий раз, когда добавляю рабочий фрагмент функции в свою программу, обычно несколько раз в день.
Док Браун

2
@DocBrown это далеко не абсурдно. Я мог бы посвятить себя разным проектам и разным репозиториям три раза в минуту. С другой стороны, я мог бы вообще не писать никакого кода целую неделю. Я предлагаю вам серьезно рассмотреть вашу стратегию комментирования.
НимЧимпский

1
@NumChimpsky: Я предполагаю, что вы говорите о ситуации, сравнимой с ситуацией, описанной ОП. Мы говорим о 10 разработчиках, работающих над одним проектом. Если среднее время между коммитами на разработчика составляет 3 дня, то в этом проекте что-то идет очень и очень неправильно.
Док Браун

2
@DocBrown wtf? Вы не знаете, о чем говорите ... Я так понимаю, вы не работаете над несколькими проектами одновременно.
НимЧимпский

3

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

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


2

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

Но я согласен, что нет смысла строить, если ничего не изменилось.


2

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

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

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


0

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

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

Если у вас настроены задания Jenkins для запуска при развертывании артефактов зависимостей (и если вы это сделаете ... Bravo), вы можете проверить запланированную сборку, если ваши модульные тесты надежны (то есть они не проверяют зависимости) и ваши Интеграционные / функциональные тесты не являются частью работы Дженкинса.

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


0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.