В какой момент интересен сервер непрерывной интеграции?

9

Я немного читал о CI-серверах, таких как Jenkins, и мне интересно: в какой момент это полезно?

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

Здесь у нас около 1500 юнит-тестов, и они проходят (на старых рабочих станциях Core 2 Duo) примерно за 90 секунд (потому что они действительно тестируют «юниты» и, следовательно, очень быстро). У нас есть правило, что мы не можем зафиксировать код, если тест не пройден.

Поэтому каждый разработчик запускает все свои тесты для предотвращения регресса.

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

Мне все еще не очень ясно: я должен настроить CI-сервер как Дженкинс? Что бы это принесло?

Это просто полезно для увеличения скорости? (не проблема в нашем случае)

Это полезно, потому что старые сборки могут быть воссозданы? (но мы можем сделать это с Mercurial, проверяя старые обороты)

В принципе, я понимаю, что это может быть полезно, но я не понимаю, почему именно.

Любое объяснение, принимая во внимание пункты, которые я поднял выше, было бы очень желательно.

Седрик Мартин
источник

Ответы:

9

Это просто полезно для увеличения скорости? (не проблема в нашем случае)

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

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

Это полезно, потому что старые сборки могут быть воссозданы? (но мы можем сделать это с Mercurial, проверяя старые обороты)

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

Вы строите его на сервере сборки, а не на каком-то устройстве Dev.

Здесь у нас около 1500 юнит-тестов, и они проходят (на старых рабочих станциях Core 2 Duo) примерно за 90 секунд (потому что они действительно тестируют «юниты» и, следовательно, очень быстро). У нас есть правило, что мы не можем зафиксировать код, если тест не пройден.

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

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

в какой момент это полезно?

Это инвестиция, как и любая другая.

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

Это также зависит от типа приложений, которые вы делаете.

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

Кроме того, вы, возможно, захотите увидеть, как ваши потребности и проблемы совпадают с 12 Шагами к улучшению кода Джоэла Спольски . Особенно 2, 3 и 10 (хотя они все интересные и важные).

Мерлин Морган-Грэм
источник
2
+1 ... ОК, теперь ты говоришь со мной! « Не теряя времени делать строит» аргумент , который я , как много. Наша сборка выполняется несколько раз в день и занимает всего один клик, но ... это медленнее, чем запуск всех тестов (поэтому разработчики теряют время). Кроме того, мне нравится идея более сложных тестов: я вижу, как мы можем извлечь выгоду из CI-сервера. Относительно 2,3 и 10: да, да и да (один щелчок по задаче Ant) ... Но, человек, эти 12 правил должны быть обновлены: вы используете контроль версий? Я бы предпочел не CVS, например; ) (просто полушутя;)
Седрик Мартин
7

В какой момент это полезно?

  • Ваш цикл сборки + тестирования занимает более пары минут. После 5-минутного теста вы больше не захотите запускать все тесты самостоятельно, особенно для небольших изменений.
  • Вы начинаете строить несколько вариантов. Если у вас есть несколько клиентов с различными настройками, вы должны запускать тесты для каждого варианта, поэтому объем работы начнет расти довольно быстро. Чем бы вы запустили набор тестов для одного варианта на компьютере разработчика и предоставили CI запускать его на остальных.
  • Вы пишете автоматизированные интеграционные тесты, которые требуют некоторой нетривиальной настройки тестовой среды. Чем вы хотите провести тестирование в одной канонической тестовой среде, поскольку разработчики могут изменить свою среду различными способами из-за изменений в разработке. КИ является наиболее подходящим местом для канонической среды.
  • Тестеры могут просто извлечь последнюю сборку из CI. Таким образом, им не нужно иметь, изучать и использовать инструменты разработки, и ни один разработчик не должен отправлять им свою сборку вручную.
  • Когда вы готовитесь к выпуску:
    • Тестирование становится более важным, поэтому наличие одного места с подготовленными сборками для тестирования еще более полезно.
    • Вы уверены, что все сборки построены с использованием одной и той же среды сборки, поэтому вы избежите проблем, которые могут возникнуть из-за тонких различий между установками разработчика.
    • Вы уверены, что вы строите именно то, что проверено в системе контроля версий. Во время разработки, если кто-то забудет что-то проверить, вы найдете это довольно быстро, потому что это не удастся следующему разработчику. Но если такая сборка переместится в QA или производство и они сообщат об ошибке, это будет очень трудно отследить.

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

