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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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