Hello, production: почему первый релиз стоит сделать как можно раньше

Перевод статьи «Hello production»

Рассказывает Пит Ходжсон

Я часто помогаю командам разработчиков в первоначальной сборке и выпуске продукта. И в первые же дни я всегда даю совет: разверните на сервере самую простую версию вашей системы. Сконцентрируйтесь исключительно на том, что необходимо для запуска «Hello, world» версии в боевой среде. Я называю это «Hello, production».

Релиз «Hello, production» для веб-приложения не должен содержать больше одной страницы, которая отвечает кодом 200 с каким-либо текстом (например «Hello, world»). Если в этой версии есть полезные функции — вы сделали слишком много. Но если ваша система не отвечает на живой трафик в боевой среде, то вы сделали недостаточно.

Какой в этом смысл?

Tracer Bullet

Насколько мне известно, термин Tracer Bullet («трассирующая пуля») впервые был введён в книге «Программист-прагматик» Э. Ханта и Д. Томаса. Идея в том, что при исследовании нового подхода или среды вы создаёте прототип с минимальным набором функций, чтобы удостовериться, что нововведение вам подходит. Однако «трассирующий» код — это не одноразовый прототип. Он станет основой будущей работы.

Релиз «Hello, production» похож на Tracer Bullet. Он тоже:

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

Малый объём первоначальной версии (помните, никаких полезных функций) позволит первой Tracer Bullet выйти как можно скорее, что даст ценный отклик. Вы рано узнаете о препятствиях, которые должна преодолеть команда, чтобы развернуть и запустить продукт в продакшн.

Linux System Administrator / DevOps Sportmaster Lab, Москва, от 150 000 до 350 000 ₽ tproger.ru

Вакансии на tproger.ru

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

«Ходячий скелет»

Я позаимствовал идею «Hello, production» из замечательной книги «Growing Object-Oriented Software, Guided by Tests», которая представляет эту концепцию в качестве примера «ходячего скелета».

Релиз «Hello, Production» представляет собой минималистичную, но функциональную версию нашей системы. После того как скелет системы создан, мы можем начать добавлять функциональность — наращивать мясо на кости. Один программист может начать работу над фронтендом, в то время как другой займётся хранилищем данных, а третий — интеграцией со сторонним API. Если у нас есть «ходячий скелет», всё это можно делать одновременно и начать работу значительно раньше. Команда может распределиться по более широкой кодовой базе, независимо создавая и выпуская фичи.

Несколько потоков выгодны даже для совсем небольшой команды. Часто бывает, что один поток временно блокируется, особенно на ранних этапах разработки. Возможно, вы не можете добиться прогресса в интеграции стороннего сервиса, потому что он ещё не закончил работу над API, или не можете работать над интерфейсом, потому что ждёте, когда дизайнер создаст макеты некоторых страниц. Благодаря «ходячему скелету» можно не ждать, а сразу переключаться на другой поток.

Непрерывный конвейер доставки

«Hello, production» позволяет на ранней стадии внедрять методы непрерывной доставки. Он должен помочь не только протестировать инфраструктуру новой системы, но и установить механизмы безопасной поставки изменений после полноценного запуска — базовый непрерывный конвейер доставки. Сначала он будет довольно сырым — без сложных этапов автоматизированного тестирования, а некоторые этапы развёртывания могут выполняться вручную (надеюсь, что хотя бы в соответствии с контрольным списком).

Начать с примитивного конвейера доставки — нормально, это «ходячий скелет», такой же, как программа «Hello world». Прототип конвейера позволит команде улучшать его с течением времени: автоматизировать ручные процессы, добавить Quality Gates, улучшать прозрачность процесса поставки, оптимизировать медленные этапы конвейера и так далее. Только начав регулярно использовать конвейер доставки, вы увидите, что нужно исправить.

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

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

Насколько минимальным должен быть «Hello, production»?

Когда вы только начинаете, сложно понять, до какого минимума нужно сокращать «Hello, Production», а то, что он должен стать «бесполезным» звучит совсем странно. По моему опыту, чтобы сократить исходную систему, нужно сделать несколько подходов. Даже если вам кажется, что убирать больше нечего, спросите себя: «Могу ли я упростить систему ещё немного, оставив что-то, что будет отвечать на трафик?».

Звучит хорошо, но…

Когда я советую командам разработчиков делать «Hello, Production» релизы, мне часто возражают.

«Наш продакт-менеджер хочет видеть полезные функции»

Частые релизы работающего программного обеспечения — это здорово. Но создание «Hello, production» не означает, что мы откладываем разработку функциональности. Просто мы делаем дополнительный релиз даже раньше, чем первый коммит в мастер-ветку.

Свой первый «Hello, production» не обязательно демонстрировать руководителям, им стоит показать первый «настоящий» релиз с полезными функциями.

«Лучше подождать и сделать полноценный первый релиз»

Идея того, что релиз большими партиями более «эффективен», звучит довольно часто. Кроме того, исследование из книги «Accelerate» Н. Форсгрена, Д. Хамбла, Д. Кима, показывает, что организации, которые быстрее выпускают продукцию, чаще всего более прибыльны и продуктивны. Первоначальный релиз «Hello, production» помогает задать команде такой темп с самого начала.

«Будет сложно заставить что-то работать на боевом сервере»

Если вы работаете в крупной компании, нужно приложить много усилий, чтобы что-то заработало. И это ещё одна причина начать путь как можно скорее. Готовый к релизу «Hello, production» уменьшит количество процессов, необходимых для выпуска готового ПО. Я обнаружил, что на вопросы «Что нужно будет сделать, когда мы будем готовы к первому релизу?» и «У нас есть готовый релиз. Что ещё нужно сделать, прежде чем мы сможем его запустить?» люди дают принципиально разные ответы.

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

«Мы не можем залить на боевой сервер незаконченный продукт»

Многие компании не привыкли развёртывать неполное ПО на рабочем сервере. Руководство может спросить, почему вы хотите залить сервис до того, как ваша команда приблизится к завершению работы над первой версией продукта. Тем не менее большинство людей открыты для концепции «Hello, production», если сначала объяснить, зачем это нужно.

Вероятно, вам нужно будет придумать, как закрыть публичный доступ к вашему незаконченному продукту. В небольших организациях я делал это, скрывая все веб-страницы за окном авторизации. В крупных организациях мы не создавали рабочие записи DNS, пока не были готовы к запуску, или не добавляли производственные серверы в общедоступную подсеть. Обратите внимание, что команда по-прежнему должна иметь возможность работать над проектом (даже если он доступен только в корпоративной сети), а также проводить демонстрации, выполнять пользовательское тестирование и так далее.

Релиз «go-live» продуктов, которые начинаются с «Hello, production», как правило не требует активного участия системных администраторов. Зачастую необходимо лишь создать запись DNS или изменить конфигурацию сети, чтобы открыть действующую систему внешнему трафику. Я знаю немало системных администраторов, которые приняли концепцию «Hello, production», увидев, что с ней запуск в продакшн становится тривиальным.

Начните так, как хотите продолжить

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

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

Не смешно? А здесь смешно: @ithumor