Continuous integration что это

Что такое непрерывная интеграция?

Придайте гибкости своей команде, ускорив обратную связь. Ваша реальная скорость определяется скоростью ваших тестов.

Непрерывная интеграция (CI) направлена на автоматизацию интеграции изменений кода от нескольких участников в единый программный проект. Это основная рекомендация DevOps, позволяющая разработчикам регулярно объединять изменения кода в центральном репозитории, где затем запускаются сборки и тесты. Автоматизированные инструменты используются для проверки нового кода перед интеграцией.

В основе процесса CI лежит система контроля версий исходного кода. Система контроля версий дополняется другими средствами, такими как автоматизированные проверки качества кода, инструменты проверки стиля синтаксиса и многими другими.

Как перейти к непрерывной интеграции

Узнайте, как внедрить непрерывную интеграцию и автоматизированное тестирование за пять шагов. Прочитать статью

Пять советов по организации репозиториев Git с поддержкой непрерывной интеграции

Пять советов о том, как извлечь максимум пользы из Git и вашего инструмента непрерывной интеграции. Прочитать статью

Инструменты непрерывной интеграции

Пять советов о том, как извлечь максимум пользы из Git и вашего инструмента непрерывной интеграции. Прочитать статью

Магистральная разработка

Подробнее о магистральной разработке — методе управления версиями, при котором разработчики объединяют небольшие частые обновления с центральной «магистралью», или главной веткой. Прочитать статью

Учебное руководство по непрерывной интеграции

Из этого учебного руководства вы узнаете, как начать использовать непрерывную интеграцию за три простых шага. Ознакомьтесь с этим учебным пособием

Важность непрерывной интеграции

Чтобы понять важность CI, полезно сначала обсудить ряд проблем, возникающих при отсутствии CI. Без CI разработчики вынуждены самостоятельно координировать действия и общаться при внесении кода в конечный продукт. Координация выходит за рамки команд разработчиков и затрагивает отдел эксплуатации и остальные отделы организации. Проектировщики должны согласовывать последовательный выпуск функций и исправлений, а также распределять ответственность между участниками.

Избыточная коммуникация в среде без CI может вылиться в сложную работу по синхронизации, а также привести к бюрократии и неоправданным расходам при реализации проектов. Затем релизы начнут выходить реже и увеличится частота сбоев, поскольку интеграции потребуют больше внимания и осмотрительности со стороны разработчиков. Эти риски растут экспоненциально по мере расширения команды инженеров и кодовой базы.

Без надежного конвейера CI может возникнуть разлад между командой инженеров и остальными сотрудниками организации. Коммуникация между проектировщиками и инженерами может быть затруднена. Разработка становится черным ящиком, в который остальные участники команды вносят требования и функции (и получают нужные результаты, если сошлись звезды). Инженерам становится трудно прогнозировать скорость обработки запросов, поскольку не удается определить время интеграции новых изменений.

Зачем нужна непрерывная интеграция (CI)

CI помогает расширить персонал и нарастить эффективность команд инженеров. Внедрение CI по упомянутому сценарию позволяет разработчикам программного обеспечения параллельно вести независимую работу над функциями. Так они смогут самостоятельно и без задержек объединить эти функции в конечный продукт, когда все будет готово. CI — важная и надежная технология, используемая современными, высокоэффективными организациями в сфере разработки ПО.

Как можно использовать непрерывную интеграцию (CI)

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

Непрерывная интеграция, непрерывное развертывание и непрерывная поставка

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

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

Непрерывное развертывание — это заключительная стадия конвейера. Стадия развертывания отвечает за автоматический запуск и распространение рабочего продукта среди конечных пользователей. На момент развертывания продукт должен успешно пройти стадии интеграции и поставки. Теперь нужно автоматически развернуть или распространить продукт. Это будет сделано с помощью скриптов или инструментов, которые автоматически разместят продукт на общедоступных серверах или в другой системе распространения, такой как магазин приложений.

Плюсы и минусы непрерывной интеграции

Непрерывная интеграция — важная часть DevOps и высокоэффективных команд по разработке ПО. При этом преимущества CI приносят пользу не только команде инженеров, но и всем остальным частям организации. CI повышает прозрачность, а также помогает анализировать процесс разработки и поставку ПО. Эти преимущества позволяют другим сотрудникам организации лучше планировать и реализовывать рыночные стратегии. Ниже приведены некоторые из общих преимуществ CI для организации.

Масштабируемость

