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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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