Как использовать CI для интерпретируемых языков?

23

Я никогда раньше не использовал систему непрерывной интеграции (CI). Я в основном кодирую в MATLAB, Python или PHP. Ни у одного из них нет этапа сборки, и я не вижу, как CI мог бы использоваться для моей работы. Друг большого проекта в большой фирме сказал мне, что язык не имеет значения.

Я не понимаю, как CI будет полезен для меня, если у меня нет шага сборки. Я могу думать о CI как о среде тестирования, которая будет запускать модульные тесты. Я что-то пропустил?

Лорд лох
источник
14
Верно ли это, зависит от того, что вы считаете «этапом сборки». Вы, кажется, думаете об этом как о минимальной компиляции, чтобы дать вам что-то работоспособное. В моей команде мы рассматриваем сборку как компиляцию, статический анализ и модульные тесты (с местом для дополнительных задач). Преимущество этого определения заключается в том, что коммит, который не прошел модульные тесты, не «строится» и не допускается в репозиторий с самого начала.
Крис Хейс
Если говорить более подробно о Крисе, система CI может и должна тестировать любые и все автоматизированные тесты - компиляция и компоновка могут рассматриваться как одна из форм автоматических тестов. Если у вас есть ограничения по ресурсам, некоторые из более медленных тестов могут выполняться только на ночных сборках или даже сборках выходного дня, но CI будет их запускать. Задайте себе вопрос: почему вы хотите автоматизировать тесты, но по-прежнему запускать автоматизированные тесты вручную?
Питер - Унбан Роберт Харви

Ответы:

32

Непрерывная интеграция как термин относится к двум различным идеям.

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

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

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

Оказывается, такой сервер полезен не только для тестирования. Фактически, большинство программного обеспечения CI действительно дрянно проводят тесты в различных конфигурациях, но хорошо справляются со всеми видами работ. Например, в дополнение к «непрерывным» модульным тестам, может быть полный тест как ночная сборка. Программное обеспечение может быть протестировано с несколькими версиями Python, различными версиями библиотеки. Веб-сайт может быть проверен на наличие мертвых ссылок. Мы можем запустить статический анализ, проверки стиля, инструменты тестирования покрытия и т. Д. Поверх кода. Документация может быть сгенерирована. Когда все наборы тестов пройдены, можно начать процесс упаковки, чтобы вы были готовы выпустить свое программное обеспечение. Это полезно в гибкой настройке, когда вам нужен постоянно развертываемый (и демо) продукт. С появлением веб-приложений появилась и идея постоянного развертывания.: Если все тесты пройдены, мы можем автоматически отправить изменения в производство. Конечно, это требует, чтобы вы были действительно уверены в своем наборе тестов (если нет, у вас есть большие проблемы).

Амон
источник
3
«CI имеет смысл, только если у вас есть набор тестов» - обратите внимание, что для скомпилированного языка сам компилятор является зачаточным набором тестов, который улавливает много распространенных ошибок.
user253751 20.02.16
@immibis Я думаю, что речь идет не о скомпилированных или интерпретированных, а о статических типах. Язык со статической системой типов может автоматически доказывать определенные свойства корректности. Это даже лучше, чем тесты, которые работают только на примерах. Единственная распространенная проблема, обнаруживаемая сервером CI при выполнении компиляции, заключается в том, что разработчик забыл зафиксировать новый файл; во всех остальных случаях нам на самом деле не нужен CI-сервер, и мы можем просто скомпилировать локально для проверки на наличие ошибок.
Амон
1
@ Amon Неверно. Нередко вносить изменения в последнюю минуту, а затем забывают проверить компиляцию перед фиксацией. Он также улавливает проблемы, когда вы добавляете зависимости от чего-то, что вы глобально установили локально, но больше нигде не установлено.
jpmc26
24

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

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

Икер
источник
8
Я бы добавил: самый очевидный способ автоматически протестировать систему - это автоматически выполнить ее. Например, вы можете протестировать сайт с помощью таких инструментов, как JMeter или Selenium.
reinierpost
7

Непрерывная интеграция выполняет больше, чем компиляция кода. Если это все, что было сделано, нам бы не понадобилось так много инструментов!

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

  • Выполнение автоматических тестов. (У Python есть множество автоматизированных библиотек тестирования, а у PHP есть, по крайней мере, некоторые. Я не могу говорить с MATLAB.)
  • Комплектация программного обеспечения для распространения. Автоматизируя этот процесс, вы гарантируете, что он выполняется точным, последовательным и воспроизводимым образом каждый раз. Никакие шаги не будут забыты; создание такого дистрибутива занимает не более одного клика. (Объединение вашего Python-приложения в качестве колеса - отличная идея!)
  • Пометка вехи фиксирует. Всякий раз, когда вы создаете пакет для производства, вы, вероятно, хотите пометить его.
  • Автоинкрементные номера версий. Обычно это просто номер сборки, а не более значимые части, но может быть полезно однозначно идентифицировать конкретную сборку, чтобы вы знали, где и где развернуты.

Пройдя немного дальше к границе «непрерывной интеграции» в строгом смысле, вы также можете сделать это:

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

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

  • Последовательный процесс (Стэн и Салли не будут делать что-то по-разному.)
  • Знание процессов, записанных в коде (любой, кто умеет читать сценарии, может изучить этапы развертывания, вместо того, чтобы Салли была единственной, кто это делает или знает как).
  • Простое дублирование процессов (Простое развертывание нескольких копий веб-сайта: вы просто предоставляете новую конфигурацию!)
  • Более тщательное тестирование (Боб только протестировал свою страницу, но его изменения испортили страницу Салли. Салли забыла зафиксировать файл. Стэн добавил новую зависимость, которая должна быть установлена ​​вместе с приложением, но не осознал этого, потому что она автоматически устанавливается в среде IDE. Я видел все это в той или иной форме.)

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

jpmc26
источник
Спасибо за ответ. Примеры отличные. Я хотел бы проголосовать более одного ответа, как принято: - /
Лорд Ло.
@LordLoh. Не стоит беспокоиться. Я просто рад, что смог помочь. =) Спасибо, что дали мне знать.
jpmc26
1
Проголосовал, отличный ответ. Как и все, если сделать плохо, вы не могли бы пожинать объявленные преимущества. Например, согласованность, знание процесса, простота могут пострадать, если вы перестроитесь. Так что ... оцените свои потребности реально и Godspeed!
brian_o
1

Вам может не понадобиться компилировать решения, но CI все равно может помочь вам, изменив конфигурационные файлы / пути к папкам и т. Д., И если вы в команде - продвигаете изменения в статусе prod и развертываете их

Допустим, вы развертываете свой код Python на 5 разных серверах QA, и вам нужно, чтобы он указывал на разные базы данных QA, а затем, после автоматического запуска теста (запускаемого CI), продвигать сборку в производство и развертывать ее там с соответствующими изменениями конфигурации для каждого рабочего сервера. ,

Майк
источник