Создаём сервис быстрого запуска stage-серверов

Evrone много внимания уделяет качеству проектов. Использование инструментов DevOps давно стало частью нашей культуры, а некоторые клиенты даже просят у нас внедрить «управление разработкой в стиле Evrone» у них в компаниях. Поэтому когда появился Docker, мы сразу обратили на него внимание.

С его помощью мы создали проект Teatro.io, который автоматизировал создание тестовых (stage) серверов для демонстрации и проверки фич.

Какие проблемы решает teatro.io?

1) Высокая стоимость поддержки собственных тестовых серверов

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

2) Необходимость большого количества серверов для больших команд

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

Как устроен teatro.io?

С помощью Docker мы создали on-demand SaaS-решение, под капотом у которого была автоматизированная работа системного администратора и DevOps-специалиста. Вот как оно работает.

Как только разработчик отправляет пулл-реквест с новой фичей, к нему тут же привязывается ссылка вида «teatro.io/request_code». Нажатие на ссылку инициирует запуск тестового сервера в облаке. В течение 1–5 минут (в зависимости от требований к окружению) сервер с уже задеплойенной на нём функцией запускается и доступен для демонстрации.

Если в течение часа teatro.io не фиксирует обращений к ссылке, то сервер отключается, но ссылка остаётся рабочей — при повторном нажатии на неё снова происходит автоматическое развёртывание приложение на staging сервере.

Как мы проверили жизнеспособность технологического стартапа?

Первыми пользователями нашего сервиса для автоматического развёртывания облачного stage сервера стали команды Spree, OpenProject и GitLab. С их помощью мы проверили основные продуктовые гипотезы и превратили MVP в полноценный продукт и занялись поиском «product-market fit».

Оказалось, что потребность в разработке инструментов DevOps на рынке есть, но не в b2c, а в b2b-сегменте. Большие корпоративные команды действительно могли серьёзно сэкономить, используя teatro.io. А вот маленькие команды использовать сервис не могли.

Дело в том, что teatro.io работал с «отполированными» проектами, которые были готовы к автоматизированному деплойменту. Такие проекты поддерживали roll-back, имели файлы с описанием необходимого окружения. Такой подход требовал высокой инженерной культуры, которую можно поддерживать только в компаниях уровня корпораций.

Маленькие команды из нескольких человек действовали проще, где-то игнорируя общепринятые стандарты разработки, делая допущения и упрощения. И это было правильно с их точки зрения, потому что более серьёзный подход к тонким настройкам замедлил бы их работу.

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

У нас получился продукт с потенциальный рынком, как у гиганта вроде SAP — 10–20 компаний, до которых нам пришлось бы дотягиваться индивидуально. Оценив требуемые инвестиции и стратегию teatro.io, мы превратили его во внутреннее решение для нужд Evrone и некоторых клиентов.

Если вашему проекту нужны инструменты для автоматизации деплоя (continuous deployment and delivery), заполните форму внизу, чтобы наши DevOps специалисты связались с вами.