Ян Худек
источник
+1, спасибо. Но аргумент о сборке, которого я никогда не получал: разве приложение не является более надежным, когда все разработчики могут проверить любую версию и построить точно такую ​​же сборку, каждый на своем компьютере? Разве мы не просто перенесли проблему «сборок, привязанных к учетной записи разработчика», на «сборку, привязанную к CI-серверу» ? Я имею в виду: сам сервер CI может быть неправильно настроен, и, следовательно, сборка зависит от тонкой разницы в установке сервера CI !? Тем не менее, я вроде понимаю, что это может быть полезно: я думаю, что мне просто нужно «установить его и посмотреть»
:)
@CedricMartin: CI-сервер - это всего лишь один, поэтому ошибка не будет возникать из-за различий между средами, в которых вы это делали, и предыдущей сборкой, и, поскольку вы не выполняете другую работу на CI-сервере, менее вероятно, что вы ее сломаете ,
Ян Худек
@CedricMartin: Очевидно, что если сервер CI неправильно настроен, вы заметите, что сборки ведут себя не так, как сборки на полях для разработчиков, так как разработчики будут собирать для себя все время. Проще, чем когда какая-то конкретная коробка разработчика неправильно настроена, так как больше людей могут это заметить.
Ян Худек
6

Для меня КИ становится интересным, если в вашей команде более 1 члена.

Вы должны перестать думать о КИ как о «другом ПК, на котором проводятся тесты для меня». CI о наличии определенного и автоматизированного процесса сборки и управления выпуском.

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

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

Проблемы, которых он избегает:

  • Кто несет ответственность за создание релиза
  • Этот человек доступен 24/7
  • Но это основывается на моей машине синдром
  • Убирает всю двусмысленность в отношении того, какая версия была выпущена нами.

Преимущества (слишком много, чтобы упоминать все):

  • Автоматическая нумерация версий
  • Интеграция с отслеживанием проблем
  • Автоматическая генерация метрик
  • Статический анализ кода
  • Автоматическое развертывание
  • Многоступенчатые установки
Olivers
источник
5

Существует одна фундаментальная проблема, связанная с Continuous Integration (CI), которая отлично отражена в вашем вопросе: практики CI сложно реализовать и защитить, потому что программное обеспечение CI-сервера не тривиально в настройке и не тривиально, чтобы ваши проекты работали и выполнялись через CI сервер. При этом становится трудно понять, где вообще выигрыш от использования КИ.

Прежде всего, CI - это понимание и качество. Хороший CI приближает вас к вашему проекту, дает правильную обратную связь по показателям качества, документации, соответствию стандартам кодирования и т. Д. Он должен предоставить вам инструменты для простой визуализации всего этого, и позволит вам сразу же распознавать и легко связать набор изменений с определенным снимком всех этих метрик проекта.

Это не просто запуск модульных тестов. Не за что! Что подводит меня к качеству. КИ охватывает ошибки, не избегает их и не выбрасывает. Что он делает, так это просто предоставляет вам инструмент для выявления ошибок на раннем этапе, а не позже. Таким образом, вы на самом деле не передаете ранее протестированный код на CI-сервер. Хотя вы должны стремиться к фиксации чистого и не битого кода, вы фактически используете сервер CI для автоматического запуска компоновщика интеграции через ваш код и позволяете ему оценить, все ли получилось правильно. Если это так, аккуратно! Если это не так, нет проблем - хорошие практики CI утверждают, что вашим следующим приоритетом должно быть просто исправить то, что было сломано. Который, на хорошем CI-сервере, должен быть легко указан для вас.

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

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

У меня была точно такая же проблема, и именно это заставило меня развивать Cintient в свободное время примерно год назад. Моя предпосылка состояла в том, чтобы сделать его простым в установке, настройке и использовании, а также обеспечить его на основе тех показателей качества, которые все остальные в значительной степени терпят неудачу или недопоставки. Итак, после этого длинного ответа приходит мой бесстыдный плагин, указывающий на ссылку GitHub для проекта (которая является бесплатной и с открытым исходным кодом, естественно). У этого также есть некоторые хорошие скриншоты, очевидно. :-) https://github.com/matamouros/cintient

Надеюсь, я тебе помог.

(ПРИМЕЧАНИЕ: отредактировано после комментария Брайана Окли о том, что мне нужно было больше времени, чтобы найти лучший ответ. Я также думаю, что он был прав.)

matamouros
источник
Я проголосовал, потому что это не отвечает на вопрос, это просто реклама. Вы никогда - адрес , когда часть вопроса, кроме как неявно подразумевает «теперь, с моим инструментом».
Брайан Оукли
Мне потребовалось некоторое время, чтобы отредактировать ответ, как предложено @ bryan-oakley.
Матамурос
@matamouros: хорошая работа по редактированию.
Брайан Оукли