Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.
Небольшой Time To Market позволяет бизнесу опережать конкурентов и быстрее получать прибыль от продуктов. Даже Греф еще в 2016 году говорил, что главное для IT-компаний — выводить продукт на рынок быстрее.
Чтобы решить эту проблему компании пытаются оптимизировать процессы — чаще запускают эксперименты, создают кросс-функциональные команды на замену отдельным департаментам разработки и дизайна. Однако они упускают из вида, что время до выхода продукта на рынок можно сократить, если перестать тестировать задачи на одном сервере. Подробнее о том, почему так происходит, расскажу ниже.
Почему один рабочий сервер на всю команду — не ок
Когда все разработчики команды тестируют свои задачи на одном сервере, сначала все работает нормально. Фичи затрагивают разные части проекта и не противоречат друг другу.
Однако со временем таски разработчиков наслаиваются и начинают мешать тестированию друг друга — особенно когда у одного разработчика одновременно несколько незавершённых задач в работе. Проблема обостряется, когда часть задач встали на холд, а новые таски с ними пересекаются.
Упрощенный пример: в компании было решено перекрасить сайт в желтый и протестировать нововведение на общем сервере. Редизайн всего сайта — серьезное изменение, поэтому согласование затянулось. Вместо этого была поставлена новая задача: перекрасить в желтый цвет только одну кнопку сайта.
Разработчик, ответственный за эту задачу, столкнется с проблемой — на общем сервере весь сайт желтый, из-за чего тестирование новой желтой кнопки невозможно.
Для решения этой ситуации разработчику придется искать часть кода, которая пересекается с его задачей. Затем согласовывать с теми, кто эту фичу делал и тестировал, что её можно удалить из тестового сервера. А затем тратить время на вычищение этого участка кода с тестового сервера.
Получается, что помимо самой задачи разработчику придется разбираться еще и с тем, кто и что делал, какие фичи актуальны, а какие — нет. В результате, драгоценное время разработчиков тратится не на новые фичи, а на бессмысленную суету, и TTM растёт.
Когда на сервере всего несколько конфликтующих изменений, с этим не так сложно справиться. Можно потратить дополнительные ресурсы и разобрать каждый конфликт вручную. Однако рано или поздно накапливается критическое количество конфликтных изменений, которое в итоге ломает весь сервер и полностью останавливает возможность тестирования фичей.
Итог: новые фичи не доставляются до пользователя.
У многих возникает соблазн решить эту проблему одним из двух простых способов. Подробнее о них ниже, но, спойлер, решить проблему «в лоб» не получится.
Решение в лоб #1. Очередь на тест
Одно из логичных решений проблемы — заставить разработчиков пользоваться сервером по-очереди. Так их задачи не будут взаимодействовать, а значит и не будут конфликтовать.
В этом случае создается бутылочное горлышко, которое тормозит работу. Помимо ожидания своей очереди для тестирования фичи, сотрудники теряют время на обсуждение очередности работы с сервером. В результате процесс введения изменений затягивается.
Решение в лоб #2. Не хватает одного сервера — сделаем несколько
Кто-то решает проблему конфликтов изменений, создавая несколько серверов: по одному на каждого разработчика. Этот вариант кажется более логичным. Разработчики работают независимо друг от друга, а значит не пересекаются друг с другом.
Однако разработчики редко работают одновременно только над одной задачей. Как правило, разработчики по одной задаче пишут код. По другой ждут фидбека от менеджера, по третьей — фидбека от тестировщика по исправленному багу, а по четвёртой — фидбека по код-ревью от коллеги.
В этом случае разработчикам приходится либо постоянно исправлять конфликты изменений, либо перезаливать ту задачу, которую первее нужно показать менеджеру.
Как решить проблему по-человечески: динамические окружения
Динамические окружения — это подход, при котором для тестирования каждой фичи автоматически разворачивается полная копия сервиса, который сейчас доступен пользователям. Но к этой копии применены изменения, касающиеся только одной новой фичи.
Простыми словами: суть динамических окружений в том, чтобы выдавать каждому разработчику столько серверов, сколько фичей у него находится в работе. Каждую фичу можно показать менеджеру и тестировщику на отдельном сервере.
Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику.
Чем динамические окружения хороши
Можно выделить несколько преимуществ динамических окружений:
— Экономия времени. Динамические окружения создаются и удаляются автоматически, поэтому разработчики не тратят время на то, чтобы положить изменения на сервер.
— Изолированные задачи. Динамические окружения предотвращают конфликты изменений — если один разработчик что-то сломал на одном из своих тестовых серверов, это не повлияет на работу других своих задач и задач других разработчиков.
— Доступность в любой момент. Благодаря динамическим окружениям разработчики могут использовать сервер в любой момент. Им не нужно ждать своей очереди для тестирования рабочих фичей.
А как настроить динамические окружения?
Внедрить динамические окружения — единоразовая работа. Если в команде нет людей, которые уже раньше это делали, то средние затраты по нашим опросам занимают 4-6 человеко-месяцев в зависимости от квалификации инженеров и сложности проекта.
Мы же можем настроить динамические окружения за 2 недели.
Будем рады провести консультацию для вас и вашей команды и помочь в настройке динамических окружений поверх Kubernetes.
Пишите в телеграм: ссылка
Комментарии (25)
supersmeh
31.10.2023 09:57+2У нас это называется:
"фича-инфраструктура" - временное окружение со своими временными репозиторями пакетов, бд и т.п., и "фича-стенд" - стенд для тестировщика/аналитика, развернутых на базе "ФИ". на нём происходит функциональная приема и тестирование, устранение выявленных багов. Когда всё проверено и готово - тогда код попадает в мастер затронутых пакетов.
IVNSTN
31.10.2023 09:57+1С базами данных как порешали?
LeoGV
31.10.2023 09:57Все зависит от конкретного окружения, например: можно использовать операторы в kubernetes и с помощью init-контейнеров заливать данные; в яндекс облаке есть интересный инструмент data transfer, с ним и питоном в обнимку не сложно организовать процесс изготовления обезличенных данных из продовой/препродовой среды (о нем писали в курсе про динамические среды - https://cloud.yandex.ru/training/devops)
IVNSTN
31.10.2023 09:57Так я про решение этой задачи в вашем конкретном решении по "отдавать версию под каждую фичу" из статьи спрашиваю, зачем мне ссылки на курсы. "Мы оставили это за скобками и БД решением не покрыты" - простая и понятная фраза, хоть и не объясняет как же каждая отдельная фича самостоятельно может существовать, если в реализации фичи задействованы БД.
uwriter Автор
31.10.2023 09:57В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Getequ
31.10.2023 09:57+3Это не сайт с объявлениями, а технический - если пишите про динамические тестовые стенды, то где оно?
Batalmv
31.10.2023 09:57+6Блин, а ведь кто-то прочитает и подумает ...
Давайте отделять мух от котлет. Чтобы тестить фичи независимо, надо иметь ТРИ вещи.
фича-бренчи (ну иначе а как вы хотите собрать приложение с этой фичей) и процесс работы в репозитории под эту идеологию
окружение под фичу/человека, или метод его создания на лету
деплой фичи на окружение
Все просто "А" "и" "Б". Как в считалочке детской. Два объекта и связь между ними.
Работа в репозитории является первичной. Ну если вы не можете собрать приложение в варианте "стабильная версия" + "желтый фон" - в этом моменте можно заканчивать. Почему автор статьи начал сразу с конца - не ясно. Наверное потому что это типа очень легко и все умеют :) Либо потому что на эту часть консалтинг не распространяется. Но на практике это так не всегда. Точнее наплодить мильон фич легко, вот собрать из них к сроку работающий продукт ...
Второй момент - это выделение окружения для сборки. Понятно, задача зависит напрямую от архитектуры. Для монолита или близких к ним - один подход, для микросервисов - второй. Плюс надо понимать, что это все в общем, а дьявол в деталях. Но я так понимаю, эти детали тоже считаются микроскопическими и ими заниматься не интересно. Либо "мы умеет только в кубер", а кто не с нами - те лузеры и неудачники.
Третье - ура. У нас есть команда, которая генерит фичи в бренчах, есть среды - можно деплоить. Так это как раз самое неинтересное. Банальный Jenkins творит "чудеса" которые были доступны миру еще Х десятилетий назад (да и под капотом там часто "технологии" постарше многих комментаторов). Зашел, выбрал версию, тыкнул "бубочку", глотнул чайку и вперед.
А в реальном мире так все может не работать, и не работает, так как есть два пряпятствия:
merge, так как фичи могут задевать одни и те же сервисы, и тест фич по отдельности без теста merge не лучшая идея
зависимость между сервисами
Понятно, что тут тоже статья это опускает, да и зачем :)
-------------
Ну а задача как поднять много сред - тоже мне бином ньютона. Банально локально поднял нужный контейнер "А*" локально, настроенный на стабильную среду и дело в шляпе. Бесплатно и как "два пальца". Понятно способ не единственный, но ... камон ... тут вообще и проблемы то нет
uwriter Автор
31.10.2023 09:57+1Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Batalmv
31.10.2023 09:57+1Много где чего-то нет. Это нормально. Но ... ну блин, конвееров CI/CD выше крыши. Технически это не проблема. Проблема не получить оптимизацию в стиле "doing shit faster"
А это как раз работа в репозитории в первую очередь. Если у вас хаос там - смысл ускорять его перенос по средам?
Да и статья - ну такое. По большому счету это неинтересно. В худшем случае закрывается Devops за 4-5 килобаксов в месяц
Kerrigan
31.10.2023 09:57+3Это работает ровно до того момента, когда поднятие еще одной копии инфраструктуры не выливается с большие требования по железу. Еще у вас может быть прод, засыпанный микросервисной крошкой, для соедининения которой воедино нужно привлечь половину обслуживающего ее персонала.
uwriter Автор
31.10.2023 09:57-1Про второй кейс скорее соглашусь, но про первый -- часы разработчиков и прочих сотрудников, задействованных в разработке в абсолютном большинстве случаев дороже, чем доп затраты на сервера для динамических окружений
Мощности же постоянно дешевеют
sshmakov
Идея хорошая.
Но а где вариант "разработчик тестирует фичу локально"? Если уж говорим про тестирование разработчиками.
astec
Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику.
sshmakov
разработчик по этой ссылке получает образ для скачивания или развернутый на сервере?
uwriter Автор
По ссылке будет развернутый на сервере проект
saboteur_kiev
А если проект это десятки ссылок и зависимостей?
У меня в проекте свыше 100 компонентов, и пишутся они разными командами, плюс базы данных, состояние которых должно быть консистентным релизной ветке, и размер баз достаточно значительный.
Всем решением свое место. Тестирование на одном сервере вполне может быть рабочим решением.
uwriter Автор
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
saboteur_kiev
Тогда не получится прорекламировать что " Мы же можем настроить динамические окружения за 2 недели."
uwriter Автор
вы всерьез рассматриваете вариант, в котором тестировщики и менеджеры смотрят фичу на компе разработчика?:)
Это хорошая возможность для какого-нибудь пет проекта, но для продакшна это ж моветон
saboteur_kiev
Тестировщики смотрят фичу на своем компе, менеджеры могут смотреть фичу на компе разработчика, если им это вдруг надо.
Но вообще для демонстрации фичи для менеджеров, организовывается специальный демо митинг, где показывают и рассказывают. Какой конкретно при этом инстанс используется - зависит от выступающего и проекта.
Чтобы менеджер сам лично ковырял фичу - какого уровня менеджер имеется ввиду тогда?
Ну и обычно есть тестовый сервер. Их не обязательно должно быть десять или сто.
Частая ситуация - QA, UAT, pre-prod, prod.
Четыре статических енва.
uwriter Автор
Может мы просто про разное говорим
Чтобы тестировщик смотрел фичу на своём компе, он же не должен разворачивать на своем компе полную версию сервиса?
А насчет тестового сервера - хоть 2, хоть 4 проблемы те же самые, что описаны в статье:
Фичи влияют друг на друга
Если какие-то фичи откладываются или зависают, то их надо руками отрывать с тестового стенда и не забыть еще это сделать до того как всё разломается
saboteur_kiev
Я про это и уточняю - в статье предлагается только один путь для единственного видения сервиса. В то время как проектов полно, и наличие множества динамических енвайрнментов не всем нужны, не всегда подходят, не всегда возможны.