CI позволяет организациям масштабировать команду инженеров, кодовую базу и инфраструктуру. CI помогает создавать рабочие процессы DevOps и Agile, минимизируя бюрократию при интеграции кода и избыточную коммуникацию. Благодаря этому каждый участник команды может внести изменение кода вплоть до выпуска. CI позволяет выполнять масштабирование благодаря удалению организационных зависимостей при разработке отдельных функций. Разработчики могут создавать функции самостоятельно и с полной уверенностью в том, что слияние их кода с остальной частью кодовой базы пройдет без проблем. Это основной процесс DevOps.

Улучшение цикла обратной связи

Использование CI имеет полезные побочные эффекты, например быстрая обратная связь по бизнес-решениям. Проектировщики могут быстрее тестировать идеи и подбирать дизайн продукта с помощью оптимизированной платформы CI. Изменения можно быстро продвинуть и оценить. Ошибки и другие проблемы можно оперативно выявить и устранить.

Улучшение коммуникации

CI оптимизирует обмен информацией и обеспечивает отслеживаемость среди инженеров, что повышает эффективность сотрудничества между разработчиками и операционным отделом в команде DevOps. Внедряя рабочие процессы с запросами pull и привязкой к CI, разработчики обеспечивают пассивный обмен знаниями. Запросы pull позволяют разработчикам просматривать и комментировать код участников команды. Разработчики теперь могут просматривать функциональные ветки и работать над ними вместе с коллегами по мере продвижения функций по конвейеру CI. Непрерывная интеграция также подходит для управления расходами на ресурсы. Эффективный конвейер CI с автоматизированным покрытием тестами и высокой достоверностью предотвращает регрессии и гарантирует соответствие новых функций спецификации. Перед слиянием новый код должен показать соответствие набору тестовых утверждений CI, обеспечивающих защиту от новых регрессий.

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

Внедрение и установка

Трудности непрерывной интеграции прежде всего связаны с внедрением в команде и первичной технической установкой. Если у команды пока нет решения CI, его выбор и начало работы с ним могут потребовать определенных усилий. Таким образом, при установке конвейера CI необходимо учитывать существующую инфраструктуру процесса разработки.

Время на освоение технологии

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

Рекомендации по непрерывной интеграции (CI)

Разработка на основе тестов

После создания проектного конвейера CI с автоматическим покрытием тестами рекомендуется постоянно развивать и улучшать покрытие. Каждой новой функции, сходящей с конвейера CI, требуется сопутствующий набор тестов для проверки работоспособности кода.

Разработка на основе тестов (TDD) — это практика написания тестового кода и примеров перед фактическим программированием функции. Проектировщики могут активно использовать методику TDD как таковую для описания ожидаемого поведения бизнеса, на основе которого можно позже создать контрольные тесты. В «чистом» сценарии TDD разработчики и проектировщики встречаются и обсуждают спецификацию или список требований. Этот список требований преобразуют в перечень проверочных утверждений в коде. Затем разработчики пишут код с учетом этих утверждений.

Запросы pull и проверка кода

Большинство современных команд разработчиков ПО практикуют рабочий процесс, включающий запросы pull и проверку кода. Запросы pull критически важны для эффективной работы CI. Такой запрос создается, когда разработчик готов объединить новый код с основной кодовой базой. Запрос pull уведомляет других разработчиков о новых изменениях, подготовленных к интеграции.

Если имеются запросы pull, пришло время запустить конвейер CI и выполнить ряд автоматизированных шагов подтверждения. При создании запроса pull обычно добавляется дополнительный шаг ручного подтверждения, в течение которого инженер, не являющийся заинтересованным лицом, выполняет проверку кода функции. Это позволяет посмотреть на новый код и функциональные возможности с разных сторон. Незаинтересованное лицо сможет предложить правки, а также подтвердить или отклонить запрос pull.

Запросы pull и проверка кода являются мощным инструментом для содействия пассивной коммуникации и обмену знаниями между инженерами. Это помогает избежать технического долга в виде разрозненных знаний, при котором лишь некоторые инженеры заинтересованы в конкретных функциях кодовой базы.

Оптимизация скорости конвейера

Конвейер CI станет основным и часто используемым процессом, поэтому важно оптимизировать скорость его выполнения. Любая небольшая задержка в рабочем процессе CI будет нарастать экспоненциально с ускорением выпуска функций, а также расширением команды и кодовой базы. Рекомендуется по мере необходимости измерять и оптимизировать скорость конвейера CI.

