Continuous Integration (CI, непрерывная интеграция) — практика разработки программного обеспечения, при которой все члены команды интегрируют свой код в общую ветку как минимум раз в день. Каждая интеграция запускает автоматическую сборку и тестирование. Цель — выявлять конфликты и ошибки как можно раньше, когда их стоимость исправления минимальна.
Как работает
Рабочий процесс CI строится на автоматизации. Разработчик отправляет коммит в репозиторий (Git), CI-сервер обнаруживает изменение через webhook или polling и запускает pipeline:
- Checkout — CI-сервер клонирует репозиторий.
- Build — компиляция кода, сборка артефактов (Docker-образ, JAR, npm-bundle).
- Unit tests — запуск быстрых тестов, изолированных от внешних зависимостей.
- Integration tests — тесты с реальными базами данных, очередями, API.
- Static analysis — линтинг, покрытие кода (coverage), проверка уязвимостей зависимостей.
- Notification — уведомление команды о результате (Slack, email, PR-статус).
При провале любого шага pipeline останавливается, разработчик получает уведомление. Ветка не попадает в основную до зелёного статуса всех проверок. Это называется broken build discipline — культура немедленного исправления упавшей сборки.
CI-системы: GitHub Actions, GitLab CI, Jenkins, Drone CI, CircleCI, TeamCity. Каждая система запускает задачи в контейнерах или виртуальных машинах, называемых Runner.
История
Концепцию CI впервые описал Грейди Буч в 1991 году, но без обязательных ежедневных интеграций. Кент Бек и Рон Джеффрис в 1997 году в рамках экстремального программирования (XP) добавили требование частых интеграций. Мартин Фаулер и Мэтт Фоммел опубликовали статью «Continuous Integration» в 2000 году (переработана в 2006) — этот текст стал каноническим определением практики. В 2001 году ThoughtWorks создали CruiseControl — первый широко распространённый CI-сервер. В 2008 году вышел Hudson (позже переименован в Jenkins), ставший на долгое время стандартом индустрии. GitHub Actions (2019) и GitLab CI демократизировали CI, интегрировав его прямо в платформы управления кодом.
CI vs CD
CI — первая часть практики CI/CD. Continuous Deployment (или Continuous Delivery) расширяет CI автоматическим развёртыванием собранного и проверенного кода в production или staging-среду. CI останавливается на этапе проверки; CD добавляет доставку.
На что обращать внимание
Медленные тесты убивают ценность CI — если pipeline занимает 40 минут, разработчики начнут пропускать запуски. Цель: основной pipeline менее 10 минут для поддержания ритма. Разделяйте тесты на быстрые (unit) и медленные (integration, e2e); запускайте e2e-тесты отдельно — по расписанию или на staging. Покрытие кода (code coverage) — полезная метрика, но не самоцель: 80% реальных тестов лучше 100% формальных. Храните конфиг CI в репозитории (.github/workflows/, .gitlab-ci.yml, .drone.yml) — это Infrastructure as Code.
CI в хостинге
CI-система запускает автоматические проверки при каждом коммите: сборка, тесты, staging-деплой. GitHub Actions — бесплатно для public-репозиториев, $4/мес для private. Self-hosted Jenkins на VPS: полный контроль, требует 512 МБ-2 ГБ ОЗУ. Drone CI — лёгкий, container-first. CI/CD pipeline: source → build → test → container → deploy. GitLab CI встроен в GitLab — нет отдельной установки. CD (Continuous Deployment) — следующий шаг: автоматический деплой в production после успешного CI.