Ci pipeline что это

Что такое методология разработки CI/CD

О новой методологии дискутируют разработчики, менеджеры проектов и другие IT-специалисты. Как строится работа по проекту в рамках методологии? Какие выгоды она несет DevOps? Подробнее – в материалах статьи. Простыми словами, CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, […]

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

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

Основные принципы CI/CD

Сегрегация ответственности заинтересованных сторон. Участники процесса разработки и потребители готового проекта разделяют между собой ответственность за ту или иную стадию жизненного цикла продукта. Разработчики и дизайнеры проектируют бизнес-логику, а также обеспечивают положительный пользовательский опыт взаимодействия с готовой системой. Инженеры по качеству вводят сквозные функции и приемочные тесты, DevOps-инженеры организуют логистику кода, а пользователи — дают обратную связь по результатам использования системы.

Снижение риска. Каждая группа участников процесса разработки минимизирует возможные риски при прохождении продукта через стадии жизненного цикла (контроль целостности бизнес-логики, пользовательского опыта, оптимизация хранения и обработки данных, миграции и пр.).

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

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

Этапы CI/CD

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

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

Ручное тестирование. Когда CI система успешно проверила работоспособность тестовой версии, то код отправляется тестировщикам для ручного обследования. При этом тестовая сборка получает номер кандидата для дальнейшего релиза продукта (например, v.1.0.0-1).

Релиз. По итогам ручного тестирования сборка получает исправления, а итоговый номер версии кандидата повышается (например, после первого исправления версия v.1.0.0-1 становится v.1.0.0-2). После этого выпускается версия кода для клиента (например, v.1.0.0) и начинается следующий этап цикла.

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

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

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

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

Метод обеспечивает оперативность вывода нового функционала продукта (работа с запросами клиентов). Как правило, это считанные дни или недели. В то же время при классическом подходе к разработке клиентского софта это может занять год.

Кроме того, команда разработки получает пул альтернатив кода, что оптимизирует затраты ресурсов на решение задачи (за счет автоматизации первичного тестирования функционала).

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

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

Также заслуживает внимания и организация взаимодействия между проектными группами, поскольку CI/CD сильно завязан на человеческий фактор. Инженеры, scrum-специалисты, аналитики, dev-группы и другие функциональные единицы должны работать в единой экосистеме с адекватным руководством и проектным управлением.

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

Software разработчики используют различные инструменты для автоматизации тестирования и доставки кода своих проектов конечным пользователям.

GitLab. Среда позволяет управлять репозиториями проекта, документировать функциональность и результаты доработок и тестов, а также отслеживать ошибки и работать с CI/CD pipeline.

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

Travis-CI. Инструмент подключается к репозиториям в GitHub при минимуме настроек. Решение облачное и не требует локальной установки. Кроме того, оно бесплатно для open-source проектов.

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

Jenkins. Довольно популярный инструмент в DevOps среде. Заслужил свою репутацию благодаря работе с различными плагинами, позволяющими гибко настраивать CI/CD процессы под требования разработки конкретного продукта.

TeamCity. В бесплатном режиме позволяет работать только с 3 агентами сборки, техническая поддержка предоставляется по подписке.

PHP Censor. CI-сервер для автоматизации сборки PHP-проектов, работающий с репозиториями GitLab, GitHub, Mercurial и др. Для тестирования используются библиотеки Atoum, PHP Spec, Behat и др. Проект хорошо документирован, но предполагает самостоятельную настройку и хостинг.

Rex. Предназначен для автоматизации CI процессов в дата-центрах. Функционирует на Perl-скриптах.

Open Build Service (OBS). Предназначен для автоматизации CI/CD в разработке дистрибутивов приложений.

Buildbot. CI-система, позволяющая автоматизировать сборку и тестирование приложений. Поддерживает современные VCS и позволяет гибко настраивать сборку за счет Python-компонентов.

Managed Kubernetes by Selectel помогает разворачивать тестовые среды для автоматизации разработки и тестирования IT-решений (приложения на базе микросервисов, высоконагруженные проекты и др.). Сервис предоставляет все для гибкого конфигурирования и управления кластерами, их миграцией и распределением. Подробнее о продукте — в нашей базе знаний.

Что такое CI/CD-пайплайн

CI/CD-пайплайн (Continuous Integration and Continuous Delivery/Deployment) – это автоматизированная последовательность действий которая позволяет интегрировать, тестировать и доставлять обновления программного обеспечения с максимальной эффективностью.

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

