Сегодня мы поделимся критериями, которые используют команды True Engineering, чтобы удостовериться в качестве продукта при поставке на Prod.

Что значит «продукт готов»? У каждого разработчика может быть свой ответ на этот вопрос. И хотя в общем и целом представления могут совпадать, рано или поздно любой команде понадобится выработать некий язык, который позволит смотреть на продукт с одних и тех же позиций и выдавать стабильный результат.

Эти единые представления и составляют понятие Production Readу. Когда команда договаривается о требованиях, которым должен соответствовать продукт, разработчикам становится проще работать. Все вкладывают в понятие готовности единый смысл, значит результат не меняется от разработчика к разработчику – не будет такого, что кто-то не стал делать логирование, потому что посчитал, что почему-то не нужно. У менеджера проекта меньше головной боли – он знает, в каком состоянии получит продукт и что можно гарантировать заказчику.

Наш набор критериев Production Ready объединил и наши собственные знания, и лучшие практики из «внешнего мира» разработки. Этот момент стоит отдельно подчеркнуть – необязательно брать под копирку чужой опыт, у вашей команды может быть свой стиль работы. Главное, чтобы он был эффективным и соответствовал единому стандарту.

Итак, как мы понимаем, что наш продукт действительно Production Ready?

Он соответствует требованиям проекта. Этот пункт прежде всего предполагает, что такие требования существуют, они формализованы и задокументированы. Сюда входят и запросы клиента, и пожелания пользователей, и технические требования окружений. Все участники команды про эти требования знают и ориентируются на них при разработке.
Продукт имеет хорошо продуманную архитектуру. То есть она формируется не стихийным образом. Если решение заранее спроектировано, его архитектура учитывает возможные риски и перспективы развития. Такой подход позволит команде продумать отказоустойчивость продукта, заранее определиться с техническими средствами, которые обеспечат нужную функциональность, и проверить их совместимость. Иначе в будущем может выясниться, что внедрить нужную фичу нельзя без того, чтобы переделывать фундаментальные модули продукта. От архитектуры зависят другие критерии – мы ещё не раз к ней вернёмся.
Систему можно протестировать. В данном случае мы не имеем в виду 100-процентное покрытие тестами (хотя это тоже полезная вещь). Важно закладывать саму возможность оценить работоспособность системы до того, как она запущена в бой. Не так важно, будут ли это ручные проверки или автоматизированные тесты – главное, чтобы продукт сам по себе мог получать тестовые данные и выдавать результат. На низком уровне это означает, например, что в решении нет сильно связанных классов и каждый модуль можно проверить с помощью абстракций и mock-ов. На верхнем – что у вас есть тестовое окружение и проверки работоспособности не вызовут проблемы у реальных пользователей.
Продукт работает стабильно. Не бывает систем, которые работают бесперебойно 100% времени, поэтому под стабильностью следует понимать соответствие SLA. Эти требования меняются от продукта к продукту, а иногда - даже от одного модуля системы к другому. У сайта-визитки и учётной системы принципиально разные требования к стабильности. Самое главное, чтобы они были прописаны в SLA, а команда гарантировала их выполнение.
Решение готово к поддержке. У команды есть логи и средства мониторинга, а разработчики могут быстро установить, что сломалось и как это починить. Плюс ко всему, продукт должен быть пригоден к ремонту, т.е. провести диагностику и исправить ошибку можно без переписывания всего приложения. Иногда решить проблему с продуктом не удаётся из-за ошибок на архитектурном уровне – например, разработчики выбрали шину, которая не справляется с потоком запросов, и менять нужно всю систему.
Систему можно масштабировать. Ещё один пункт, который закладывается в архитектуре. Важно помнить, что можно экономить на ресурсах, но не на технологиях. Например, при запуске продукт должен справляться с тысячей запросов в час, а через год число пользователей вырастет, и нагрузка дойдёт до десяти тысяч. Команда должна заранее представлять жизненный цикл своего продукта, понимать, какие технологии потребуются на каждом этапе и как обеспечить их работоспособность.
Продукт задокументирован. Опять же, в первую очередь речь о самой возможности готовить документацию. В широком смысле продукт должен документироваться автоматически – описание взаимодействий, инфраструктуры и т.д. должно содержаться прямо в коде.
Продукт работает. Это может показаться очевидным, но нужно понимать, что пока решение не запущено на боевом сервере и с ним не работают реальные пользователи, систему нельзя считать готовой. Если код, который выполняет все требования, лежит в Gitlab, а не запущен на сервере, продукт не готов.
Продукт приносит ценность. Это самая обширная тема, о которой можно написать отдельную статью, а то и книгу. Не погружаясь в подробности, скажем так: система решает возложенную на неё бизнес-задачу, продает билеты или страховки, обеспечивает взаиморасчеты с клиентами, помогает сотрудникам оформлять отпуска и т.д.

Единые критерии Production Ready помогут вам добиться одинакового результата, вне зависимости от того, кто создаёт продукт или кто управляет каждым конкретным проектом. Рекомендуем брать этот метод на вооружение всем, кто хочет выстроить для своей команды простые, прозрачные и логичные правила разработки.

Production Ready: как проверить работоспособность продукта