В чем смысл ежедневных сборок?

Question

[littleguga]

Для чего их стоит использовать?

1. Тема для вордпресса?
2. Плагин для jquery?
3. Консольный модуль для nodejs
4. Обширное и многофункциональное веб-приложение на стеке php+js

Я правильно понимаю, что данная процедура нужна для отслеживания изменений, которые ломают продукт?
То есть сделал коммит->ночная сборка сломалась->на следующий день поправил?
А если я пишу изменения, не успел доделать функционал, но день закончен - надо ли кидать в git, точно зная, что это сломает продукт? (и тут сразу второй вопрос, ежедневно тестировать сборку надо только ветки master? Или всех веток с фичами, наработками и тд?)

Answer 1

[Saboteur]

Варианты могут быть такие:
а) На каждый коммит сразу идет сборка продукта и прогоняются интеграционные тесты.

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

б) сборка может быть ночной. Например потому что билд идет 5 часов на толстом сервере, и на рабочей машине он будет идти 10-15 часов, а то и не идти вообще. Тогда конечно, желательно не ломать билд недоделанными коммитами. Но git же позволяет коммитить без пушей, либо пользоваться бренчами, и настраивать сборку не на просто коммит, а на мерж в девелоперский или мастер бренч.

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

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

Comments

[littleguga]

А по пунктам, для какого проекта стоит это настраивать делать, а для какого нет?

[Saboteur]

littleguga:
Эм. ну это надо весь проект смотреть, в деталях. И дело не только в самих ночных сборках, но и в том, как работают разработчики - они же должны учитывать, что будут сборки.

Если же по вашему примеру, то
1. Тема для вордпресса?
Я не очень разбираюсь, можно ли тему для вордпресса автоматически тестировать, это же смотреть глазами надо. Кроме того, я не очень представляю сколько коммитов нужно в сумме, чтобы сделать новую тему для ворпресса. Есть подозрение, что настраивать continous integration для такой задачи займет больше чем сама задача

2. Плагин для jquery?
3. Консольный модуль для nodejs
Тут можно. Естественно билдить только если коммиты были. И желательно добавить автоматическое тестирование.

4. Обширное и многофункциональное веб-приложение на стеке php+js
Вот тут можно развернуться, написать обширное и многофункциональное тестирование, автоматический деплой на разные тестовые энвайрнменты, чтобы тестеры с утра пришли, а у каждого уже с нуля новая версия поднята, репорты об автоматическом тестировании в почте, остальное - сиди тестируй.

[littleguga]

Saboteur: спасибо большое!

Answer 2

[Максим Люмен]

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

Answer 3

[Толстый Лорри]

Ломать билд крайне нежелательно, особенно в master-ветке!
Ночные сборки нужны не только для непосредственно разрабатываемого продукта, но и для отслеживания интеграции со всякими внешними зависимостями (через Maven, NuGet, npm...у кого там что подтягивается).

Встречал, что юнит-тесты прогоняются при каждом коммине (даже фичебранчи, т.е. их ломать тоже не желательно), но полноценные ночные сборки, тесты Selenium работают лишь с develop.

Comments

[littleguga]

Ломать master понятно не надо, вот есть ветка "my-feature", я пилю в ней изменения, день закончился, я не доделал до рабочего варианта, но кидаю в git, надо ли собирать данную ветку? Тестировать?

[Толстый Лорри]

littleguga: ИМХО, это не стоит даже коммитить. И уж тем более - пушить на некий общий сервер, откуда CI берет ветку на тесты. Зачем тестировать заведомо сломанный билд?)

[littleguga]

Free_ze: стоит коммитить, мало ли, что потом произойдет и код будет дописывать за меня другой.

[littleguga]

Free_ze: просто пушить не в мастер

[Толстый Лорри]

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

[Толстый Лорри]

Free_ze: ну или хотя бы не пушить на сервер в фичебранч.

Answer 4

[ahosta]

Ну у нас например, тесты прогоняются ПРИ КАЖДОМ КОММИТЕ, а не раз в сутки.
Раз в сутки - это уже устаревшее.
Это с тех времен, когда софт писался на медленно компилируемых вещах.

Comments

[littleguga]

Не, я про ночные билды, а не тесты.