Материал входит в серию статей о build vs buy в HRTech.

DevOps. Независимо от способа использования инфраструктуры, вам довольно рано понадобится DevOps. Даже внутри облачной среды кто-то должен развернуть и поддерживать ваши окружения: разработку, тестирование, demo, pre-prod, production и другие. Их набор может отличаться в зависимости от зрелости продукта и принятых правил разработки, но очень быстро становится понятно: одной среды недостаточно.

Это неизбежно. Вам нужно где-то показывать продукт пользователям, пока команда продолжает работу. Нужно где-то проверять изменения до выхода в production. Нужны бэкапы, мониторинг, логи, доступы, процессы поставки и восстановления. Это отдельный мир.

Моя задача здесь проста: показать, что без DevOps более или менее серьёзную разработку вести невозможно. Вопрос не в том, нужен он вам или нет, а в том, будет ли эта роль находиться внутри команды или закрываться по сервисной модели.

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

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

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

Мой совет — не откладывайте неизбежное. Берите QA, чтобы с самого начала выстраивать процесс тестирования параллельно с процессом разработки. И сразу закладывайте автотесты: они сильно помогают с регрессией.

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

Читайте полную версию https://dzen.ru/a/ae-ooaiLEzJN5gYz