40 релизов в неделю: зачем и как переходить на режим непрерывной поставки

Руководитель команды разработки в ГИС Торги Егор Савочкин выступил на нашей конференции AgileDays 2022. По теме своего доклада он написал длинную статью на habr, где рассказал об опыте перехода от ежемесячных релизов к релизам по 6–10 раз в день. А в этой статье — ключевые идеи Егора. 

Пять лет назад разработчики Amazon рассказали, что между их релизами проходит 12 секунд. Их подход заключается в том, что они разбивают системы на маленькие сервисы, которые развивают небольшие автономные команды. А они выпускают маленькие изменения — вплоть до исправления одной строчки кода.

Сначала подход вызвал у Егора недоумение — в то время его команда делала релизы раз в месяц, а между ними была еще неделя для хотфиксов. Но сейчас в проекте ГИС Торги команда делает около 40 релизов в неделю. Непрерывная поставка по сравнению с поставкой по итогу спринтов показывает улучшения в разы.

С чего все началось: две строчки кода и 14 часов на решение проблемы

В одном из проектов VIP-клиенту нужно было срочно разместить данные, но при сохранении возникала ошибка. Егор нашел разработчика, который за пару минут внес исправления и добавил их в main, а после — пошел тестировать доработку. 

Оба стенда были заняты, поэтому руководителю проектов пришлось останавливать работу на одном из них и отдавать его Егору. Вместе с получением доступа к стенду, тестированием, согласованием и исправлением ошибок решение заняло 14 часов и потребовало вовлечения DevOps-инженера, тестировщиков, разработчика и других специалистов. А еще пришлось остановить систему на два часа — и все ради изменения двух строчек кода. 

Егор подумал, как можно было бы решить ситуацию проще:

• Он видит проблему, вносит изменения в код, добавляет в тесты в main.
• Автоматически запускается пайплайн развертывания, в рамках которого в специальной песочнице прогоняются модульные и интеграционные тесты.
• Пайплайн падает с ошибкой. Егор исправляет код, запускает в main, ждет завершения пайплайна. 
• Все готово: сборка разворачивается на продуктиве автоматически без остановки системы. Исправление ошибки заняло 20-30 минут и задействовало только одного человека.

Примерно так Егор теперь работает в проекте ГИС Торги. О том, какие практики нужно внедрить для перехода на подобный режим — далее. 

Практика №1. Уменьшение размера задач

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

Теперь аналитики в команде прорабатывают концепцию решения с заказчиком, но не пишут детальные спецификации: вместо этого они разбивают решение на большое количество маленьких задач. Они должны занимать не больше 2-3 дней разработки и быть понятными как пользователю, так и заказчику. Например, вместо большой задачи реализации реестра лотов получилось 30-40 маленьких задач, которые релизят по мере готовности.

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

Практика №2. Фича-флаги

Фича-флаги — это условие «if then» в коде, которое активирует или деактивирует функциональность в зависимости от настройки. Решение поможет деактивировать раздел сайта, который пока не реализован.

Фича-флаги удобны для разработки экспериментальных функций. Они дают много дополнительных возможностей. Например, позволяют делать Blue/Green Deployment для повышения доступности и использовать канареечное тестирование, что делает релизы более безопасными и снижает затраты на тестирование.

Практика №3. Автоматизированное тестирование

Автоматизированное тестирование (АТ) — это сердце непрерывной поставки, но его сложно внедрить. Если модульные и интеграционные тесты работают быстро и надежно, то с end-to-end тестами возникают проблемы. Они медленные, часто ломаются и обычно их делают силами внешних команд — для старта это нормально, но с течением времени они только мешают, поэтому end-to-end тесты должны писать сами разработчики.

Но end-to-end тестам мешает психологический момент. Они требуют постоянных усилий для актуализации — это не очень популярное занятие у разработчиков, поэтому менеджеру нужно постоянно следить за тестами. Команда Егора попробовала всё и сделала вывод, что end-to-end тесты оказываются рабочими, только если запускать их при каждом мерже в main. Если мержи маленькие, — не более пары дней работы одного разработчика — то сразу видно, кто сломал тесты и кто должен их починить.

Практика №4. Автоматизация инфраструктуры

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

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

«Рекомендую почитать книги Джина Кима, где очень большой фокус делается на улучшении проектной инфраструктуры (например, Проект Феникс или The Unicorn Project). Много информации можно почерпнуть из книг Google по SRE».

Практика №5. CI/CD пайплайн

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

Эта практика называется CI/CD-пайплайн. Суть в том, что по триггеру или после ручного запуска создается дистрибутив и прогоняется вся необходимая последовательность тестов. Если они завершились удачно, то дистрибутив считается корректным и его можно развернуть на продуктив. Если нет — забраковываем дистрибутив, исправляем и запускаем новый пайплайн. 

Наилучший эффект от CI/CD-пайплайна достигается тогда, когда он запускается автоматически при каждом коммите каждого разработчика (если коммиты тоже частые). В этом случае, если что-то сломалось, диагностика тривиальна, а исправление занимает очень мало времени.

Общая схема

Как правило, новая система изначально разрабатывается как монолитное приложение — это самый простой и надежный подход. Но если система бурно развивается, CI/CD-пайплайн будет отрабатывать все дольше, а доработки начнут тормозить друг друга. Чтобы кардинально решить эту проблему, нужно разрезать систему на независимые модули, или микросервисы. 

В ГИС Торги Егор пошел по такому пути. Получилось больше десяти основных микросервисов. Каждый из них — независимое приложение со своим UI, логикой и хранилищами, которое имеет свой репозиторий, АТ, CI/CD-пайплайн и может выпускаться независимо от других микросервисов.

Выводы

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

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

Режим непрерывной поставки с очень частыми релизами может снижать затраты на «менеджмент». Например, если у вас не было других причин работать спринтами (помимо регулярных релизов), теперь вы можете отказаться от спринтов. И тогда не нужно будет планировать их, разбираться, если запланированная задача не может быть сделана к дате завершения спринта, и так далее. 

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

Уменьшение размера релиза дает заказчику возможность заниматься более важными задачами — он видит на продуктиве или на демо-стендах все, что было сделано. Частые релизы позволяют делать MVP и быстро проверять свои гипотезы. Если у заказчика меняются приоритеты, производственная команда может очень быстро изменить направление движения и при этом понести адекватные накладные расходы.