Быстрый конвейер CI обеспечивает быстрый цикл обратной связи по продукту. Разработчики могут быстро продвигать изменения и экспериментировать с новыми идеями в сфере функциональности, чтобы повысить удобство использования. Любые ошибки можно быстро исправить и устранить по мере обнаружения. Ускорение работы не только дает вашим клиентам конкурентное преимущество, но и в целом повышает удобство использования.

Начало работы с непрерывной интеграцией

В основе CI лежит система контроля версий (VCS). Если целевая кодовая база для установки CI не имеет системы VCS, для начала нужно ее установить. Современные кодовые базы практически всегда оснащены системой VCS. Популярные решения включают Git, Mercurial и Subversion.

После установки системы VCS следует найти хостинг-площадку контроля версий. Большинство современных инструментов для хостинга контроля версий поддерживают CI и соответствующие функции. К популярным хостинг-площадкам контроля версий относятся Bitbucket, GitHub и GitLab.

После установки контроля версий в проект следует добавить шаги подтверждения интеграции. Самый важный шаг подтверждения интеграции включает автоматизированные тесты. Добавление автоматизированных тестов в проект может увеличить изначальную стоимость. Сначала нужно установить платформу для тестирования, после чего разработчики смогут написать тестовый код и тестовые сценарии.

Можно добавить ряд более экономичных проверочных средств CI, например средства проверки синтаксиса, оформления кода или сканирования уязвимостей в зависимостях. После настройки системы контроля версий с рядом шагов подтверждения и слияния будет завершена и настройка непрерывной интеграции!

Бизнес-процесс CI используется не только при разработке ПО. Конвейер CI будет полезен и другим сотрудникам организации, например командам по маркетингу и продажам, а также проектировщикам. Проектировщикам нужно будет подумать над тем, как обеспечить параллельную и одновременную разработку. Проектировщики и инженеры вместе определят соответствующие бизнес-ожидания в сфере функциональных возможностей, с учетом которых и будет создан набор автоматизированных тестов.

Команды маркетинга и продаж смогут ссылаться на конвейер CI для координации действий и мероприятий, ориентированных на общение с клиентами. CI позволяет другим сотрудникам организации видеть, как продвигается разработка. Непрерывная интеграция добавляет слой прозрачности и коммуникации, а также изящно интегрируется с рабочим процессом Agile-разработки проекта.

Заключение

Если ваша организация стремится извлечь пользу из подхода DevOps или у вас просто есть большая команда разработчиков, CI играет важную роль. Непрерывная интеграция поможет организации в сфере разработки выполнять задачи быстрее и эффективнее.

CI — неотъемлемый инструмент современных высокоэффективных организаций в сфере разработки ПО. Самые успешные компании имеют надежные конвейеры CI и всегда готовы вложиться в повышение эффективности. Преимущества CI доступны не только команде инженеров, но и всем остальным частям организации.

Существует множество инструментов для установки и управления CI от сторонних разработчиков. К популярным решениям относятся Codeship, Bitbucket Pipelines, Semaphore, CircleCI, Jenkins, Bamboo, Teamcity и многие другие. Эти инструменты снабжены подробными руководствами по настройке и документацией, которые помогут начать работу.

Попробуйте некоторые из лучших инструментов Atlassian для непрерывной интеграции.

Bitbucket Pipelines — это отличная утилита для ускорения работы над проектом благодаря современным функциям CI.

Jira — один из самых популярных в мире инструментов по управлению проектами, основанными на принципах DevOps и Agile. Он тесно интегрируется с другими проектами Bitbucket и в сочетании с конвейером CI может дать очень четкое представление о том, как в организации обстоят дела с выполнением проектов.

Max Rehkopf

Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian.

CI/CD

CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчикам, аналитикам, инженерам качества, конечным пользователям и др.).

«IT-специалист с нуля» наш лучший курс для старта в IT

Принципы CI/CD

Концепция непрерывной интеграции и развертывания относится к agile-методологиям разработки программного обеспечения. Ее основная цель — уделение достаточного внимания бизнес-требованиям, безопасности и качеству кода конечного продукта. В рамках подхода решаются следующие задачи:

• автоматизация последовательной сборки, упаковки и тестирования программных продуктов;
• автоматизация развертывания приложения в различных окружениях;
• минимизация ошибок и уязвимостей программного продукта.

Разработка по методике CI/CD соответствует таким основным принципам:

