Непрерывная интеграция - обзор
Непрерывная интеграция была впервые представлена в 2000 году с программным обеспечением, известным как Cruise Control. С годами непрерывная интеграция стала ключевой практикой в любой программной организации. Это практика разработки, при которой команды разработчиков должны гарантировать, что сборка и последующее тестирование проводятся для каждого изменения кода, внесенного в программу. Эта концепция была предназначена для устранения проблемы обнаружения поздних возникновений проблем в жизненном цикле сборки. Вместо того, чтобы разработчики работали изолированно и недостаточно интегрировались, была введена непрерывная интеграция, чтобы гарантировать, что изменения кода и сборки никогда не будут выполняться изолированно.
Почему непрерывная интеграция?
Непрерывная интеграция стала неотъемлемой частью любого процесса разработки программного обеспечения. Непрерывный процесс интеграции помогает ответить на следующие вопросы команде разработчиков программного обеспечения.
Все ли программные компоненты работают вместе, как должны? - Иногда системы могут стать настолько сложными, что для каждого компонента будет несколько интерфейсов. В таких случаях всегда важно обеспечить бесперебойную работу всех программных компонентов друг с другом.
Код слишком сложен для интеграции? - Если процесс непрерывной интеграции будет продолжать давать сбой, возможно, код слишком сложен. И это может быть сигналом к применению правильных шаблонов проектирования, чтобы сделать код менее сложным и более удобным в обслуживании.
Соответствует ли код установленным стандартам кодирования? - Большинство тестовых примеров всегда проверяют, соответствует ли код надлежащим стандартам кодирования. Выполняя автоматический тест после автоматизированной сборки, это хороший момент, чтобы проверить, соответствует ли код всем желаемым стандартам кодирования.
Сколько кода покрывают автоматические тесты? - Нет смысла тестировать код, если тестовые примеры не охватывают требуемую функциональность кода. Поэтому всегда рекомендуется гарантировать, что написанные тестовые примеры должны охватывать все ключевые сценарии приложения.
Все ли тесты прошли успешно после последнего изменения? - Если тест завершился неудачно, тогда нет смысла продолжать развертывание кода, поэтому это хороший момент, чтобы проверить, готов ли код перейти к этапу развертывания или нет.
Рабочий процесс
На следующем изображении показан быстрый рабочий процесс того, как весь рабочий процесс непрерывной интеграции работает в любом проекте разработки программного обеспечения. Мы рассмотрим это подробно в следующих главах.
Итак, исходя из описанного выше рабочего процесса, обычно так и работает процесс непрерывной интеграции.
Сначала разработчик фиксирует код в репозитории контроля версий. Между тем, сервер непрерывной интеграции на машине построения интеграции опрашивает репозиторий исходного кода на предмет изменений (например, каждые несколько минут).
Вскоре после совершения фиксации сервер непрерывной интеграции обнаруживает, что в репозитории управления версиями произошли изменения, поэтому сервер непрерывной интеграции извлекает последнюю копию кода из репозитория, а затем выполняет сценарий сборки, который интегрирует программное обеспечение.
Сервер непрерывной интеграции формирует обратную связь, отправляя результаты сборки по электронной почте указанным участникам проекта.
Затем выполняются модульные тесты, если сборка этого проекта проходит. Если тесты пройдены успешно, код готов к развертыванию на промежуточном или производственном сервере.
Сервер непрерывной интеграции продолжает опрашивать изменения в репозитории контроля версий, и весь процесс повторяется.