Ci tools что это

Что такое CI/CD

Аббревиатура CI/CD означает «Continuous Integration/Continuous Delivery» — то есть «непрерывная интеграция/непрерывная доставка». Это подход к разработке, при котором задачи сборки, публикации, тестирования продукта полностью или частично автоматизированы. Очень часто автоматизация интегрирована в бизнес-процессы продуктовой команды или компании, но практики CI/CD прекрасно могут быть внедрены и в проекты, в которых участвует только один разработчик.

Как понять

Скопировать ссылку «Как понять» Скопировано

Технологии CI/CD стали активно проникать в процессы разработки программных продуктов, когда стало очевидно, что для большинства прикладных программ великолепно подходят практики Agile, о которых можно подробнее почитать в статье «Методологии разработки и Agile». Оказалось, что каждую итерацию цикла разработки можно ускорить с помощью автоматизации разных процессов. Типичную итерацию процесса разработки с применением CI/CD можно изобразить на схеме следующим образом:

Схема применения CI/CD на итерации типичного проекта.

Применение CI/CD стало очень хорошим решением, и вскоре появились первые инструменты. В мире веб-разработки это различные «системы сборки», «менеджеры пакетов» и инструменты для тестирования.

Основные принципы

Скопировать ссылку «Основные принципы» Скопировано

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

В основе разработки и использования CI/CD лежат следующие принципы:

разделение ответственности заинтересованных сторон;
снижение рисков;
короткий цикл обратной связи;
реализация среды.

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

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

Применение автоматизации процессов разработки снижает риск ошибок, позволяет оперативно чинить то, что не работает. Настройка инструментов CI/CD затрагивает и такую часть разработки, как создание единого окружения, в котором ведётся разработка программного продукта. Для разработчика это крайне важно.

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

Этапы интеграции и доставки приложений

Скопировать ссылку «Этапы интеграции и доставки приложений» Скопировано

Работа системы инструментов CI/CD основана на цикличности, что прекрасно укладывается в рамки гибкой методологии разработки программного обеспечения. Цикл применения инструментов состоит из следующих этапов:

написание кода;
сборка;
ручное тестирование;
релиз;
развёртывание;
поддержка и мониторинг;
планирование.

Написание кода

Скопировать ссылку «Написание кода» Скопировано

На этом этапе самым главным инструментом является система контроля версий. Обычно это Git. Важный элемент здесь — модель ветвления, то есть принципы использования веток в разработке. Например, в проектах на GitHub, как правило, используется модель ветвления GitHub Flow:

Разработчик делает форк репозитория к себе в аккаунт на GitHub или клонирует репозиторий на компьютер. Форк — это полная копия (зеркало) репозитория на какой-то определённый момент времени, которую можно обновлять при необходимости.
После этого разработчик вносит изменения в форке или в локальной копии. Хорошей практикой является создание новой ветки и работы в ней.
Затем формируется пулреквест — это запрос на слияние с основной веткой.
В рамках пулреквеста можно проверить все предложенные изменения, обсудить решения и прийти к консенсусу.
После утверждения всех изменений они вливаются в основную ветку репозитория.

Существуют и другие модели ветвления, например, Git-flow, о которой хорошо рассказывается в статье «A successful Git branching model» на английском языке и в переводе на русском «Удачная модель ветвления для Git».

Сборка

Скопировать ссылку «Сборка» Скопировано

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

Что такое Docker;
Как устроен Dockerfile;
Управление данными в Docker;
Мультиконтейнерное приложение и Docker Compose.

Для автоматизации сборки могут использоваться различные системы. Наиболее популярные из них:

Jenkins;
GitHub Actions;
GitLab CI/CD;
Bitbucket Pipelines;
JetBrains TeamCity.

Сборку поддерживают популярные и специализированные хостинги, например, Netlify.

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

Скопировать ссылку «Тестирование» Скопировано

После первичной подготовки кода продукту назначается версия будущего релиза с пометкой номера тестовой сборки для детального автоматизированного и ручного тестирования. Например, если номер будущего релиза v.2.4.5, то номер первой тестовой сборки может быть указан так: v.2.4.5-1. На этом этапе преобладает ручное тестирование продукта, поиск и планирование исправления ошибок. После нескольких итераций продукт признаётся готовым к релизу и переходит на следующий этап тестирования.