• Распределение ответственности. Задачи и этапы разработки разделяются между членами команды или ее подгруппами (при работе над большим проектом). Рабочий процесс организуется с учетом бизнес-логистики, внедрения сквозных функций, проведения тестов, безопасности хранения данных и т.д.
• Сокращение рисков. Каждый разработчик или подгруппа разработчиков должны стремиться минимизировать уязвимости и ошибки на всех этапах разработки. Для этого постоянно контролируется бизнес-логистика, проводится пользовательское тестирование продукта, оптимизируется хранение, обработка данных и т.д.
• Оптимизация обратной связи. Успех проекта зависит от того, как работают друг с другом разработчики, клиенты и пользователи. Это влияет на скорость внесения в приложение корректировок и обновлений. Если сборку и тестирование можно автоматизировать, то во многих других операциях требуется участие человека. Чтобы взаимодействие происходило конструктивнее, уменьшается количество посредников между заказчиком, исполнителями и пользователями.
• Создание рабочей среды. Для удобства совместной работы у разработчиков должно быть общее рабочее пространство. Помимо основной ветки процесса в нем должна быть побочная – в ней удобнее проводить тестирование, вносить корректировки, отслеживать отказоустойчивость и т.д.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

СI/CD представляет собой современную аналогию конвейерного производства. Их объединяют четкое распределение труда, непрерывный, потоковый характер рабочего процесса, параллельное выполнение сразу нескольких задач (например, кодинга и тестирования). Сегодня эта концепция является доминирующей в DevOps.

Читайте также Как выбрать IT-специальность в новых реалиях?

Этапы CI/CD

Написание кода. Каждый разработчик создает код отведенного ему модуля и тестирует его в ручном режиме. Затем разработанный и проверенный программный блок интегрируется в основной ветке с текущей версией продукта. Как только все модули будут опубликованы в главной ветке, команда переходит к следующему этапу.

Сборка. Заранее подобранная система контроля версий запускает автоматизированную сборку и тестирование всего продукта. Триггеры могут быть настроены автоматически или вручную. Автоматическая сборка выполняется с помощью Jenkins или другого сервера непрерывной интеграции.

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

Релиз. После исправления ошибок вычищенный и отлаженный код переходит на этап релиза для клиентов. Его проверяет заказчик, возможно, с привлечением своих специалистов или ограниченной группы пользователей. По результатам проверки код отправляется на доработку или согласуется.

Развертывание. Текущая версия программы размещается на продакшн-серверах разработчика. Заказчик может работать с программой, исследовать ее функции, искать уязвимости.

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

Планирование. На основании данных, полученных при изучении пользовательского опыта, разработчик подготавливает план доработок, включающий новые функции, исправление ошибок и т.д. После этого он вносит все корректировки в продукт — и цикл разработки начинается снова.

Таким образом, рабочий процесс по методологии CI/CD включает как последовательные, так и параллельные этапы. Именно для распараллеливания в рабочем пространстве создается побочная ветка — в ней проще вести работу, не вмешиваясь в основной код до тех пор, пока программируемый модуль не будет готов к интеграции. Условно рабочий процесс по методологии CI/CD можно представить в виде следующей схемы:

Преимущества CI/CD

• Сокращение сроков разработки. Методология уменьшает время доработок до нескольких дней, в сложных проектах — недель. Это позволяет разработчикам быстрее тестировать и опробовать нововведения, а затем внедрять их в продукт раньше конкурентов.
• Отбор перспективных вариантов. Быстрое тестирование и большое количество итераций позволяют разработчику вовремя отсеивать бесперспективные варианты кода на начальных этапах. Это также способствует экономичному расходованию времени и ресурсов без их распыления на тупиковые направления.
• Качество тестирования. Сочетание ручной и автоматизированной проверки позволяет выявлять ошибки на ранних этапах разработки. Это снижает вероятность их накопления на этапе релиза, что еще больше сокращает время работы над проектом.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Недостатки CI/CD

• Высокие требования к опыту. Рабочий процесс в любой компании можно перевести на методологию CI/CD. Однако это требует от разработчиков как знания самой концепции на практическом уровне, так и умения быстро реорганизовать процессы в самой организации. Иными словами, CI/CD имеет достаточно большой порог вхождения в сравнении со многими традиционными методологиями.
• Сложность постоянного взаимодействия. Непрерывная интеграция и доставка программного продукта требуют от разработчиков высокой скоординированности действий. На практике это означает, что должно быть отдельное лицо, которое занимается организацией рабочего процесса и налаживанием взаимодействия между членами команды.

