Насколько важно время сборки сервера для быстрой разработки? - PullRequest
2 голосов
/ 30 июля 2009

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

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

Сейчас я склоняюсь к 5 минутам.

Ответы [ 2 ]

3 голосов
/ 13 августа 2009

5 минут - хорошая отправная точка. У меня были проекты, которые занимали 12-15 минут, чтобы построить с командой из 6 человек. Наше правило состояло не в том, чтобы взять на себя обязательство по проекту здания или сломанной конструкции, которую вы не сломали. Коммиты могут происходить только каждые 12-15 минут, и это стало проблемой. Мы инвестировали в лучшее оборудование и разделили сборку на 1) сборочные и модульные тесты и 2) приемочные тесты и проверки качества кода. Мы внесли изменения в правило, разрешив повторную фиксацию после шага 1, который теперь длился около 5-6 минут.

Еще один фактор, который необходимо учитывать, это то, как скоро после коммита вы покидаете свою рабочую среду на обед, встречу или на день. Я помню, что совершил в 6 вечера и пришлось ждать до 6:20, чтобы уйти. Были времена, когда я ждал до утра, чтобы совершить.

Итак, два фактора:

  • Как долго между фиксациями?
  • Время сборки настолько велико, что разработчики избегают коммитов?
1 голос
/ 30 июля 2009

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

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

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

Так что, пока ваши сборки не занимают часы, это, вероятно, нормально.

...