На этом этапе широко применяются интеграционные тесты, E2E-тесты, ручное и автоматизированное тестирование UI/UX. Для этого могут использоваться различные инструменты. Например, Jest может покрыть задачи модульного, интеграционного и E2E-тестирования веб-приложения. Для генерации скриншотов веб-приложения и автоматического сравнения с эталоном можно использовать Selenium или Puppeteer. При этом можно смоделировать не только загрузку веб-приложения и сохранить скриншоты экранов разных размеров, но и с помощью сценариев посмотреть, как будущий пользователь будет взаимодействовать с приложением.

Релиз

Скопировать ссылку «Релиз» Скопировано

Есть разные типы цикла релизов, о которых подробно рассказывается в статье «Методологии разработки и Agile». В зависимости от особенностей продукта, состава команды и задач владельцев продукта назначается периодичность релизов. Важен не только сам релиз, но и то, как работала команда на очередном витке.

Инструменты CI/CD на этом этапе отвечают в основном за сбор различной статистической информации. Это могут быть как пользовательские метрики (например, Яндекс.Метрика или Google Analytics), так и метрики, принятые внутри команды для отслеживания эффективности того или иного члена команды (например, можно отслеживать количество выполненных задач, скорость их выполнения, инициативность и профессиональный рост с помощью встроенных инструментов Jira, Wrike или Trello).

Развёртывание

Скопировать ссылку «Развёртывание» Скопировано

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

Поддержка и мониторинг

Скопировать ссылку «Поддержка и мониторинг» Скопировано

Наконец-то приложение доступно для рядовых пользователей. Здесь важны скорость и точность ответов на вопросы пользователей (то есть организация службы поддержки пользователей) и встроенная грамотная маркетинговая политика. Для решения этих задач существует множество инструментов, но мы не будем подробно на них останавливаться, поскольку это не относится к разработке. В основном эти инструменты не сильно отличаются от инструментов для обычной офисной работы в рамках крупной компании (IP-телефония, чаты, электронная почта, различные менеджеры задач, подготовка автоматических отчётов и другие программные и аппаратные инструменты). В поддержке современных продуктов часто используются голосовые помощники и чат-боты. Практически все эти инструменты не являются инструментами CI/CD, но почти всегда предоставляют API, чтобы можно было настроить глубокую интеграцию между различными этапами для повышения качества продукта.

Планирование

Скопировать ссылку «Планирование» Скопировано

Важным этапом является и планирование следующего цикла. На основе пользовательского опыта формируется бэклог задач для реализации, назначаются приоритеты и исполнители. После этого цикл CI/CD замыкается.

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

Преимущества и недостатки

Скопировать ссылку «Преимущества и недостатки» Скопировано

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

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

На практике

Скопировать ссылку «На практике» Скопировано

Виталий Баев советует

Скопировать ссылку «Виталий Баев советует» Скопировано

Когда устанавливаете зависимости при помощи пакетного менеджера в автоматизированном CI/CD окружении, обязательно пользуйтесь опцией фиксации лок-файла. Вот как это выглядит для разных пакетных менеджеров:

 # npmnpm install # ❌npm ci # ✅ # pnpmpnpm install # ❌pnpm install --frozen-lockfile # ✅ # yarn classicyarn install # ❌yarn install --frozen-lockfile # ✅ # yarn modernyarn install # ❌yarn install --immutable # ✅ # npm npm install # ❌ npm ci # ✅ # pnpm pnpm install # ❌ pnpm install --frozen-lockfile # ✅ # yarn classic yarn install # ❌ yarn install --frozen-lockfile # ✅ # yarn modern yarn install # ❌ yarn install --immutable # ✅

Без этих команд есть вероятность установить зависимости других версий, чем указанных в лок-файле. Это может создать неочевидные баги, связанные с версиями библиотек.

Например, если лок-файл не содержит зависимость, указанную в package.json. Стандартная установка обновит лок-файл, а установка в режиме CI упадёт с ошибкой.