Инструменты для CI/CD

Так как непрерывная интеграция и развертывание подразумевает автоматизацию многих процессов в ходе разработки, для этого созданы различные программные инструменты и сервисы:

• GitLab. Эта платформа позволяет управлять хранилищами проекта, документировать результаты тестирования и доработок, анализировать и дополнять функциональность проекта, выявлять и устранять ошибки.
• Docker. СD-система, позволяющая контейнеризировать проект, то есть упаковать его со всем окружением и зависимостями.
• Travis-CI. Сервер, который можно подключать к виртуальным репозиториям GitHub с минимальными настройками. Благодаря использованию облачных технологий его не нужно отдельно устанавливать.
• Jenkins. Один из самый популярных DevOps-инструментов, совместимый со всевозможными плагинами для адаптации под различные проекты и задачи.
• PHP Censor. CI-сервер, автоматизирующий сборку PHP-проектов. Может работать с репозиториями GitLab, Mercurial и другими, с библиотеками для тестирования Atoum, PHP Spec, Behat.

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

IT-специалист с нуля

Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

Статьи по теме:

Что такое CI (Continuous Integration)

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Что такое CI

CI — это сборка, деплой и тестирование приложения без участия человека. Сейчас объясню на примере.

Допустим, что у нас есть два разработчика — Маша и Ваня. И тестировщица Катя.

Маша пишет код. Добавляет его в систему контроля версий (от англ. Version Control System, VCS). Это что-то типа дропбокса для кода — место хранения, где сохраняются все изменения и в любой момент можно посмотреть кто, что и когда изменял.

Потом Ваня заканчивает свой кусок функционала. И тоже сохраняет код в VCS.

Но это просто исходный код — набор файликов с расширением .java, или любым другим. Чтобы Катя могла протестировать изменения, нужно:

1. Собрать билд из исходного кода
2. Запустить его на тестовой машине

Собрать билд можно вручную, но это лишний геморрой: нужно помнить, что в каком порядке запустить, какие файлики зависят друг от друга, не ошибиться в команде… Обычно используют специальную программу. Для java это Ant, Maven или Gradle. С помощью сборщика вы один раз настраиваете процесс сборки, а потом запускаете одной командой. Пример запуска для Maven:

mvn clean install

Это полуавтоматизация — все равно нужен человек, который введет команду и соберет билд «ручками». Допустим, этим занимаются разработчики. Когда Катя просит билд на тестирование, Ваня обновляет версию из репозитория и собирает билд.

Но собрать билд ≠ получить приложение для тестирования. Его еще надо запустить! Этим занимается сервер приложения. Серверы бывают разные: wildfly, apache, jetty…

Если это wildfly, то нужно:

1. Подложить билд в директорию standalone/deployments
2. Запустить сервер (предварительно один раз настроив службу)

А вот если убрать из этой схемы человека — мы получим CI!

CI — это приложение, которое позволяет автоматизировать весь процесс. Оно забирает изменения из репозитория с кодом. Само! Тут есть два варианта настройки:

CI опрашивает репозиторий «Эй, ку-ку, у тебя есть изменения??» раз в N часов / минут, как настроите.

Репозиторий машет CI рукой при коммите: «Эй, привет! А у меня обновление тут появилось!» (это git hook или аналог в вашей VCS)

Когда CI получило изменения, оно запускает сборку билда и автотесты.

Если сборка провалилась (тесты упали, или не получилось собрать проект), система пишет электронное письмо всем заинтересованным лицам:

• Менеджеру проекта (чтобы знал, что делается!)
• Разработчику, который внес изменения
• Любому другому — как настроите, так и будет.

Если сборка прошла успешно, CI разворачивает приложение на тестовой машине. И в итоге Катька может тестировать новую сборку!

Да, разумеется, один раз придется это все настроить — рассказать серверу CI, откуда забирать изменения, какие автотесты запускать, как собирать проект, куда его потом билдить… Но зато один раз настроил — а дальше оно само!

Автотесты тоже придется писать самим, но чтож поделать =)

Если на пальцах, то система CI (Continuous Integration) – это некая программа, которая следит за вашим Source Control, и при появлении там изменений автоматически стягивает их, билдит, гоняет автотесты (конечно, если их пишут).

В случае неудачи она дает об этом знать всем заинтересованным лицам, в первую очередь – последнему коммитеру. (с) habr.com/ru/post/352282

Программы CI

