Я пытаюсь добавить непрерывную интеграцию в проект.
Согласно Википедии , одним из основных элементов CI является автоматизированная сборка. Однако я не совсем понимаю, что именно это означает, поскольку статьи о КИ и автоматизации сборки, похоже, не согласны.
Особенности путаницы: что означает «автоматизированная сборка» в контексте:
- проект, использующий интерпретируемый язык, такой как Python или Perl?
- строить из источника на компьютере конечного пользователя?
- приложение, которое имеет зависимости, которые нельзя просто предварительно скомпилировать и распространить, например, базу данных в СУБД, локальной для компьютера пользователя?
buildsиbuildпотому что я не знал, какой из них использовать.Ответы:
Вы правильно заметили, что для некоторых технологий этап компиляции не требуется. Тем не менее, я рекомендую вам придерживаться более широкой точки зрения при интерпретации термина «автоматизация сборки». Представьте, что «сборка» включает в себя следующие два основных компонента:
Таким образом, автоматизация означает просто выполнение любого, если не всех, этих операций автоматически (то есть не требует ручного вмешательства). Это может включать в себя множество шагов, в зависимости от вашей технологии:
Этапы трансформации:
Этапы обеспечения качества:
В наши дни хорошие инструменты CI позволят вам решить все эти проблемы. Первоначально большинство магазинов заинтересованы в автоматизации компиляции своего кода, поскольку это первый и наиболее заметный источник проблем при разработке обычного программного обеспечения.
источник
Автоматическая сборка - это описание процесса, которое должно охватывать следующие основы:
5.1 Успешная компиляция, успешное тестирование
Это практический процесс, который должен выполняться без ручного вмешательства.
источник
На мой взгляд, автоматизированная сборка - это то, что
Цель состоит в том, чтобы иметь процесс развертывания, который можно повторить - прочитайте: протестировал - чтобы к моменту развертывания в рабочей среде вы имели достаточную степень уверенности в том, что все пойдет не так. Чем меньше человеческого взаимодействия в процессах сборки и развертывания, тем безопаснее будет ваш выпуск.
Если у вас не скомпилированный язык, вы все равно можете создать сайт и сжать его, чтобы создать один артефакт.
Хороший инструмент CI позволит вам выполнять множество задач в процессе сборки, включая запуск модульных тестов. Он также будет вести учет ваших успешных и неудачных сборок, тестового покрытия и т. Д. Но ничего из этого не является частью того, что я бы определил как автоматическую сборку. (то есть. Хороший автоматизированный процесс сборки имеет эти вещи, но плохой процесс не может быть назван «автоматической сборкой», потому что в нем нет таких вещей.)
Я бы предложил, чтобы интеграционные / регрессионные тесты выполнялись как часть процесса развертывания, а не как процесс сборки (хотя, если у вас есть удобная среда, вы можете развертывать ее при каждой сборке).
источник
В случае с интерпретируемыми языками, вещи могут быть поражены или пропущены. В некоторых взаимопроникающих языках есть компиляторы, но чаще всего нет необходимости использовать их. В этом случае я бы обычно просто сканировал код на наличие синтаксиса и ошибок синтаксического анализа вместо компиляции или сразу переходил к выполнению тестов кода.
Для меня это будет означать, что вы можете предоставить одну команду, которую конечные пользователи могут запустить, чтобы получить последнюю версию программы, скомпилировать ее, настроить и развернуть по мере необходимости.
Они подпадают под тестовую часть непрерывной интеграции, поскольку вы можете автоматически уничтожать и восстанавливать базы данных, чтобы убедиться, что сценарии верны и что программа проверяет их корректность.
источник
То, что вы обсуждаете в своем вопросе, - это на самом деле 3 разных понятия:
Непрерывная интеграция в своей основе вносит небольшие изменения и часто синхронизирует эти изменения с «глобальной истиной». Вместо того, чтобы оформлять заказ и удерживать его в течение недели, разработчик должен поработать над задачами, которые могут быть выполнены в течение дня, чтобы его код никогда не был слишком далеко не синхронизирован с основным хранилищем.
Чтобы достичь этого, не причиняя боли своей команде (т.е. проверяя источник, который не создает или нарушает существующую функциональность). Разработчик должен убедиться, что его код не «нарушает сборку». Если это делается вручную, это добавляет дополнительные издержки к процессу разработки (представьте себе проект, который занимает много времени для сборки и / или имеет много взаимозависимостей, где изменение одной строки кода может неожиданно повлиять на приложение).
Чтобы смягчить эту ситуацию, мы используем другие методы, чтобы устранить эти издержки.
Мы используем автоматические сборки для извлечения источника и его сборки, при необходимости запускаем автоматические тесты, которые проверяют, что приложение работает должным образом (этот шаг полезен только как набор тестов).
Дальнейший шаг непрерывной доставки решает вашу проблему с базой данных и другими проблемами. Идея заключается в том, чтобы обеспечить некоторый уровень управления версиями для базы данных и других факторов среды, чтобы мы могли как можно быстрее подтвердить, что приложение работает в среде, максимально приближенной к рабочей .
источник
«Автоматизированная сборка» означает, что вы можете перейти от исходного кода к отправляемому пакету одним (планируемым) действием (обычно сценарием оболочки или пакетным файлом).
Что именно представляет собой сборка, в этом контексте во многом зависит от того, что именно вы отправляете, как она доставляется и какие шаги требуются для различных частей вашего стека разработки, но в любом случае вы начинаете с что находится в управлении исходным кодом, и вы в конечном итоге получите отправляемый продукт (или сообщение об ошибке и злой менеджер проекта).
Для простого проекта Python автоматическая сборка может состоять только из двух этапов - проверка исходных файлов и копирование соответствующих файлов в правильные каталоги. Для более сложных проектов это может включать такие вещи, как:
источник