Стоит отметить, что пакетные менеджеры pnpm и Yarn modern включают такой режим по умолчанию, если установка происходит в CI/CD окружении.

Подробнее про работу с пакетным менеджером и механизм лок-файла можно прочитать в статье «Пакетные менеджеры».

Ci Tools

Ci Tools enable you to get the most out of your Archicad installation.

Ci Tools is committed to developing and distributing tools to help architects and designers get the most out of Archicad. We think that helping you get things done faster, and with less frustration, is good for everyone. Because what we all want in the end, is to create great buildings.

I praise your products wherever possible and importantly, the support offered by you guys.

B Turner, 2013

The Ci Tools Add-ons for Archicad

Doors + Windows

Finally — create the doors and windows the way YOU want!

Keynotes

End the tedium and eliminate errors.

Cabinets

Design custom cabinetry with ease and accuracy.

Coverings

Apply a range of scalable claddings in 2D or 3D views.

Objective

Manipulate, edit and form your own objects in 3D.

Electrical

Intuitive, smart electrical symbols and schedules.

Stairs

Design, draw and edit stairs within your floor plan.

Quantities

Calculate, schedule, and export bills of quantities from a live Archicad project model.

Annotate

Quickly and easily change Text Case without needing to retype

Metadata

Work with Properties and Classifications in one handy palette

Shortcut

Quickly jump from 3D views to the selected elements in Floorplan

Transformer

A one-click solution to Mirror an entire project

Наша история
Наши пользователи
Строим вместе
Сделано в Archicad
Награды

С чего начать
Обучение
Помощь
Сообщество
Загрузки
Системные требования

Последние новости
Мероприятия
Контакты для прессы
Правовые документы

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

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

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

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

Что такое CI

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

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

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

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

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

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

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

mvn clean install

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

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

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

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

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

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

Репозиторий машет 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. И запускать весь цикл на каждое изменение: собрать, протестировать, задеплоить. Тогда любое изменение кода сразу попадет на тестовое окружение, которое будет максимально актуальным.

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

Но в реальной жизни такая схема редко применима. Только подумайте — у вас ведь может быть много проектов, много разработчиков. Каждый что-то коммитит ну хотя бы раз в полчаса. И если на каждый коммит запускать 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

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

Фотография Макса Рекопфа

Непрерывная интеграция (CI) — это лучшая практика Agile и DevOps, которая позволяет нескольким разработчикам вносить вклад и совместно работать над общей базой кода с высокой скоростью. Без непрерывной интеграции сотрудничество разработчиков превращается в утомительный ручной процесс координации обновлений и слияний кода.

Основные принципы непрерывной интеграции

CI основывается на рекомендациях по разработке ПО с учетом принципов Agile и DevOps, таких как автоматизированное тестирование, контроль версий, автоматизация сборки и автоматическое развертывание. Каждый из этих базовых компонентов непрерывной интеграции имеет собственную экосистему инструментов и принципов. У поставщиков инструментов для разработки ПО появились комплексные предложения «CI как услуга», объединяющие эти компоненты в один пакет. Чтобы лучше разобраться в этих комплексных предложениях, повторим основы.

Управление версиями исходного кода

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

Автоматизированное тестирование

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

См. решение

Разработка и эксплуатация программного обеспечения с помощью Open DevOps

Рассмотренный продукт

Работайте совместно, тестируйте и развертывайте код

Автоматизация сборки

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

Автоматические развертывания

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

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

1. Bitbucket Pipelines

Описание. Bitbucket Pipelines — это инструмент CI, напрямую интегрированный в Bitbucket, облачную систему контроля версий Atlassian. Если ваш проект уже находится в Bitbucket, то Bitbucket Pipelines — это следующий простой шаг на пути к CI. Bitbucket Pipelines управляется с помощью кода, поэтому вы можете легко делать коммиты определений конвейеров и запускать сборки. Bitbucket Pipelines дополнительно предлагает непрерывную поставку (CD). Это означает, что проекты, созданные с помощью Bitbucket Pipelines, можно развернуть и в рабочей инфраструктуре