Текстовый курс по DevOps

Как спроектировать конвейер непрерывной поставки и развёртывания DevOps?

Во многих организациях, вероятно включая вашу, разработчики пишут код изолированно в отдельных ветках. На первый взгляд такой подход повышает индивидуальную производительность, но от него страдает производительность команды.

Отдельные ветки затрудняют слияние кода нескольких разработчиков. Чтобы объединить разные части, добиться их согласованной работы и предоставить клиентам новые функции и преимущества, обычно нужно привлечь нескольких разработчиков, многое переделать и разрешить конфликты, которыми стоило заняться намного раньше.

Без непрерывной интеграции проблема усугубляется

Как ни парадоксально, из-за сложности и утомительности слияния кода большинство команд объединяют его только перед передачей приложения на интеграционное или пользовательское приёмочное тестирование. Это усугубляет проблему. Всю ответственность за успешную интеграцию и качество общего кода они перекладывают на команды обеспечения качества. Это не только нелепо, но и прекрасно объясняет, почему проекты задерживаются, перерасход бюджета растёт, настрой и мотивация команд ухудшаются, организации не выполняют цели и обещания, а компании по всему миру ежегодно тратят впустую около 600 миллиардов USD на внеплановую ИТ-работу, не предусмотренную бюджетом. Иными словами, на переделки и обходные решения в ИТ…

Как вам поможет разработка на основе общей ветки (trunk)?

Решение — разработка на основе общей ветки в сочетании с непрерывной интеграцией и автоматизацией тестирования. В этой модели управления версиями разработчики совместно работают в одной ветке, называемой trunk, и не поддаются давлению с целью создать другие долгоживущие ветки разработки.

Разработка на основе общей ветки — ключевое условие непрерывной интеграции и, следовательно, непрерывной поставки. Когда разработчики вносят изменения в основную ветку несколько раз в день, легко выполнить главное требование непрерывной интеграции: каждый участник команды должен вносить изменения в основную ветку как минимум раз в 24 часа. Так код всегда готов к выпуску по запросу, а непрерывная поставка становится возможной.

Непрерывная интеграция позволяет поставлять код небольшими порциями, готовыми к развёртыванию

Когда разработчики часто вносят код, размер пакетов разработки и поставки уменьшается. Это улучшает качество и упрощает решение проблем и конфликтов. Непрерывная интеграция с ежедневными коммитами помогает команде создавать небольшие, но содержательные части кода, готовые к развёртыванию, без нарушения работы систем непрерывной интеграции и поставки. Обновления в общем репозитории также позволяют вам и команде быстро согласовывать действия, принимать решения и обмениваться обратной связью.

Каждый раз при внесении кода система непрерывной интеграции запускает автоматизированные тесты функций, которые зависят от изменённого модуля или могут быть затронуты. Если что-то перестало работать, автор коммита отвечает за исправление в первую очередь. В этот момент важнее всего дать остальной команде возможность продолжать интегрировать свою работу в основную ветку. Пока ошибочный коммит не исправят или не откатят, другие коммиты в этот модуль основной ветки запрещены, чтобы сохранить её стабильность и надёжность.

Если вы не согласны с этим принципом DevOps, ответьте на вопрос: зачем добавлять новый код в модуль, в котором уже есть ошибки?

У вас могут быть веские причины. Но следите за тем, чтобы не накапливать технический долг и не добавлять обходные решения поверх уже существующих.

Коммиты с предварительной проверкой дополнительно защищают разработку на основе общей ветки

Ваша команда DevOps также может использовать коммиты с предварительной проверкой, чтобы повысить качество и дать основной ветке дополнительную защиту.

При каждой попытке разработчика внести код сначала запускаются автоматизированные тесты. Код вносится в основную ветку только после успешной проверки.

Используйте среды, близкие к рабочим, на каждом этапе потока создания ценности ПО

Ещё одна типичная проблема ИТ-организаций — расхождения между рабочими средами и средами разработки, интеграции и тестирования. Могут различаться настройки, версии и уровни обновлений операционных систем, баз данных, сторонних инструментов и API. В разных рабочих и предрабочих средах могут быть и разные версии собственного кода. Даже небольшое различие версий JVM между ними способно определить успех или провал всего развёртывания. Если вы не контролируете среды полностью и не знаете, из чего они состоят, вы не сможете предсказать результат их работы.

Сделайте управление средами частью повседневной разработки и поставки ПО

Предрабочие системы должны воспроизводить рабочие. Дайте команде возможность автоматически и самостоятельно создавать среды по запросу, чтобы безопасно выполнять повседневные задачи разработки в условиях, близких к рабочим.

Поток создания ценности в ИТ приносит пользу и кодом ПО, и средами, в которых он работает. Специалистам по разработке и эксплуатации важно понимать, что у потока есть две одинаково важные составляющие:

1. Код для создания ПО, которое приносит пользу вашим внутренним и/или внешним клиентам.
2. Код для создания предрабочих и рабочих сред, в которых размещается ваше ПО.

Управляйте ПО и средами из единого источника данных — основной ветки
(то есть внедрите инфраструктуру как код, IaC)

В DevOps задачи по созданию предрабочих и рабочих сред становятся частью основной ветки. Это и есть инфраструктура как код в чистом виде. Изолированным командам эксплуатации трудно знать особенности ПО, которое должны обслуживать среды. Поэтому разработчики и специалисты эксплуатации создают инфраструктуру как код вместе.

Чтобы одинаково внимательно относиться к коду ПО и коду сред, храните и то и другое в едином источнике данных — основной ветке.

Чтобы вы могли создать все предрабочие и рабочие системы и конвейер развёртывания, включая средства непрерывной интеграции и поставки, храните в системе управления версиями код ПО, необходимые настройки и сценарии, а также всё остальное для создания полной цепочки поставки. Если нужно навсегда изменить настройку среды, внесите изменение в сценарий её создания. Тогда следующему участнику команды DevOps не придётся придумывать решение заново.

Большинство подробных документов быстро устаревает. Лучше направить силы на то, чтобы сценарии создания сред оставались актуальными. Без сред, доступных в режиме самообслуживания по запросу, облачная инфраструктура останется ещё одной недоиспользуемой площадкой, а инициатива DevOps — очередной попыткой улучшить процессы, возможности которой не реализованы. Вы должны иметь возможность полностью создавать рабочие и предрабочие среды из системы управления версиями. С DevOps среды проще и быстрее пересоздать, чем чинить. Изменять их вручную больше нельзя. Пересоздавать, настраивать и запускать среды должны только код и конфигурация.

У вас новое определение готовности (DoD)

Когда система непрерывной поставки и конвейер развёртывания уже работают, вам нужно новое определение готовности (DoD).

Задачу теперь можно считать готовой, когда связанные с ней функции и возможности для клиентов:

• собраны из основной ветки автоматически или одним нажатием кнопки,
• проверены автоматизированными тестами в средах, близких к рабочим,
• продемонстрированы в средах, близких к рабочим,
• готовы к развёртыванию или, ещё лучше, уже развёрнуты в работающих системах автоматически или одним нажатием кнопки.

ВЫВОДЫ

С DevOps интеграция кода становится частью повседневной работы вместо отдельного этапа в конце проекта. Разработчики, команды эксплуатации и специалисты по информационной безопасности многократно отрабатывают развёртывание в процессе разработки. Это, несомненно, повышает вероятность беспроблемного развёртывания в рабочей среде.

Внедрение непрерывной интеграции также повышает результативность бизнеса, стабильность ПО и сред, удовлетворённость работой и качество обслуживания внутренних и внешних клиентов.