Rsd detection ci что это
10 популярных инструментов для CI/CD
Непрерывная интеграция позволяет разработчикам получать немедленный отчет при обнаружении дефекта в коде и быстро его исправлять. На рынке доступно множество инструментов для непрерывной интеграции, у каждого — свои особенности и функции.
Перевели статью со списком популярных инструментов непрерывной интеграции. В него вошли как открытые, так и проприетарные инструменты, которые хорошо интегрируются в CI/CD.
1. Jenkins
Jenkins — открытое серверное приложение, которое позволяет разработчикам быстрее строить, автоматизировать и тестировать любой проект. Изначально Jenkins был частью проекта Hudson, созданного Kohsuke Kawaguchi в 2004 году. Позднее, в 2011 году, Jenkins отделился и сменил название. Сегодня это один из самых известных инструментов интеграции.
Ключевые преимущества:
Открытое программное обеспечение.
Jenkins написан на Java с вкраплениями Groovy, Ruby и Antlr.
Есть около 1400 плагинов, которые помогают в сборке, автоматизации и развертывании любого программного проекта.
Легко инсталлируется в любой операционной системе.
Дружественный интерфейс, который легко конфигурировать и обновлять.
2. Buddy
Buddy — веб-инструмент для непрерывной интеграции и доставки с дружественным интерфейсом. Известен в качестве одного из самых надежных и простых инструментов CI/CD.
Разработчики Git могут использовать его для создания, тестирования и развертывания веб-сайтов и приложений с использованием кода с GitРub, Bitbucket и GitLab.
Ключевые преимущества:
Можно кастомизировать шаги для запуска контейнеров, автоматизации развертывания и настройки мониторинга.
Сборка, доставка и развертывание — встроенные функции стека.
Можно развернуть на любом хостинге или в облаке.
Поддерживает Grunt, Gulp, MongoDB и MySQL.
Отчеты о прогрессе в реальном времени, журналы и историю можно отслеживать.
Сборка и тесты в контейнерах Docker.
3. TeamCity
TeamCity — инструмент непрерывной интеграции, разработанный JetBrains и выпущенный в 2006 году. Работает в среде Java, используется для создания и развертывания различных проектов. TeamCity поддерживает интеграцию со многими облачными платформами.
Ключевые преимущества:
Бесплатный и открытый исходный код.
Легко интегрируется с IDE: Eclipse, IntelliJ IDEA, Visual studio.
Проверяет покрытие кода, инспектирует и выявляет дубликаты, создает историю изменений.
Поддерживает запуск нескольких сборок и тестов для различных платформ и окружений.
4. Bamboo CI
Bamboo — еще один инструмент CI/CD, разработанный Atlassian. Написан на Java, поддерживает другие языки и технологии, например, CodeDeply, Ducker, Maven, Git, SVN, Mercurial, Ant, AWS, Amazon.
Инструмент выполняет автоматическую сборку, тестирование и развертывание. В итоге экономит время разработчиков и позволяет сосредоточиться на стратегических вопросах.
Ключевые преимущества:
Bamboo может собирать, тестировать и развертывать несколько проектов одновременно.
При любом сбое сборки предоставляет анализ и отчеты об ошибках.
Можно отслеживать текущее состояние сборок и состояние сервера с помощью REST API, который предоставляет Bamboo.
Поддерживает утилиты тестирования PHPUnit, JUnit, Selenium.
Совместим с BitBucket.
Интегрируется с JIRA, Confluence и Clover от Atlassian, что позволяет выполнять все операции в одном месте.
Поддерживает импорт из Jenkins.
5. Gitlab CI
GitLab CI — законченная платформа управления кодом с несколькими мини-инструментами, каждый из которых выполняет свой набор функций для полного SDLC. Обеспечивает анализ представлений кода, управление ошибками и CI/CD в едином веб-хранилище.
Ключевые преимущества:
Прямая интеграция с GitLab Workflow.
Отображает всю важную информацию о прогрессе на одной панели.
Версия для сообщества бесплатная, корпоративная — платная.
Командные сценарии сборки можно программировать на любом языке.
Предоставляет API для лучшей интеграции продуктов.
6. Circle CI
Circle CI — один из лучших инструментов CI/CD из доступных на рынке. Предоставляет отличную платформу для автоматизации сборки и тестирования, а также для комплексного процесса развертывания.
Circle CI интегрируется с GitHub, GitHub Enterprise и Bitbucket для создания сборок и поддерживает непрерывную интеграцию в облаке.
Ключевые преимущества:
Легко интегрируется с Bitbucket, GitHub и GitHub Enterprise.
Позволяет организовать развертывание на основе веток кода.
Простая очистка ошибок, быстрый запуск тестов и легкая настройка.
Интегрируется с облачными сервисами.
Простая интеграция с утилитами сборки, например, с Maven или Gradle.
7. Codeship
Codeship — инструмент CI, приобретенный Cloudbees. Эффективен, прост, разворачивает код непосредственно из GitHub и Bitbucket. Как только код автоматически протестирован, получается надежное развертывание благодаря комбинации функций интеграции и доставки.
Ключевые преимущества:
8. CruiseControl
Ключевые преимущества:
9. Buildbot
Buildbot — платформа непрерывной интеграции для разработки программного обеспечения, которая позволяет выполнять автоматическую компиляцию и тестирование для проверки любых изменений, произошедших в проекте. Написана на Python.
Платформа популярна для комплексного автоматизированного тестирования процессов жизненного цикла разработки и развертывания приложений. Buildbot — один из инструментов, позволяющих распределять и выполнять задачи параллельно на разных платформах.
Ключевые преимущества:
CI, CD и снова CD: принцип работы и отличия
Несмотря на общие тенденции к автоматизации процессов разработки, все еще можно встретить компании, в которых тестирование и развертывание никак не автоматизировано. Отсутствие автоматизированных процессов влияет на скорость доставки изменений и увеличивает влияние человеческого фактора, что негативно отражается на всей компании в целом, а не только на самом отделе разработки.
В этой статье я постараюсь объяснить разницу между процессами непрерывной интеграции (Continuous Integration/CI), непрерывной доставки (Continuous Delivery/CD) и непрерывного развертывания (Continuous Deployment/CD). Мало кто разделяет два последних термина, но мы все-таки рассмотрим их по отдельности для общего понимания.
Continuous Integration (CI)
Процесс непрерывной интеграции (Continuous Integration) нацелен на автоматизированную проверку интеграции между изменениями разработчика и остальным кодом.
В этот процесс может входить статический анализ кода на уязвимости и несоответствие общим практикам разработки, сборка приложения и автоматизированное тестирование с динамической проверкой на уязвимости.
Автоматизация процессов CI позволяет ускорить процесс разработки, устраняя рутинные операции по ручной проверке интеграции с остальным кодом и сокращая нагрузку на отдел тестирования благодаря более раннему нахождению проблем интеграции с остальными частями приложения. Кроме того, у разработчика не выйдет сэкономить себе время, отправив изменения на тестирование без какой-либо проверки.
Continuous Delivery (CD)
Целью этого этапа является доставка измененной версии приложения в эксплуатацию.
Так, процессом доставки Docker-образов является обычная загрузка образа в реестр образов Docker и последующая его загрузка с хостовой машины. В системах с повышенными требованиями безопасности также может встречаться ситуация, в которой Docker-хосты не имеют доступа к каким-либо реестрам, и в таком случае может применяться доставка Docker-образов с применением команд docker save и docker load.
В системах без использования Docker доставка может быть реализована посредством SCM, apt/yum-репозиториев, ssh, S3-совместимого хранилища для образов VM (собранных с использованием, например, Packer) и многих других способов, область применения которых, опять же, во многом зависит от возникающих требований и удобства поддержки.
В вышеуказанном примере с Docker изменения будут доставлены вместе с новым образом через загрузку в реестр образов Docker.
Автоматизация процессов CD позволяет ускорить процесс доставки, исключить влияние человеческого фактора, а также сделать доставку более доступной для остальных членов команды.
Continuous Deployment (CD)
Процесс нацелен на развертывание новой версии приложения в окружение эксплуатации или тестирования. Обычно этот этап не выделяют как отдельный, развертывание включают в процесс доставки. Он зависит от предъявляемых к нему требований и используемых инструментов, но, как правило, вариант реализации процесса лежит на поверхности.
Инструменты CI/CD
Есть множество SaaS-решений, для обзора которых потребовалась бы отдельная статья. Остановимся на основных решениях, которые легко интегрируются в подавляющем большинстве случаев:
Подробный разбор процессов на вымышленном примере
Представим возможный процесс в вымышленной IT-компании и возможные требования, которые предъявляются от заинтересованных сторон. Возьмем небольшой IT-отдел, в котором присутствуют команды разработки, тестирования и эксплуатации. Рабочий процесс построен по Git-flow, а развертывание выполняется на Docker-хостах. Опишем основные требования каждой из сторон в формате таблицы.
Команда
Требования
Процессы CI/CD не должны отнимать много времени (отсутствие избыточных действий).
Требуется простой для понимания процессов CI/CD (описание процесса в виде кода с минимумом ручных действий).
По возможности процессы CI/CD во всех проектах должны быть похожи друг на друга (порог вхождения в новый проект).
Требуется возможность быстрого отката изменений в случае возникших проблем (устранение влияния человеческого фактора на процесс развертывания).
Тестирование должно быть по возможности автоматизировано (правка от разработчика уже как минимум не приводит к нарушению работоспособности остальных частей системы).
Должна быть возможность простого развертывания разных версий приложения для исследования регрессий (автоматизация процессов развертывания новых окружений).
Необходим простой способ развертывания окружения с несколькими сервисами для интеграционного тестирования без необходимости привлекать другие отделы (простота использования).
Требуется минимизация простоя между развертываниями приложений (развертывание без простоя и минимизация человеческого фактора при развертывании новых версий).
Необходима возможность быстро доставлять новую функциональность пользователям для тестирования гипотез (автоматизация процессов и отсутствие избыточных действий).
После сбора требований мы можем сформировать примерный вид процессов CI/CD в команде:
Разбор по части CI
Процесс интеграции не обязательно должен быть общим во всех случаях, намного удобнее описать различные сценарии для каждой ситуации. Давайте опишем возможные ситуации в качестве примера:
Почему нельзя построить общий процесс CI? В этом просто нет смысла – если выполнять сборку образа для интеграционного тестирования после ручного подтверждения для релизной ветки, то неминуемо случится ситуация, в которой про необходимость ручного запуска сборки просто забудут, и отдел тестирования будет проверять неактуальную версию приложения. Проводить проверку соответствия стандартам кодирования и юнит/функциональное тестирование на версии, помеченной тегом, – пустая трата времени, ведь все изменения уже есть в релизной ветке.
Чем больше будет автоматизированных задач, тем больше бессмысленной работы будет выполнено в общем процессе.
Разбор по части CD (Delivery)
В нашем случае доставкой является загрузка Docker-образа с приложением в Registry, из которого образы будут загружены на конкретный Docker-хост в процессе развертывания. Реестр может быть как общим, так и отдельным – для окружения разработки и тестирования и окружения эксплуатации. Тут все зависит от требований безопасности в конкретной компании.
Разбор по части CD (Deployment)
В нашем случае деплой в окружение эксплуатации может выполняться путем перенаправления всех новых HTTP-запросов на новый экземпляр приложения (основываясь на том, что максимальное время запроса ограничено сверху разумным лимитом для обеспечения развертывания без простоя).
Небольшим проектам или проектам без необходимости создания собственной инфраструктуры стоит обратить внимание на облачные хостинги, которые позволяют автоматизировать разработку проекта, налаживая процессы CI/CD.
Выводы
Надеюсь, теперь вы точно разобрались в отличиях CI и CD, а также поняли всю важность автоматизации данных процессов.
Подведем итог по всему вышесказанному – внедрение CI/CD само по себе является непрерывным процессом и постоянно видоизменяется в зависимости от новых требований отдельно взятой компании. В то же время процессы CI/CD требуют дополнительных инструментов и времени на внедрение, которое можно сократить, используя уже готовые сервисы для их автоматизации.
Поэтому вывод о необходимости автоматизации того или иного процесса каждый должен сделать для себя сам. Я считаю, что автоматизация рассмотренных процессов должна присутствовать в каждой компании, которая связана с разработкой.
Rsd detection ci что это
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:
Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.
Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
CI — это сборка, деплой и тестирование приложения без участия человека. Сейчас объясню на примере.
Допустим, что у нас есть два разработчика — Маша и Ваня. И тестировщица Катя.
Маша пишет код. Добавляет его в систему контроля версий (от англ. Version Control System, VCS). Это что-то типа дропбокса для кода — место хранения, где сохраняются все изменения и в любой момент можно посмотреть кто, что и когда изменял.
Потом Ваня заканчивает свой кусок функционала. И тоже сохраняет код в VCS.
Сборка билда — это когда мы из набора файликов исходного кода создаем один запускаемый файл:
Собрать билд можно вручную, но это лишний геморрой: нужно помнить, что в каком порядке запустить, какие файлики зависят друг от друга, не ошибиться в команде… Обычно используют специальную программу. Для java это Ant, Maven или Gradle. С помощью сборщика вы один раз настраиваете процесс сборки, а потом запускаете одной командой. Пример запуска для Maven:
Это полуавтоматизация — все равно нужен человек, который введет команду и соберет билд «ручками». Допустим, этим занимаются разработчики. Когда Катя просил билд на тестирование, Ваня обновляет версию из репозитория и собирает билд.
Но собрать билд ≠ получить приложение для тестирования. Его еще надо запустить! Этим занимается сервер приложения. Серверы бывают разные: wildfly, apache, jetty…
Если это wildfly, то нужно:
И это снова полуавтоматизация. Потому что разработчик скопировать получившийся после сборки архив на тестовый стенд и включить службу. Да, это делается парой команд, но все равно человеком.
А вот если убрать из этой схемы человека — мы получим CI!
CI — это приложение, которое позволяет автоматизировать весь процесс. Оно забирает изменения из репозитория с кодом. Само! Тут есть два варианта настройки:
Когда CI получило изменения, оно запускает сборку билда и автотесты.
Если сборка провалилась (тесты упали, или не получилось собрать проект), система пишет элекронное письмо всем заинтересованным лицам:
Если сборка прошла успешно, CI разворачивает приложение на тестовой машине. И в итоге Катька может тестировать новую сборку!
Да, разумеется, один раз придется это все настроить — рассказать серверу CI, откуда забирать изменения, какие автотесты запускать, как собирать проект, куда его потом билдить… Но зато один раз настроил — а дальше оно само!
Автотесты тоже придется писать самим, но чтож поделать =)
Если на пальцах, то система CI (Continuous Integration) – это некая программа, которая следит за вашим Source Control, и при появлении там изменений автоматически стягивает их, билдит, гоняет автотесты (конечно, если их пишут).
В случае неудачи она дает об этом знать всем заинтересованным лицам, в первую очередь – последнему коммитеру. (с) habr.com/ru/post/352282
Наиболее популярные — Jenkins и TeamCity.
Но есть куча других вариаций — CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Serve.
Как это выглядит
Давайте посмотрим, как это выглядит с точки зрения пользователя. Я покажу на примере системы TeamCity.
Когда я захожу в систему, я вижу все задачи. Задачи бывают разные:
Задачи можно группировать. Вот, скажем, у нас есть проект CDI. Зайдя внутрь, я вижу задачи именно по этому проекту:
Помимо автоматизированного запуска, я могу в любой момент пересобрать билд, нажав на кнопку «Run»:
Когда я заходу внутрь любой задачи — я вижу историю сборок. Когда она запускалась? Кто при этом вносил изменения и сколько их было? Сколько тестов прошло успешно, а сколько развалилось?
Поэтому, даже если я не подписана на оповещения на электронную почту о состоянии сборок, я легко могу посмотреть, в каком состоянии сейчас система. Открываешь графический интерфейс программы и смотришь.
Как 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. Кто первый встал — того и тапки.
Очередь можно корректировать вручную. Так, если я вижу, что очередь забита сборками, которые запустила система контроля версий, я подниму свою на самый верх. Если я вижу, что сборки запускали люди — значит, они тоже важные, придется подождать.
Это нормальная практика, если мощностей агентов не хватает на всей и создается очередь. Смотришь, кто ее запустил:
Иногда можно даже отменить сборку от системы контроля версий, если уж очень припекло, а все агенты занятами часовыми тестами. В таком случае можно:
2. Агент выполняет задачу и возвращает серверу результат
3. Сервер отрисовывает результат в графическом интерфейсе и сохраняет артефакты. Так я могу зайти в TeamCity и посмотреть в артефактах полные логи прошедших автотестов, или скачать сборку проекта, чтобы развернуть ее локально.
Настоятельно рекомендуется настроить заранее количество сборок, которые CI будет хранить. Потому что если в артефактах лежат билды по 200+ мб и их будет много, то очередной запуск сборки упадет с ошибкой «кончилось место на диске»:
4. Сервер делает рассылку по email — тут уж как настроите. Он может и позитивную рассылку делать «сборка собралась успешно», а может присылать почту только в случае неудачи «Ой-ей-ей, что-то пошло не так!».
Интеграция с VSC
Я говорила о разных вариантах настройки интеграции CI — VSC:
Но когда какой используется?
Лучше всего, конечно, чтобы система контроля версий оповещала сервер CI. И запускать весь цикл на каждое изменение: собрать, протестировать, задеплоить. Тогда любое изменение кода сразу попадет на тестовое окружение, которое будет максимально актуальным.
Плюс каждое изменение прогоняет автотесты. И если тесты упадут, сразу ясно, чей коммит их сломал. Ведь раньше работало и после Васиных правок вдруг сломалось — значит, это его коммит привел к падению. За редким исключением, когда падение плавающее.
Но в реальной жизни такая схема редко применима. Только подумайте — у вас ведь может быть много проектов, много разработчиков. Каждый что-то коммитит ну хотя бы раз в полчаса. И если на каждый коммит запускать 10 сборок по полчаса — очереди в TeamCity никогда не разгребутся!
У нас у одного из продуктов есть core-модуль, а есть 15+ Заказчиков. В каждом свои автотесты. Сборка заказчика — это core + особенности заказчика. То есть изменение в корневом проекте может повлиять на 15 разных сборок. Значит, их все надо запустить при коммите в core.
Когда у нас было 4 билд-агента, все-все-все сборки и тесты по этим заказчикам запускались в ночь на вторник. И к 10 утра в TeamCity еще была очередь на пару часов.
Другой вариант — закупить много агентов. Но это цена за саму машину + за лицензию в TeamCity, что уже сильно дороже, да еще и каждый месяц платить.
Поэтому обычно делают как:
1. Очень быстрые и важные сборки можно оставить на любой коммит — если это займет 1-2 минуты, пусть гоняется.
2. Остальные сборки проверяют, были ли изменения в VSC — например, раз в 15 минут. Если были, тогда запускаем.
3. Долгие тесты (например, тесты производительности) — раз в несколько дней ночью.
CI в тестировании
Если мы говорим о разработке своего приложения, то тестирование входит в стандартный цикл. Вы или ваши разработчики пишут автотесты, которые потом гоняет CI. Это могут быть unit, api, gui или нагрузочные тесты.
Но что, если вы тестируете черный ящик? Приложение есть, исходного кода нету. Это суровые реалии тестировщиков интеграции — поставщик отдает вам новый релиз приложения, который нужно проверить перед тем, как ставить в продакшен.
Вот, допустим, у вас есть API-тесты в Postman-е. Или GUI-тесты в Selenium. Можно ли настроить цикл CI для них?
CI не ставит жестких рамок типа «я работаю только в проектах с автотестами» или «я работаю только когда есть доступ к исходному коду». Он может смотреть в систему контроля версий, а может и не смотреть. Это необязательное условие!
Написали автотесты? Скажите серверу CI, как часто их запускать — и наслаждайтесь результатом =)
Итого
CI — непрерывная интеграция. Это когда ваше приложение постоянно проверяется: все ли с ним хорошо? Проходят ли тесты? Собирается ли сборка? Причем все проверки проводятся автоматически, без участия человека.
Особенно актуально для команд, где над кодом одного приложения трудятся несколько разработчиков. Как это бывает? По отдельности части программы работают, а вот вместе уже нет. CI позволяет очень быстро обнаружить такие проблемы. А чем быстрее найдешь — тем дешевле исправить.
Отсюда и название — постоянная проверка интеграции кусочков кода между собой.
Типичные задачи CI:
И все это — автоматически, без вмешательства человека! То есть один раз настроили, а дальше оно само.
Если в проекте настроен CI, у вас будут постоянно актуальные тестовые стенды. И если в коде что-то сломается, вы узнаете об этом сразу, сервер CI пришлет письмо. А еще можно зайти в графический интерфейс и посмотреть — все ли сборки успешные, а тесты зеленые? Оценить картину по проекту за минуту.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моего курса по автоматизации в Postman.