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