Наиболее популярные — Jenkins и TeamCity.

Но есть куча других вариаций — CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Server.

Как это выглядит

Давайте посмотрим, как это выглядит с точки зрения пользователя. Я покажу на примере системы TeamCity.

Когда я захожу в систему, я вижу все задачи. Задачи бывают разные:

• Собрать билд
• Прогнать автотесты
• Развернуть приложение на тестовом стенде
• Прогнать на этом стенде GUI тесты (или тесты Postman-a)
• Оповестить всех заинтересованных по email о результатах сборки и тестирования

• CDI Archetype и CDI Core — это билды. Они проверяют, что приложение вообще собирается. Отрабатывают за пару минут и прогоняются на каждое изменение кода.
• CDI Core with tests — сборка проекта со всеми автотестами, которых, как видно на скрине, 4000+ штук. Тесты идут полчаса, но тоже прогоняются на каждый коммит.

Это нужно, чтобы:

• Перезапустить тесты, исправив косяк — это ведь может быть настройки окружения, а не кода. Поэтому исправление настройки не перезапустит тесты, которые следят только за системой контроля версий кода.
• Перезапустить билд, если TeamCIty настроен проверять изменения раз в час — а нам нужно сейчас проверить исправления
• Перезапустить билд, если в VCS исправления вносились не в этот проект, а в связанный.
• Проверить стабильность падения — иногда тесты падают по неведомым причинам, а если их перезапустить, отработают успешно.

Поэтому, даже если я не подписана на оповещения на электронную почту о состоянии сборок, я легко могу посмотреть, в каком состоянии сейчас система. Открываешь графический интерфейс программы и смотришь.

Как CI устроен

Как и где CI собирает билд и прогоняет автотесты? Я расскажу на примере TeamCity, но другие системы работают примерно также.

Сам TeamCity ничего не собирает. Сборка и прогон автотестов проходят на других машинах, которые называются «агенты»:

«Агент» — это простой компьютер. Железка или виртуальная машина, не суть. Но как этот комьютер понимает, что ему надо сделать?

В TeamCity есть сервер и клиент. Сервер — это то самое приложение, в котором вы потом будете тыкать кнопочки и смотреть красивую картинку «насколько все прошло успешно». Он устанавливается на одну машину.

А приложение-«клиент» устанавливается на машинах-«агентах». И когда мы нажимаем кнопку «Run» на сервере:

Сервер выбирает свободного клиента и передает ему все инструкции: что именно надо сделать. Клиент собирает билд, выполняет автотесты, собирает результат и возвращает серверу: «На, держи, отрисовывай».

Сервер отображает пользователю результат плюс рассылает email всем заинтересованным лицам.

При этом мы всегда видим, на каком конкретно агенте проходила сборка:

И можно самому выбирать, где прогонять автотесты. Потому что бывает, что автотесты падают только на одном билд-агенте. Это значит, что у него что-то не так с конфигурацией.

Допустим, исходно у нас был только один билд-агент — Buran. Название может быть абсолютно любым, его придумывает администратор, когда подключает новую машину к TeamCity как билд-агента.

Мы собирали на нем проект, проводили автотесты — все работало. А потом закупили вторую машинку и назвали Apollo. Вроде настроили также, как Буран, даже операционную систему одинаковую поставили — CentOs 7.

Но запускаем сборку на Apollo — падает. Причем падает странно, не хватает памяти или еще чего-то. Перезапускаем на Apollo — снова падает. Запускаем на Буране — проходит успешно!

Начинаем разбираться и выясняем, что в Apollo забыли про какую-то настройку. Например, не увеличили количество открытых файловых дескриптеров. Исправили, прогнали сборку на Apollo — да, работает, ура!

Мы также можем для каждой сборки настроить список агентов, на которых она может выполняться. Зачем? Например, у нас на половине агентов линукс, а на половине винда. А сборку мы только под одну систему сделали. Или на винде вылезает какой-то плавающий баг, но исправлять его долго и дорого, а все клиенты на линуксе — ну и зачем тогда?

А еще бывает, что агентов делят между проектами, чтобы не было драки — этот проект использует Бурана и Аполло, а тот Чип и Дейла. Фишка ведь в том, что на одном агенте может выполняться только одно задание. Поэтому нет смысла покупать под агент крутую тачку, сразу кучу тестов там все равно не прогнать.

В итоге как это работает: сначала админ закупает компьютеры под «агенты» и устанавливает на них клиентское приложение TeamCity. Слишком крутыми они быть не должны, потому что много задач сразу делать не будут.

