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, в свою очередь, несут ответственность за эту конвейерную карусель.
FAQ
CI (Continuous Integration) и CD (Continuous Delivery) – подход, который оптимизирует процесс доставки кода. Цели непрерывной интеграции и непрерывной доставки – минимизировать ошибки, ускорить сборку кода и повысить качество. CI/CD относится к средствам автоматизации, которая оптимизирует процессы сборки и сокращает время на выявление ошибок. Тестирование в CI/CD выполняют когда в код вносятся изменения, каждый раз. Благодаря этому дефекты можно выявить на первоначальной стадии сборки кода и сэкономить время. Ведь чем позже выявлена ошибка, тем сложнее устранить.
При командной работе над проектом изменения в код вносятся несколько раз в день. В этом случае каскадная сборка работает медленно. В игру вступает CI/CD – подход DevOps, который отвечает за автоматизацию в данной методологии. CI/CD максимально снижает время прохождения этапов – с месяца до минут. Чтобы настраивать и отслеживать работу CI/CD, нужен человек, который возьмет на себя роль координатора. DevOps настраивает инструменты CI/CD и выступает связующим звеном между участниками проекта. Также мониторит три этапа CI/CD – непрерывную интеграцию, непрерывную доставку и непрерывное развертывание.
Jenkins в CI/CD – популярная программная платформа для сборки проектов. Большинство опций в Jenkins можно использовать бесплатно, есть много доступных плагинов. Jenkins можно поместить в отдельный namespace, чтобы среда была изолирована от других environments. Что помогает сделать Jenkins в процессах CI/CD? Создать релизную ветку, собрать код, определить задачи коммита, создать запросы на тестирование, проконтролировать тесты. Без Jenkins на эти этапы уходит до нескольких дней. Данная программная платформа помогает выстроить эффективный pipeline, автоматизировать и максимально ускорить этапы.
Подход CI/CD работает, основываясь на трех принципах – непрерывная доставка, непрерывная интеграция и непрерывное развертывание. Эти три подхода могут использовать вместе, а в отдельных случаях – и по отдельности. Зависит от стратегии на каждом проекте. При внесении изменений в код, CI позволяет писать сценарии для автоматизированной сборки и тестов. После тестирования код можно разворачивать в рабочей среде и так после каждого изменения. Когда процессы CD настроены, этапы проходят автоматически без участия команды. Таким образом, отлаженные процессы CI/CD оптимизируют работу команды на проекте.
Преимущества CI/CD дают разработчикам, тестировщикам, системным инженерам и DevOps экономить ресурсы команды. CI/CD уменьшает количество ошибок в каждой итерации и во время деплоя. Выстроив конвейер, можно снизить время на сборку кода, внесение изменений и тестирование. Тщательное тестирование, как следствие настройки CI/CD pipeline, позволяет безопасно разворачивать код в рабочей среде. Одним из явных преимуществ Continuous Integration и Continuous Delivery является одновременное участие заинтересованных сторон. Нет больших временных разрывов между этапами работы каждого участника проекта – все процессы проходят быстро.
Да, Jenkins – это open source платформа, которая является одним из популярных инструментов CI/CD. Используется для настройки CI/CD pipeline с целью автоматизации доставки, тестирования и развертывания кода. Конвейер Jenkins позволяет настроить непрерывную доставку кода с быстрым выявлением дефектов и ошибок. Jenkins pipeline обеспечивает быстрое автоматическое тестирование каждого куска кода, в каждой итерации. Команда может не переживать, что какой-нибудь дефект может отбросить всю работу за несколько месяцев. Разворачивается уже проверенный код, и маловероятно, что какой-то дефект заставит вернуть все до исходной версии.
Для построения системы сборки и тестирования CI пишется сценарий. Вот как примерно работает CI: разработчик делает пул-реквест/коммит в репозиторий текущего проекта. На вспомогательном сервере разворачивается проект и создается контейнер. Чтобы собрать проект, нужно установить на нем определенное программное обеспечение. Из текущей ветки проекта копируется репозиторий с кодом, выполняется настройка конфигураций и скриптов. После этого запускаются юнит-тесты и проектировщик получает уведомление с результатами. Если тест провален, пул-реквест возвращается на доработку.
CI нужен для ускорения сборки и тестирования. Когда команда работает над совместным проектом, релизы могут затягиваться на недели. Раньше это было вызвано тем, что приложение разворачивалось на финальном этапе. В этот момент тестирование показывало ошибку в одной из частей кода и код приходилось «откатывать». Таким образом, вся работа останавливалась до устранения выявленного дефекта разработчиком. При следующем деплое ошибка могла появиться уже в другом месте, и это было обидно. Релизы стопались, затягивались, все нервничали и искали виноватого. Continuous Integration позволила делать реквесты частями и выявлять ошибки автотестами на ранних стадиях.
Часто подход CI путают с Agile. Но подход Agile не является практикой CI – это две разные сущности. Agile-методология развивалась, основываясь на Lean-производстве. Методология Agile фокусируется на процессах, которые указывают на изменения и ускоряют доставку приложения. Подход CI, в свою очередь, нацелен на оптимизацию жизненного цикла программного обеспечения. В CI есть комплекс инструментов, собранных в единую методологию. А если мы сравним еще и DevOps, то увидим, что еще есть понятие культуры. DevOps – не является CI. А вот CI – неотъемлемый инструмент этой философии.