Перевод статьи подготовлен в преддверии старта курса "DevOps практики и инструменты".
Прямо сейчас у вас есть шанс успеть на курс по специальной цене. Узнать подробности.
В настоящее время гибкость бизнеса часто основана на гибкости кода. Возможность быстрых и безопасных релизов по требованию для современных цифровых продуктов и услуг является реальным конкурентным преимуществом.
С 2004 года мы разрабатываем, собираем и развертываем пайплайны кода для автоматизации приложений и инфраструктур. В этой статье мы делимся семью паттернами, которые улучшают скорость, гибкость и качество, при одновременном повышении автономности, прозрачности и удобства обслуживания.
Непрерывная поставка
Непрерывная поставка (Continuous Delivery) — это "возможность надежно и быстро поставлять изменения всех типов в руки пользователей". Если посмотреть на непрерывную поставку по матрице Agile vs Effort, то можно увидеть, что она находится прямо между непрерывной интеграцией и непрерывным развертыванием. Часто их вместе называют CI / CD.
В отчете о состоянии DevOps за 2019 год более 31 000 респондентов сообщили об эффективности своих процессов разработки и поставки. Но разница между лидерами и отстающими ошеломляет. У лидеров в 200 раз больше развертываний и в 100 раз выше скорость развертывания, а также в 2 600 раз быстрее восстановление после инцидентов и в 7 раз меньше вероятность отката релизов.
Это исследование показывает, что для лидеров скорость и стабильность не противоположны! Вы можете получить и то и другое (на самом деле вам нужно и то и другое), чтобы получить реальные конкурентные преимущества для ваших цифровых продуктов и услуг.
Пайплайны
Пайплайны (конвейеры) — это основные технические артефакты непрерывной поставки. Современные пайплайны преобразуют исходный код приложения и инфраструктуры в версионированные пакеты, которые можно разворачивать в любой среде. Автоматизируя все рутинные задачи по сборке и развертыванию систем, разработчики могут сосредоточиться на реализации действительно полезных фич.
Хотя пайплайны кода существуют уже почти 20 лет — CruiseControl, один из наших первых любимцев, был выпущен в 2001 году, — они значительно эволюционировали за последние годы.
Основываясь на нашем опыте и опыте наших клиентов, мы выделили семь паттернов пайплайнов, которые мы наблюдали во многих современных технологических компаниях.
Паттерны пайплайнов
Паттерн 1 — пайплайны как код
Логика пайплайна кодируется и хранится вместе с кодом приложения и инфраструктуры. Для выполнения пайплайнов используются контейнеры.
Никаких настроек через графический интерфейс! Вся логика пайплайна управляется, как и любой другой код приложения, и подчиняется тем же стратегиям ветвления и ревью.
Выполнение пайплайнов в контейнерах позволяет CI / CD - платформе поддерживать множество различных рабочих нагрузок, при этом каждая рабочая нагрузка может иметь свою собственную среду сборки для удовлетворения специфических требований.
Для образов контейнеров сред сборки используются проверенные Docker-образы.
Конфигурация CI runner автоматизированная, одинаковая и не требует ручной настройки. CI runner при необходимости могут масштабироваться и находиться в режиме ожидания для минимизации задержек.
Секреты хранятся вне пайплайнов, а их вывод маскируется, что повышает безопасность.
Паттерн 2 — перенос логики в повторно используемые библиотеки
Общая логика пайплайнов выносится в повторно используемые библиотеки, на которые можно ссылаться из кода пайплайнов, а также независимо их разрабатывать и тестировать.
Относитесь к пайплайн-библиотекам как к любому другому программному обеспечению. У них есть собственные репозитории, пайплайны, модульные тесты и релизы.
По возможности для запуска внешних задач пайплайны используют специфичные для языка инструменты, такие как Make, Rake, npm, Maven и т.п. Для того чтобы упростить пайплайн и сохранить идентичность процесса локальной сборки и CI.
Библиотеки легко найти и у них хорошая документацию.
Паттерн 3 — отдельные пайплайны для сборки и развертывания
Пайплайны сборки и развертывания должны быть логически разделены, управляться и запускаться независимо. Должна быть возможность как автоматического, так и ручного запуска.
Должна быть одна сборка и много развертываний. Сосредоточьтесь на сборке. В ее результате появляются артефакты, которые можно развернуть несколько раз.
Будьте независимы от окружения. При отсутствии пакетов, специфичных для окружения, и вынесения параметров в переменные окружения, одна и та же сборка может работать в любой среде.
Упакуйте всё вместе. Всё — весь исходный код, включая код инфраструктуры, должен храниться вместе, чтобы стать версионнированным пакетом.
Паттерн 4 — запуск правильного пайплайна
Коммиты в ветки, пул реквесты и слияние с основной веткой — всё это может инициировать различное поведение пайплайна, оптимизированное под конкретную команду.
Открытие pull request'а создает эфемерную среду для тестирования.
Слияния с основной веткой развертываются в не-продакшн или демо-среде, содержащей последний интегрированный код.
Создание новых тэгов приводит к выпуску релиза.
Паттерн 5 — быстрая обратная связь
Каждый коммит автоматически запускает определенный пайплайн. При этом пайплайны сборки специально оптимизированы для скорости и быстрого оповещения о возникающих проблемах.
Пайплайны сборки используют распараллеливание для независимых друг от друга заданий с целью повышения производительности.
Быстрые пайплайны сборки выполняют необходимые задания за несколько минут.
Каждый успешный запуск завершается созданием версии пакета и результатами статического анализа.
С помощью многоканальных уведомлений вы можете настроить оповещения о статусе пул реквестов на дашбордах, в чатах, по электронной почте и др.
Паттерн 6 — стабильные внутренние релизы
Развертываются только версионнированные пакеты, созданные пайплайном сборки. Эти развертывания запускаются вручную или автоматически по событиям.
Каждая ветка кода получает полное эфемерное окружение, названное в соответствии с именем ветки, которое можно легко создать или уничтожить.
Любой инженер может создать или удалить эфемерную среду.
CI runners используют возможности cloud-native IAM с временными разрешениями, чтобы получить необходимые роли и разрешения для выполнения своей работы.
Паттерн 7 — история релизов
Разверните тегированные релизы в продакшн, автоматизируйте отчетность и оставьте историю развертываний.
"Релизный шлюз" (release gate) в виде кода и стандартизированные процессы релиза позволяют выпускать релизы по требованию.
Автоматизированные релизы оставляют историю, которую можно проанализировать в дальнейшем.
Release gate может вызывать внешние API и использовать ответ, чтобы решить продолжать релиз или остановить его.
Проблемы
Мы все чаще встречаем эти семь паттернов пайплайнов и используем их при работе с клиентами. Но несмотря на то что они представляют собой огромный скачок вперед с точки зрения скорости и стабильности, они не лишены недостатков.
Безопасность — это самая большая проблема, которую мы видим. Она связана со сложностью автоматизации процессов, которые традиционно были ориентированы на человека. Сложность пайплайнов, принятие командой, изменение в культуре и автоматизация баз данных — другие серьезные проблемы, над которыми нужно работать. Но это все решаемо, и мы ежедневно работаем над этим.
Итог
Гибкость бизнеса основана на гибкости кода. Для современных цифровых продуктов и сервисов возможность быстрого и безопасного релиза по требованию является реальным конкурентным преимуществом бизнеса. Пайплайны кода и, в частности, описанные семь паттернов могут помочь вашей организации сделать гигантский шаг вперед в скорости и стабильности релизов, а ваши команды будут работать на уровне лидеров.