Сейчас от разработчиков очень часто требуется намного больше, чем просто писать код. Предполагается, что они будут уметь тестировать, собирать приложения и деплоить их. Все эти операции довольно трудоёмкие и в некоторых командах выполняются другими людьми, но в маленьких командах или личных проектах необходимо всё это уметь одному человеку. Да и в больших компаниях не помешает понимать весь этот процесс.
Не утонуть во всех понятиях и деталях и сделать все процессы быстрее и эффективнее помогает подход DevOps, который объединяет работу разработчиков (Dev) и операторов (системный администраторов – Ops). По сути, этот подход убирает пробел между двумя независимыми отделами, делая процесс разработки и деплоя приложения более «гладким».
Основные понятия: CI/CD
Continuous Integration (CI). Это практика, при которой приложение автоматически собирается и тестируется каждый раз, когда разработчик отправляет изменения в репозиторий.
Желательно это проворачивать при каждом коммите – то есть даже по несколько раз в день. То есть мы проверяем, как интегрируются новые изменения в уже существующее приложение.
Регулярные коммити помогают избежать работы с ветками, которые устаревают и потом требуют внимательных мёржей (merge).
По идее, разработчик сначала собирает и тестирует проект локально, а потом уже отправляет на общий сервер.
Continuous Delivery (CD). Это второй шаг. Здесь проверяем, будет ли каждое изменение работать в продакшне. Мы создаём среду, близкую к продакшну, и там запускаются интеграционные тесты. Такая среда может быть развернута в Docker-контейнерах или виртуалках: главное, чтобы она вела себя как реальный прод.
То есть мы проверяем, будет ли наше изменение работать на проде, в наших реальных условиях, но пока ещё туда ничего не деплоим, а только имитируем их.
Continuous Deployment. Финальный шаг. Если все тесты прошли успешно, то изменения автоматически выкатываются прямо на прод.
Преимущества CI/CD
Во-первых, эти практики помогают улучшить атмосферу в команде: взаимодействие между отделами становится легче.
Кроме этого, в команде меньше стресса из-за релизов, потому что каждый коммит теперь можно считать релизов – все они, по идее, оказываются в продакшне довольно быстро. Поэтому больше не нужно ждать месяцы, а потом трястись – всё ли будет работать, как надо.
Далее, конечно, метрика, которую можно выразить в числах. Время выката новой фичи уменьшается. Ну и так как многие этапы становятся автоматизированными, у команды появляется больше времени на работу над задачами.
Также эти практики позитивно сказываются на безопасности.
Этапы CI/CD пайплайна
В этом разделе разберу общий пример пайплайна для веб-приложения. Важно помнить, что нет универсального варианта, но тем не менее, главные принципы CI/CD работают везде.
Вот типовая последовательность этапов, которые встречаются в пайплайнах:
- Коммит – Система контроля версий. Коммит исходного кода в систему контроля версий, например GitHub или GitLab, которые запустят дальнейший процесс.
- Сборка. Cборка приложения с помощью CI-систем, например, Jenkins (о них подробнее будет ниже в статье).
- Тесты. Юнит-тесты и интеграционные тесты.
- Артефакт. Сохранение артефактов, например, в Nexus или Docker Registry.
- Деплой в тестовую среду. Автоматическая выкладка в тестовую среду (например, в контейнер). Здесь можно провести интеграционные тесты уже на среде, схожей с продом. Также не стоит забывать про security-тесты, например, с Gauntlt.
- Ручная проверка. End-to-end тесты (UI-тесты), например, с Selenium.
- Деплой на прод. Автоматический или полуавтоматический деплой в прод, например с Chef.
- Мониторинг. Сбор логов, метрик и автоматическое уведомление о сбоях.
Лучшие практики CI/CD
Основная идея – коммитить меньше и чаще, и тестировать, соответственно, тоже как можно чаще. Поэтому автотесты – такой же код, как и основное приложение, и их нужно поддерживать.
Также нужно помнить, что работа разработчика не заканчивается после коммита – успех достигнут, только если код встал в прод без сбоев. Иначе нужно откатиться до прошлой сборки – поэтому важно использовать системы контроля версий. И не отправлять в прод нестабильные сборки, которые не прошли все тесты.
Ручное тестирование должно быть точечным и фокусироваться на том, что сложно автоматизировать.
Всё должно быть кодом (Infrastructure as Code (IaC)): конфигурации, инфраструктура, деплой-скрипты – всё в системе контроля версий. Автоматическое создание окружений снижает вероятность багов.
Сборка и деплой должны быть быстрыми (в идеале – минуты).
В идеале пайплайн превращается в предсказуемый конвейер:
код → сборка → артефакт → тест → деплой → мониторинг.
Всё автоматизировано, хранится в версиях и отлажено.
Типы инструментов для CI/CD. Их плюсы и минусы.
Теперь время перейти к примерам инструментов, которые можно использовать для создания пайплайнов. Конечно, их очень много, и я почти никакие пока не трогал, но некоторые потрогаю в следующей статье, где буду создавать пайплайн.
А в этой секции рассмотрю четыре категории инструментов, понимание которых сильно упростит выбор.
Self-Hosted
Примеры: Jenkins, Bamboo, TeamCity
Эти инструменты устанавливаются и обслуживаются вручную: на сервере в дата-центре, в виртуальной машине в облаке или на локальной машине разработчика.
Из плюсов: гибкость (вы сами выбираете полный стек технологий и даже железо), полный контроль над данными (соответственно, их безопасность – вы не боитесь утечки данных у провайдера).
Из минусов: необходимость всё настраивать и поддерживать самостоятельно, поэтому сложная машсштабируемость и высокий порог входа (для новичков может быть сложный вариант).
Jenkins пример бесплатного инструмента с множеством плагинов и поддержкой от коммьюнити. А TeamCity, например, хорошо интегрируется с IDE, что может быть важно, если вы тоже пишете на джаве в Idea.
Software as a Service
Примеры: Travis CI, CirkleCI
Эти инструменты хранятся у провайдера, а вы просто регистрируетесь и используете их. Обновление и поддержка инфраструктуры ложится на плечи провайдера.
Из плюсов: простота использование, быстрое начало, не нужно тратиться на свою инфраструктуру, да и сервисы предлагают для начала недорогие (или даже бесплатные) тарифы.
Из минусов: масштабирование может потребовать значительные финансовые затраты, и риск утечки данных (проблема безопасности может быть актуальна и для следующих категорий).
Cloud Providers
Примеры: AWS CodePipeline, AWS CodeBuild, Azure Pipelines, CGP CloudBuild
Эта категория расширяет SaaS-модель, и её главное отличие, что на больших платформах (AWS, Azure, GCP) есть интеграция с другими сервисами этих провайдеров (VM, хранение данных, IAM и т.д.)
Из плюсов: нативная интеграция с инфраструктурой, масштабируемость.
Из минусов: привязка к экосистеме конкретного облака, довольно сложная конфигурация.
Code Repos
Примеры: GitHub Actions, GitLab CI, Bitbucket Pipelenies
Современные репозитории кода предлагают встроенные CI/CD-возможности. Вы храните код и тут же запускаете пайплайны.
Из плюсов: всё в одном месте, ест бесплатные опции.
Из минусов: может уступать по гибкости специализированным инструментам.
Для вступительного конспекта хватит, а в следующей статье буду настраивать пайплайн и показывать уже примеры из практики.
Zimowski Journal 