После успешной интеграции CI-процесс может быть автоматически запущен, чтобы выполнить серию тестов, таких как модульные тесты, интеграционные тесты и функциональные тесты. Если тесты успешно пройдены, пайплайн переходит к следующему этапу – непрерывной доставке/развертыванию (Continuous Delivery/Deployment).

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

CI/CD-пайплайн автоматически развертывает приложение в рабочую среду после прохождения всех тестов. Это позволяет быстро и надежно предоставлять новые функции и изменения пользователям.

CI/CD-пайплайны часто используют различные инструменты CI/CD и технологии, такие как системы контроля версий (например, Git), средства непрерывной интеграции (например, Jenkins, Travis CI, GitLab CI/CD), платформы для автоматического развертывания (например, Docker, Kubernetes) и другие варианты тестирования и управления конфигурацией.

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

Задача CI/CD-пайплайна

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

Рассмотрим подробнее функции CI/CD-пайплайн:

1. Регулярное и частое выполнение интеграции кода в центральный репозиторий. Это помогает быстрее обнаруживать и исправлять конфликты и ошибки в коде, а также улучшать его качество.
2. Автоматический запуск различных типов тестов, таких как модульные тесты, интеграционные тесты и функциональные тесты. Автоматизированное тестирование помогает выявить ошибки и проблемы на ранних стадиях разработки.
3. Автоматическая сборка программного обеспечения и его упаковка в пакеты или контейнеры. Это позволяет создавать релизы приложения и подготавливать его к развертыванию.
4. Автоматическая доставка или развертывание приложения в тестовые, стейджинговые или рабочие среды после успешного прохождения тестов. Это позволяет быстро и надежно доставлять новые функции и изменения пользователям. Часто используемый инструмент для автоматической доставки кода – GitLab CI/CD. Воспользуйтесь инструкцией для GitLab CI/CD приложения GitLab Runner для запуска.
5. Сбор метрик и журналов приложения, а также отображение отчетов о прохождении тестов. Это помогает получать обратную связь о работе приложения, его стабильности и производительности.

Этапы билд-пайплайна

Билд-пайплайн – это последовательность этапов и операций, которые выполняются для сборки и подготовки приложения. Расскажем детально из каких этапов состоит CI/CD процесс:

1. Первый шаг билд-пайплайна – это получение полного исходного кода из системы контроля версий (например, Git). Это может быть выполнено путем клонирования репозитория или получения последней версии кода.
2. Установка зависимостей. На этом этапе настраиваются все зависимости и компоненты, необходимые для сборки и работы приложения. Это может включать установку пакетов и библиотек, зависимых модулей или компонентов фреймворка.
3. Сборка и компиляция. На этом шаге происходит фактическая сборка и компиляция приложения. Она может включать компиляцию исходного кода, сборку JavaScript, CSS, шаблонов и т. д., а также другие действия, необходимые для создания исполняемого приложения.
4. Далее выполняется автоматическое тестирование приложения. Оно может включать запуск модульных тестов, интеграционных тестов, функциональных тестов и других типов тестов для проверки корректности работы приложения.
5. Создание артефакта. После успешной сборки и прохождения тестов создается артефакт – полный набор файлов, необходимых для развертывания и работы приложения. Это может быть архив с исполняемыми файлами, докер-контейнер, образ диска или другое представление приложения.
6. Развертывание. В зависимости от конфигурации и требований, созданный артефакт может быть автоматически развернут на тестовую, стейджинговую или рабочую среду. Оно включает подготовку серверов, установку необходимых зависимостей и настройку окружения.
7. Последний шаг – это мониторинг и обратная связь. В конце каждого билд-пайплайна могут быть включены шаги мониторинга и сбора метрик. Это позволяет отслеживать процесс сборки и развертывания, а также получать обратную связь о работе приложения и его состоянии.

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

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

Заключение

В современной разработке программного обеспечения CI/CD-пайплайны являются неотъемлемой частью процесса разработки. Команды DevOps-специалистов применяют CI/CD пайплайн для автоматической сборки, интеграции, тестирования и доставки кода, что повышает эффективность и надежность процесса.

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

GitLab CI/CD

Что-то вроде GitHub Actions, но для GitLab. Настраиваем сборку проекта.

Время чтения: 8 мин

Открыть/закрыть навигацию по статье