При этом TeamCity вы платите за количество лицензий на билд-агентов. Так что чем меньше их будет, тем лучше.

На отдельной машине админ устанавливает сервер TeamCity. И конфигурирует его — настраивает сборки, указывает, какие сборки на каких машинах можно гонять, итд. На сервере нужно место для хранения артефактов — результатов выполнения сборки.

У нас есть два проекта — Единый клиент и Фактор, которые взаимодействуют между собой. Тестировщик Единого клиента может не собирать Фактор локально. Он запускает сборку в TeamCity и скачивает готовый билд из артефактов!

Дальше уже разработчик выбирает, какую сборку он хочет запустить и нажимает «Run». Что в этот момент происходит:

1. Сервер TeamCity проверяет по списку, на каких агентах эту сборку можно запускать. Потом он проверяет, кто из этих агентов в данный момент свободен:

Нашел свободного? Отдал ему задачку!

Если все агенты заняты, задача попадает в очередь. Очередь работает по принципу FIFO — first in, first out. Кто первый встал — того и тапки.

Очередь можно корректировать вручную. Так, если я вижу, что очередь забита сборками, которые запустила система контроля версий, я подниму свою на самый верх. Если я вижу, что сборки запускали люди — значит, они тоже важные, придется подождать.

Это нормальная практика, если мощностей агентов не хватает на всей и создается очередь. Смотришь, кто ее запустил:

• Робот? Значит, это просто плановая проверка, что ничего лишнего не разломалось. Такая может и подождать 5-10-30 минут, ничего страшного
• Коллега? Ему эта сборка важна, раз не стал ждать планового запуска. Встаем в очередь, лезть вперед не стоит.

• поднять свою очередь на самый верх, чтобы она запустилась на первом же освободившемся агенте
• зайти на агент, отменить текущую сборку
• перезапустить ее! Хоть она и попадет в самый низ очереди, но просто отменять сборку некрасиво

3. Сервер отрисовывает результат в графическом интерфейсе и сохраняет артефакты. Так я могу зайти в TeamCity и посмотреть в артефактах полные логи прошедших автотестов, или скачать сборку проекта, чтобы развернуть ее локально.

Настоятельно рекомендуется настроить заранее количество сборок, которые CI будет хранить. Потому что если в артефактах лежат билды по 200+ мб и их будет много, то очередной запуск сборки упадет с ошибкой «кончилось место на диске»:

4. Сервер делает рассылку по email — тут уж как настроите. Он может и позитивную рассылку делать «сборка собралась успешно», а может присылать почту только в случае неудачи «Ой-ей-ей, что-то пошло не так!».

Интеграция с VCS

Я говорила о разных вариантах настройки интеграции CI — VCS:

CI опрашивает репозиторий «Эй, ку-ку, у тебя есть изменения??» раз в N часов / минут, как настроите.

Репозиторий машет CI рукой при коммите: «Эй, привет! А у меня обновление тут появилось!» (это git hook или аналог в вашей VCS)

Но когда какой используется?

Лучше всего, конечно, чтобы система контроля версий оповещала сервер CI. И запускать весь цикл на каждое изменение: собрать, протестировать, задеплоить. Тогда любое изменение кода сразу попадет на тестовое окружение, которое будет максимально актуальным.

Плюс каждое изменение прогоняет автотесты. И если тесты упадут, сразу ясно, чей коммит их сломал. Ведь раньше работало и после Васиных правок вдруг сломалось — значит, это его коммит привел к падению. За редким исключением, когда падение плавающее.

Но в реальной жизни такая схема редко применима. Только подумайте — у вас ведь может быть много проектов, много разработчиков. Каждый что-то коммитит ну хотя бы раз в полчаса. И если на каждый коммит запускать 10 сборок по полчаса — очереди в TeamCity никогда не разгребутся!

У нас у одного из продуктов есть core-модуль, а есть 15+ Заказчиков. В каждом свои автотесты. Сборка заказчика — это core + особенности заказчика. То есть изменение в корневом проекте может повлиять на 15 разных сборок. Значит, их все надо запустить при коммите в core.

Когда у нас было 4 билд-агента, все-все-все сборки и тесты по этим заказчикам запускались в ночь на вторник. И к 10 утра в TeamCity еще была очередь на пару часов.

Другой вариант — закупить много агентов. Но это цена за саму машину + за лицензию в TeamCity, что уже сильно дороже, да еще и каждый месяц платить.

