Как и обещали, рассказываем о самых важных и интересных практиках DevOps. Сегодня мы рассмотрим 3 практики, каждая из которых связана с непрерывностью. Это Continuous Integration, Continuous Delivery и Continuous Deployment.

Что такое непрерывность в DevOps?

Для начала разберемся, почему все перечисленные практики снабжены приставкой “Continuous”. Почему в их названиях обозначили непрерывность? Разве что-то поменяется, если убрать это слово? Технически, нет. Однако непрерывность процессов – один из китов, на которых стоит методология DevOps. Речь идет о непрерывности изменений в программном обеспечении. Иными словами, в ходе работы над приложением изменения в ПО вносятся непрерывно. Посмотрим, как это выглядит на практике. Точнее, на трех вполне конкретных практиках.

1. Continuous Integration – непрерывная интеграция

Это ключевая практика DevOps, которая заключается в частом слиянии рабочих копий программного обеспечения в основную ветвь в общем репозитории и выполнении частых автоматизированных сборок проекта для быстрого выявления багов, проблем и их исправления. Без DevOps функциональные группы работают изолированно. Сначала каждая группа выполняет свои задачи, и только потом их наработки объединяются. Но такой подход крайне неэффективный. Часто коды разных групп просто не работают в связке, а после их объединения вылазят баги, которых можно было бы избежать, изначально объединив работу всех специалистов. Именно это и предлагает Continuous Integration. Наработки разных групп сразу отправляются в репозиторий, а специальное программное обеспечение проверяет, корректно ли они работают в связке. Таким образом, возможные ошибки обнаруживаются и устранятся еще до запуска рабочей версии приложения.

2. Continuous delivery – непрерывная доставка

Эта практика нацелена на непрерывное обновление ПО, даже если оно уже ушло на продакшен. Например, разработчик придумал новую фичу для приложения. Что делать без DevOps? Ждать релиза приложения и проверять, как фича впишется в его функционал? Или тормозить рабочий процесс, чтобы проверить дееспособность фичи? Но это глупо. Методология DevOps предлагает альтернативное решение – сразу отправлять фичи специалистам из QA-отдела. Они их протестируют и, если все в порядке, отправят в релизную ветку (брэнч). Используя Continuous delivery, фичи можно добавлять даже после выхода релиза. Вы видите, что нужно клиентам, и просто даете им это. Или быстро исправляете ошибки, обнаруженные уже после релиза.

3. Continuous deployment – непрерывное развертывание

Эту практику часто путают с Continuous delivery. Однако доставка и развертывание – это разные вещи. Хоть и связанные. Доставка нужна для постоянного выпуска программных обновлений. А развертывание – для того, чтобы новый функционал автоматически попадал в приложение. Например, одно из популярных инструментов — Docker, как раз помогает реализовать непрерывное развертывания приложений. Используя его, DevOps-инженер может в автоматическом режиме разворачивать приложения на продакшене.

Как эти практики работают в связке?

Continuous Integration охватывает процесс работы над приложением от написания кода до тестирования рабочей версии продукта. Continuous delivery дополнительно охватывает этап релиза, а Continuous deployment – развертывания приложения в продуктовой среде. То есть, эти практики взаимосвязаны и даже взаимопроникающие. В идеале весь процесс выглядит следующим образом:

разработчик отправляет программный код в репозиторий;

функциональные группы работают над приложением и вносят свои изменения в рабочую версию приложения;

все изменения объединяются и тестируются (Continuous Integration);

QA-инженеры тестируют новые фичи и быстро добавляют их в релиз (Continuous Delivery);

приложение развертывается на продакшене, при необходимости в него автоматически вносятся новые изменения (Continuous Deployment).

Отработка и поддержание такого цикла жизнедеятельности приложения и является основной задачей DevOps. И это – лучшая база для непрерывности бизнес-процессов.