1. О GitLab
2. Кратко
3. Пример
4. Как пользоваться
   1. Основные понятия
   2. Создаём .gitlab-ci.yml
   3. Задаём подготовительные команды
   4. Указываем этапы
   5. Описываем джобы и задаём команду
   1. Запуск вручную
   2. Продолжение при провале
   3. Выполнение джобов по условию
   4. Запуск по расписанию
   5. Серия джобов

   Обновлено 24 мая 2022

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

   О GitLab

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

   GitLab — популярный веб-сервис для совместной разработки и поддержки программного обеспечения. Вы можете работать с Git-репозиториями, управлять задачами, обсуждать правки с вашей командой, писать wiki-документацию, оценивать качество, выпускать релизы и даже мониторить работающие программы — и всё это в одном месте.

   Кратко

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

   GitLab CI — инструмент, встроенный в GitLab для автоматизации рутинных задач, возникающих в процессе разработки программного обеспечения. Спектр таких задач огромен и отличается от проекта к проекту, но основные — это тестирование, статический анализ, проверка стиля написания кода и деплой (выпуск) приложения. GitLab CI — конкурент другого популярного инструмента, GitHub Actions. Эти два сервиса во многом похожи, но есть некоторые отличия.

   Пример

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

   Допустим, мы договорились в команде об особых правилах оформления кода при помощи EditorConfig, установили его как дев-зависимость и сделали его доступным с помощью команды npm run editorconfig . Можно запускать проверку каждый раз перед коммитом, но всегда будут ситуации, когда это забудут сделать, и код, оформленный неправильно, попадёт в репозиторий. Здесь приходит на помощь GitLab CI/CD — достаточно создать в корне проекта файл .gitlab-ci.yml со следующим содержанием:

    EditorConfig: image: node:lts script: - npm ci - npm run editorconfig EditorConfig: image: node:lts script: - npm ci - npm run editorconfig   Скопировать Скопировано Не удалось скопировать   

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

   Как пользоваться

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

   Основные понятия

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

   Основной сущностью в GitLab CI/CD является пайплайн (pipeline) — конвейер, который может состоять из:

   • джобов (jobs), описывающих что нужно выполнить;
   • этапов (stages), указывающих когда или в какой последовательности нужно выполнить джобы.

   Джобы в одном этапе обычно выполняются параллельно. Если все джобы завершились успешно, выполнение переходит к следующему этапу и так далее. Если любой из джобов завершился ошибкой, то выполнение останавливается, и весь пайплайн (обычно) считается проваленным.

   Создаём .gitlab — ci . yml

   Скопировать ссылку «Создаём .gitlab-ci.yml» Скопировано

   GitLab CI полностью конфигурируется с помощью одного файла в формате YAML, который нужно создать в корне проекта — .gitlab-ci.yml.

   Джобы часто могут иметь одинаковые свойства, например, образ среды, в которой выполняются действия, предварительные команды и т. д. Чтобы не повторять их каждый раз, нужно объявить их в секции default . Если какому-то джобу нужны другие параметры, можно указать их внутри этого джоба, и они перезапишут глобальные параметры.

   В первую очередь нужно указать Docker-образ (подробнее в статье «Что такое Docker»), в котором будут выполняться джобы. В большинстве случаев нам подойдёт официальный образ Node.js node : lts — это означает, что наши команды будут выполняться внутри операционной системы Linux с установленными Node.js, npm и даже Yarn. Про буквы lts можно почитать в разделе про версионирование Node.js.

    default: image: node:lts default: image: node:lts   Скопировать Скопировано Не удалось скопировать   

   Задаём подготовительные команды

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

   При работе с CI/CD во фронтенд-проектах чаще всего перед выполнением основного действия необходимо установить зависимости. Для этого мы можем указать их в секции before _ script — эти команды будут выполняться в каждом джобе перед основным действием.

    default: image: node:lts before_script: - npm -v - npm install default: image: node:lts before_script: - npm -v - npm install   Скопировать Скопировано Не удалось скопировать   

   Указываем этапы

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

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

    stages: - Стиль кода - Тесты stages: - Стиль кода - Тесты   Скопировать Скопировано Не удалось скопировать   

   Описываем джобы и задаём команду

   Скопировать ссылку «Описываем джобы и задаём команду» Скопировано

   Теперь укажем все три джоба. Для этого мы вначале указываем название джоба, указываем его этап при помощи ключевого слова stage и передаём список команд в script . В нашем примере каждый джоб будет запускать по одному npm-скрипту.

    default: image: node:lts before_script: - npm -v - npm ci stages: - Стиль кода - Тесты EditorConfig: stage: Стиль кода script: - npm run editorconfig Stylelint: stage: Стиль кода script: - npm run stylelint Автотесты: stage: Тесты script: - npm run test default: image: node:lts before_script: - npm -v - npm ci stages: - Стиль кода - Тесты EditorConfig: stage: Стиль кода script: - npm run editorconfig Stylelint: stage: Стиль кода script: - npm run stylelint Автотесты: stage: Тесты script: - npm run test   Скопировать Скопировано Не удалось скопировать   

   А вот схематичное представление конфигурации выше:

   

   Джобы должны иметь уникальные имена — если указать два джоба с одинаковым именем, то из них выполнится только последний — он перезапишет все предыдущие джобы с таким именем!

   Продвинутое использование

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

   Запуск вручную

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

   Если мы хотим запускать определённый джоб вручную, то нужно добавить when : manual :

    job: script: npm run deploy when: manual job: script: npm run deploy when: manual   Скопировать Скопировано Не удалось скопировать   

   Продолжение при провале

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

   По умолчанию при провале любого джоба весь пайплайн отмечается как проваленный, и оставшиеся джобы не выполнятся. Однако бывают ситуации, когда этого поведения хочется избежать. Например, мы добавили джоб с тестами в только что появившейся версии Node.js и просто хотим видеть проблемы, которые потенциально нужно исправить в будущем. Здесь придёт на помощь allow _ failure : true :

    job: image: node:latest script: npm run test allow_failure: true job: image: node:latest script: npm run test allow_failure: true    Скопировать Скопировано Не удалось скопировать   

   Выполнение джобов по условию

   Скопировать ссылку «Выполнение джобов по условию» Скопировано

   GitLab даёт доступ к большому количеству переменных окружения с полезной информацией. Например, $ C I _ C O M M I T _ B R A N C H содержит текущую ветку, $ C I _ C O M M I T _ S H O R T _ S H A — короткий хеш коммита, $ C I _ P I P E L I N E _ S O U R C E — источник вызова текущего пайплайна и так далее. С их помощью мы можем запускать определённые джобы при соблюдении заданных условий. Для этого нужно объявить одну или несколько секций rules .

   Вот такой джоб будет выполняться только для коммитов в ветку main :

    job: script: npm run deploy-to-production rules: - if: '$CI_COMMIT_BRANCH == "main"' job: script: npm run deploy-to-production rules: - if: '$CI_COMMIT_BRANCH == "main"'    Скопировать Скопировано Не удалось скопировать   

   Запуск по расписанию

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

   В отличие от GitHub Actions, в GitLab CI/CD запуск пайплайнов по расписанию настраивается только в веб-интерфейсе. Для этого нужно открыть страницу репозитория и выбрать CI/CD → Schedules. Перед нами откроется список уже существующих правил и кнопка добавления нового. В форме добавления можно указать название правила, выбрать интервал из списка или указать свой в синтаксисе Cron. Последним важным полем является ветка — при срабатывании правила пайплайн запустится, как будто был запушен код в этой ветке. Отличие в том, что переменная $ C I _ P I P E L I N E _ S O U R C E будет содержать значение schedule.

   Серия джобов

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

   Ещё одна типичная задача — прогнать тесты в разных версиях Node.js. Можно для каждой версии создать вручную джоб, а можно указать список переменных:

    Unit Tests: script: node -v image: $ parallel: matrix: - NODE_VERSION: ["node:14", "node:16", "node:17"] Unit Tests: script: node -v image: $NODE_VERSION> parallel: matrix: - NODE_VERSION: ["node:14", "node:16", "node:17"]    Скопировать Скопировано Не удалось скопировать   

   В примере выше мы объявили список NODE _ VERSION из трёх элементов. GitLab создаст три джоба с именами: «Unit Tests [node:14]», «Unit Tests [node:16]» и «Unit Tests [node:17]», а потом в каждом джобе заменит все места использования переменной NODE _ VERSION . Поэтому image в каждом джобе будет разный.

   Непрерывная интеграция и доставка (СI/CD pipeline)

   В бизнесе критической стала бесперебойность и скорость работы. Непрерывные тесты и непрерывная доставка кода увеличивают скорость и качество продукта. Поставив код на слаженный конвейер, бизнес решает проблему затянутых релизов и оттягивание запуска продукта. Continuous Integration & Continuous Delivery (CI/CD) («непрерывная интеграция и доставка»), становится спасательным кругом. Концепция разрешает делать слияние копий частей кода в ветку несколько раз в день. На каждом этапе происходит автоматическое тестирование, по CI/CD pipeline код развертывается в готовый продукт. Принцип похож на конвейер, который оптимизирует процесс доставки кода, повышая качество.

   CI/CD для чайников

   Рассказываем про CI/CD pipeline «для чайников» – как работает и как вписывается в DevOps-методологию. CI/CD системы нужны для регулярной автоматизированной сборки кода. Это делается для моментального выявления ошибок и устранения дефектов в итерациях. CI/CD pipeline делает возможной непрерывность итераций и снижает трудоемкость в случае раннего выявления дефекта.

   Говоря про CI/CD pipeline «для чайников», уточняем, что метод лежит в основе идеологии DevOps. Что касается автоматического тестирования, здесь процесс CI/CD соответствует базовым принципам Agile. Что такое CI/CD в рамках DevOps? Это практический инструмент реализации стратегии DevOps с помощью программных платформ.

   

   Возможно, вы задались вопросом CI/CD pipeline – что это? В контексте софтверной отрасли под pipeline подразумеваем «конвейер», по которому доставляется код. Как работают CI/CD пайплайны? С помощью каких CI/CD tools реализуется работа конвейера. Хостинги репозиториев, такие как Bitbucket CI/CD, Github CI/CD, используются в качестве пайплайна доставки кода. Есть и другие CI/CD системы, например, CI/CD Jenkins, облачный сервис CI/CD AWS, Azure DevOps CI/CD. У каждого из этих инструментов есть преимущества. Команды сами выбирают, с чем удобнее работать – нет жестких рекомендаций по конкретным тулзам. По теме CI/CD Habr выдает тонны статей, попробуем собрать общую информацию про CI/CD tools ниже.

   CI/CD инструменты

   

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

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

   • Jenkins job builder, используется для описания задач.
   • Локальный DSL Plugin для описания задач пайплайна.
   • Gitlab и Gitlab CI/CD – внутри CI на Go и агенты для сборки и деплоймента.
   • GitHub Pull Request Builder – автоматизирует прослеживание pull-requests Github. Также объединяет изменения, запускает сборку, делает анализ и выдает статус реквеста.

   

   Сервер непрерывной интеграции CI/CD Teamcity применяется для конфигурации сборки кода и отслеживания коммитов. После этого ПО запускает билд и unit-тесты. В режиме реального времени отслеживаем сбои тестов, компиляции и проверять код. Процессы CI/CD превращаем в шаблоны и создавать конфигурации сборки.

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

   Gitlab CI/CD настройка

   Gitlab – SAAS сервис для размещения Git-репозиториев, отслеживания дефектов и составления wiki на markdown. Gitlab работает на разных сервисах – Docker, BitBucket Pipelines, GoCD Jenkins, Docker, Heroku CI, AWS CodeBuild и других. Рассказываем, с чего начинается Gitlab CI/CD настройка на Docker и Kubernetes.

   

   Начнем с Gitlab CI/CD Docker. С Docker настраиваем непрерывную интеграцию, используя докер-образы. Для начала проверяем доступ на сервер Git, наличие SSL-сертификата и SSH-ключа. Создаем master-slave серверы, и сервер для сборки контейнеров и их запуска. Образ Docker – для подготовки Runner, Manager и Node серверов. Строим secure connection между Runner-сервером и Docker.

   Для конфигурирования Gitlab CI/CD Kubernetes нужно настроить домен и SSL-сертификат. После создаем и активируем GitLab-репозиторий. Логинимся и подготавливаем к запуску проект. В нем будет размещен код, проходящий через Kubernetes CI/CD pipeline для сборки и развертывания. Это базовые подготовительные этапы. Как подробно настраивать CI/CD инструменты – тема для отдельной статьи.

   В проектах Gitlab CI/CD настройка системы снижает риски на каждом из этапов. Логические тесты разработчиков, целостность данных от QA, удобство использования – на бизнес-аналитиках и Product Owners. DevOps, в свою очередь, несут ответственность за эту конвейерную карусель.

   Похожие публикации:

   1. Как добавить вкладку в избранное
   2. Как отключить автообновление на айфоне
   3. Как проверить датчик детонации кайрон дизель
   4. Какой тег при создании страницы не является обязательным