Поэтому обычно делают как:

1. Очень быстрые и важные сборки можно оставить на любой коммит — если это займет 1-2 минуты, пусть гоняется.

2. Остальные сборки проверяют, были ли изменения в VCS — например, раз в 15 минут. Если были, тогда запускаем.

3. Долгие тесты (например, тесты производительности) — раз в несколько дней ночью.

CI в тестировании

Если мы говорим о разработке своего приложения, то тестирование входит в стандартный цикл. Вы или ваши разработчики пишут автотесты, которые потом гоняет CI. Это могут быть unit, api, gui или нагрузочные тесты.

Но что, если вы тестируете черный ящик? Приложение есть, исходного кода нету. Это суровые реалии тестировщиков интеграции — поставщик отдает вам новый релиз приложения, который нужно проверить перед тем, как ставить в продакшен.

Вот, допустим, у вас есть API-тесты в Postman-е. Или GUI-тесты в Selenium. Можно ли настроить цикл CI для них?

CI не ставит жестких рамок типа «я работаю только в проектах с автотестами» или «я работаю только когда есть доступ к исходному коду». Он может смотреть в систему контроля версий, а может и не смотреть. Это необязательное условие!

Написали автотесты? Скажите серверу CI, как часто их запускать — и наслаждайтесь результатом =)

Итого

CI — непрерывная интеграция. Это когда ваше приложение постоянно проверяется: все ли с ним хорошо? Проходят ли тесты? Собирается ли сборка? Причем все проверки проводятся автоматически, без участия человека.

Особенно актуально для команд, где над кодом одного приложения трудятся несколько разработчиков. Как это бывает? По отдельности части программы работают, а вот вместе уже нет. CI позволяет очень быстро обнаружить такие проблемы. А чем быстрее найдешь — тем дешевле исправить.

Отсюда и название — постоянная проверка интеграции кусочков кода между собой.
Типичные задачи CI:

• Проверить, было ли обновление в коде
• Собрать билд
• Прогнать автотесты
• Развернуть приложение на тестовом стенде
• Прогнать на этом стенде GUI тесты (или тесты Postman-a)
• Оповестить всех заинтересованных по email о результатах сборки и тестирования

И все это — автоматически, без вмешательства человека! То есть один раз настроили, а дальше оно само.

Если в проекте настроен CI, у вас будут постоянно актуальные тестовые стенды. И если в коде что-то сломается, вы узнаете об этом сразу, сервер CI пришлет письмо. А еще можно зайти в графический интерфейс и посмотреть — все ли сборки успешные, а тесты зеленые? Оценить картину по проекту за минуту.

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

• Веб-разработка
• Тестирование IT-систем
• Тестирование веб-сервисов
• DevOps

Что такое непрерывная интеграция?

Непрерывная интеграция – это практика разработки программного обеспечения DevOps, при которой разработчики регулярно объединяют изменения программного кода в центральном репозитории, после чего автоматически выполняется сборка, тестирование и запуск. Понятие непрерывной интеграции чаще всего применяется к стадии сборки или интеграции процесса выпуска ПО и включает в себя как компонент автоматизации (например, сервис непрерывной интеграции или сборки), так и компонент культуры разработки (например, обучение частой интеграции). Главная задача непрерывной интеграции – быстрее находить и исправлять ошибки, улучшать качество ПО и сокращать временные затраты на проверку и выпуск новых обновлений ПО.

Зачем нужна непрерывная интеграция?

Раньше разработчики одной команды могли в течение долгого времени работать изолированно и объединяли свои изменения с основной частью проекта только по завершении собственной работы. Это делало слияние кода сложной и трудоемкой задачей, к тому же ошибки накапливались и не исправлялись в течение долгого времени. Такие факторы затрудняли быструю доставку обновлений пользователям.

Как работает непрерывная интеграция?

При непрерывной интеграции разработчики часто подтверждают записи в совместно используемый репозиторий, используя систему контроля версий, например Git. Перед каждым подтверждением записи разработчики могут запускать локальные модульные тесты программного кода в качестве дополнительного уровня проверки перед интеграцией. Сервис непрерывной интеграции автоматически выполняет сборку и запуск модульных тестов для изменений кода, что позволяет моментально выявлять ошибки.

Непрерывная интеграция относится к стадии сборки и модульного тестирования процесса выпуска ПО. Каждое подтвержденное изменение кода запускает автоматический процесс сборки и тестирования.

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