Несмотря на общие тенденции к автоматизации процессов разработки, все еще можно встретить компании, в которых тестирование и развертывание никак не автоматизировано. Отсутствие автоматизированных процессов влияет на скорость доставки изменений и увеличивает влияние человеческого фактора, что негативно отражается на всей компании в целом, а не только на самом отделе разработки.
В этой статье я постараюсь объяснить разницу между процессами непрерывной интеграции (Continuous Integration/CI), непрерывной доставки (Continuous Delivery/CD) и непрерывного развертывания (Continuous Deployment/CD). Мало кто разделяет два последних термина, но мы все-таки рассмотрим их по отдельности для общего понимания.
Continuous Integration (CI)
Процесс непрерывной интеграции (Continuous Integration) нацелен на автоматизированную проверку интеграции между изменениями разработчика и остальным кодом.
В этот процесс может входить статический анализ кода на уязвимости и несоответствие общим практикам разработки, сборка приложения и автоматизированное тестирование с динамической проверкой на уязвимости.
Автоматизация процессов CI позволяет ускорить процесс разработки, устраняя рутинные операции по ручной проверке интеграции с остальным кодом и сокращая нагрузку на отдел тестирования благодаря более раннему нахождению проблем интеграции с остальными частями приложения. Кроме того, у разработчика не выйдет сэкономить себе время, отправив изменения на тестирование без какой-либо проверки.
Continuous Delivery (CD)
Целью этого этапа является доставка измененной версии приложения в эксплуатацию.
Так, процессом доставки Docker-образов является обычная загрузка образа в реестр образов Docker и последующая его загрузка с хостовой машины. В системах с повышенными требованиями безопасности также может встречаться ситуация, в которой Docker-хосты не имеют доступа к каким-либо реестрам, и в таком случае может применяться доставка Docker-образов с применением команд docker save и docker load.
В системах без использования Docker доставка может быть реализована посредством SCM, apt/yum-репозиториев, ssh, S3-совместимого хранилища для образов VM (собранных с использованием, например, Packer) и многих других способов, область применения которых, опять же, во многом зависит от возникающих требований и удобства поддержки.
В вышеуказанном примере с Docker изменения будут доставлены вместе с новым образом через загрузку в реестр образов Docker.
Автоматизация процессов CD позволяет ускорить процесс доставки, исключить влияние человеческого фактора, а также сделать доставку более доступной для остальных членов команды.
Continuous Deployment (CD)
Процесс нацелен на развертывание новой версии приложения в окружение эксплуатации или тестирования. Обычно этот этап не выделяют как отдельный, развертывание включают в процесс доставки. Он зависит от предъявляемых к нему требований и используемых инструментов, но, как правило, вариант реализации процесса лежит на поверхности.
Инструменты CI/CD
Есть множество SaaS-решений, для обзора которых потребовалась бы отдельная статья. Остановимся на основных решениях, которые легко интегрируются в подавляющем большинстве случаев:
- GitLab CI – отличный вариант для команд, которые используют SaaS или on-premise версию GitLab. Использует YAML для описания CI/CD процессов.
- GitHub Actions – хороший, но относительно новый вариант для тех, кто использует GitHub. Также использует YAML для описания CI/CD процессов
- Jenkins – проект с длинной историей, позволяет использовать Groovy для описания CI/СD процессов (что одновременно как плюс, так и минус по многим причинам) и собственный DSL в Jenkinsfile.
Подробный разбор процессов на вымышленном примере
Представим возможный процесс в вымышленной IT-компании и возможные требования, которые предъявляются от заинтересованных сторон. Возьмем небольшой IT-отдел, в котором присутствуют команды разработки, тестирования и эксплуатации. Рабочий процесс построен по Git-flow, а развертывание выполняется на Docker-хостах. Опишем основные требования каждой из сторон в формате таблицы.
|
Команда |
Требования |
|
Разработка |
Процессы CI/CD не должны отнимать много времени (отсутствие избыточных действий). Требуется простой для понимания процессов CI/CD (описание процесса в виде кода с минимумом ручных действий). По возможности процессы CI/CD во всех проектах должны быть похожи друг на друга (порог вхождения в новый проект). Требуется возможность быстрого отката изменений в случае возникших проблем (устранение влияния человеческого фактора на процесс развертывания). |
|
Тестирование |
Тестирование должно быть по возможности автоматизировано (правка от разработчика уже как минимум не приводит к нарушению работоспособности остальных частей системы). Должна быть возможность простого развертывания разных версий приложения для исследования регрессий (автоматизация процессов развертывания новых окружений). Необходим простой способ развертывания окружения с несколькими сервисами для интеграционного тестирования без необходимости привлекать другие отделы (простота использования). |
|
Эксплуатация |
Требуется минимизация простоя между развертываниями приложений (развертывание без простоя и минимизация человеческого фактора при развертывании новых версий). |
|
Бизнес |
Необходима возможность быстро доставлять новую функциональность пользователям для тестирования гипотез (автоматизация процессов и отсутствие избыточных действий). |
После сбора требований мы можем сформировать примерный вид процессов CI/CD в команде:
Разбор по части CI
Процесс интеграции не обязательно должен быть общим во всех случаях, намного удобнее описать различные сценарии для каждой ситуации. Давайте опишем возможные ситуации в качестве примера:
- При обновлении Pull/Merge Request выполняется статическая проверка кода на соответствие стандартам кодирования компании, статический анализ кода на возможные ошибки и уязвимости, автоматизированное модульное и функциональное тестирование с использованием заглушек вместо реальных внешних сервисов. При необходимости будет выполнена сборка образа для дальнейшей интеграции с остальными сервисами компании и внешними сервисами.
- При изменениях в основной ветке процесс аналогичен вышеприведенному, но с тем исключением, что теперь образ для интеграции собирается всегда: для дальнейшего развертывания на стенде для общего e2e и приемочного тестирования с остальными компонентами.
- При установке тега выполняется сборка образа с приложением для эксплуатации и smoke-тестирование после развертывания.
Почему нельзя построить общий процесс CI? В этом просто нет смысла – если выполнять сборку образа для интеграционного тестирования после ручного подтверждения для релизной ветки, то неминуемо случится ситуация, в которой про необходимость ручного запуска сборки просто забудут, и отдел тестирования будет проверять неактуальную версию приложения. Проводить проверку соответствия стандартам кодирования и юнит/функциональное тестирование на версии, помеченной тегом, – пустая трата времени, ведь все изменения уже есть в релизной ветке.
Чем больше будет автоматизированных задач, тем больше бессмысленной работы будет выполнено в общем процессе.
Разбор по части CD (Delivery)
В нашем случае доставкой является загрузка Docker-образа с приложением в Registry, из которого образы будут загружены на конкретный Docker-хост в процессе развертывания. Реестр может быть как общим, так и отдельным – для окружения разработки и тестирования и окружения эксплуатации. Тут все зависит от требований безопасности в конкретной компании.
Разбор по части CD (Deployment)
В нашем случае деплой в окружение эксплуатации может выполняться путем перенаправления всех новых HTTP-запросов на новый экземпляр приложения (основываясь на том, что максимальное время запроса ограничено сверху разумным лимитом для обеспечения развертывания без простоя).
Небольшим проектам или проектам без необходимости создания собственной инфраструктуры стоит обратить внимание на облачные хостинги, которые позволяют автоматизировать разработку проекта, налаживая процессы CI/CD.
Выводы
Надеюсь, теперь вы точно разобрались в отличиях CI и CD, а также поняли всю важность автоматизации данных процессов.
Подведем итог по всему вышесказанному – внедрение CI/CD само по себе является непрерывным процессом и постоянно видоизменяется в зависимости от новых требований отдельно взятой компании. В то же время процессы CI/CD требуют дополнительных инструментов и времени на внедрение, которое можно сократить, используя уже готовые сервисы для их автоматизации.
Поэтому вывод о необходимости автоматизации того или иного процесса каждый должен сделать для себя сам. Я считаю, что автоматизация рассмотренных процессов должна присутствовать в каждой компании, которая связана с разработкой.
Комментарии