Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.
Небольшой Time To Market позволяет бизнесу опережать конкурентов и быстрее получать прибыль от продуктов. Даже Греф еще в 2016 году говорил, что главное для IT-компаний — выводить продукт на рынок быстрее.
Чтобы решить эту проблему компании пытаются оптимизировать процессы — чаще запускают эксперименты, создают кросс-функциональные команды на замену отдельным департаментам разработки и дизайна. Однако они упускают из вида, что время до выхода продукта на рынок можно сократить, если перестать тестировать задачи на одном сервере. Подробнее о том, почему так происходит, расскажу ниже.
Почему один рабочий сервер на всю команду — не ок
Когда все разработчики команды тестируют свои задачи на одном сервере, сначала все работает нормально. Фичи затрагивают разные части проекта и не противоречат друг другу.
Однако со временем таски разработчиков наслаиваются и начинают мешать тестированию друг друга — особенно когда у одного разработчика одновременно несколько незавершённых задач в работе. Проблема обостряется, когда часть задач встали на холд, а новые таски с ними пересекаются.
Упрощенный пример: в компании было решено перекрасить сайт в желтый и протестировать нововведение на общем сервере. Редизайн всего сайта — серьезное изменение, поэтому согласование затянулось. Вместо этого была поставлена новая задача: перекрасить в желтый цвет только одну кнопку сайта.
Разработчик, ответственный за эту задачу, столкнется с проблемой — на общем сервере весь сайт желтый, из-за чего тестирование новой желтой кнопки невозможно.
Для решения этой ситуации разработчику придется искать часть кода, которая пересекается с его задачей. Затем согласовывать с теми, кто эту фичу делал и тестировал, что её можно удалить из тестового сервера. А затем тратить время на вычищение этого участка кода с тестового сервера.
Получается, что помимо самой задачи разработчику придется разбираться еще и с тем, кто и что делал, какие фичи актуальны, а какие — нет. В результате, драгоценное время разработчиков тратится не на новые фичи, а на бессмысленную суету, и TTM растёт.
Когда на сервере всего несколько конфликтующих изменений, с этим не так сложно справиться. Можно потратить дополнительные ресурсы и разобрать каждый конфликт вручную. Однако рано или поздно накапливается критическое количество конфликтных изменений, которое в итоге ломает весь сервер и полностью останавливает возможность тестирования фичей.
Итог: новые фичи не доставляются до пользователя.
У многих возникает соблазн решить эту проблему одним из двух простых способов. Подробнее о них ниже, но, спойлер, решить проблему «в лоб» не получится.
Решение в лоб #1. Очередь на тест
Одно из логичных решений проблемы — заставить разработчиков пользоваться сервером по-очереди. Так их задачи не будут взаимодействовать, а значит и не будут конфликтовать.
В этом случае создается бутылочное горлышко, которое тормозит работу. Помимо ожидания своей очереди для тестирования фичи, сотрудники теряют время на обсуждение очередности работы с сервером. В результате процесс введения изменений затягивается.
Решение в лоб #2. Не хватает одного сервера — сделаем несколько
Кто-то решает проблему конфликтов изменений, создавая несколько серверов: по одному на каждого разработчика. Этот вариант кажется более логичным. Разработчики работают независимо друг от друга, а значит не пересекаются друг с другом.
Однако разработчики редко работают одновременно только над одной задачей. Как правило, разработчики по одной задаче пишут код. По другой ждут фидбека от менеджера, по третьей — фидбека от тестировщика по исправленному багу, а по четвёртой — фидбека по код-ревью от коллеги.
В этом случае разработчикам приходится либо постоянно исправлять конфликты изменений, либо перезаливать ту задачу, которую первее нужно показать менеджеру.
Как решить проблему по-человечески: динамические окружения
Динамические окружения — это подход, при котором для тестирования каждой фичи автоматически разворачивается полная копия сервиса, который сейчас доступен пользователям. Но к этой копии применены изменения, касающиеся только одной новой фичи.
Простыми словами: суть динамических окружений в том, чтобы выдавать каждому разработчику столько серверов, сколько фичей у него находится в работе. Каждую фичу можно показать менеджеру и тестировщику на отдельном сервере.
Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику.
Чем динамические окружения хороши
Можно выделить несколько преимуществ динамических окружений:
— Экономия времени. Динамические окружения создаются и удаляются автоматически, поэтому разработчики не тратят время на то, чтобы положить изменения на сервер.
— Изолированные задачи. Динамические окружения предотвращают конфликты изменений — если один разработчик что-то сломал на одном из своих тестовых серверов, это не повлияет на работу других своих задач и задач других разработчиков.
— Доступность в любой момент. Благодаря динамическим окружениям разработчики могут использовать сервер в любой момент. Им не нужно ждать своей очереди для тестирования рабочих фичей.
А как настроить динамические окружения?
Внедрить динамические окружения — единоразовая работа. Если в команде нет людей, которые уже раньше это делали, то средние затраты по нашим опросам занимают 4-6 человеко-месяцев в зависимости от квалификации инженеров и сложности проекта.
Мы же можем настроить динамические окружения за 2 недели.
Проконсультируем и быстро настроим динамические окружений. Пишите в телеграм: ссылка
Картинки — огонь!)
Спасибо! Очень старались:)
Мало того, что статья классная, так и картинки прикольные, за это точно лайк
Спасибо!!!
Актуальная проблема крутое решение
Спасибо!
У вас прям отдельные сервера? Сейчас же с приходом Kubernetes + CI/CD эта проблема решается достаточно легко, даже сам тестировщик сможет развернуть, а потом потушить окружение из нужной ему ветки. Контейнеры в 21 веке маст хев в любой разработке
Их ЦА слов таких не знает, это компании с ИТ каменного века, для которых автодеплой и СИ/СД - волшебные слова какие то. Им как раз и можно продать "это занимает среднем 4-6 человеко-месяцев, мы же можем настроить динамические окружения за 2 недели".
Ну и в последней строке статьи - как раз кубер и указан. То, что во многих случаях кубер - оверкилл для мелкой компании с сайтиком, там конечно не написано :)
Кубер не оверкилл, если компания сталкивается с проблемами, описанными в статье.
Важный момент, что использование кубера в тестовой среде для развертывания отдельных окружений под каждую фичу не означает, что его нужно использовать на этом проекте в продакшне.
Так что "оверкилл для мелкой компании с сайтиком" довольно неоднозначное заявление:) Есть проблема с параллельным тестированием - не оверкилл, нет проблемы - не надо использовать (и читать эту статью)
Конечно оверкилл, так как на сапорт нужен куда более дорогой девопс с кубером, знаниями облачных кубернет движков и прочего. То есть клиент к вам привязывается на саппорт.Тогда как для деплоя традиционной связки "вебсайтик" без хайлоада достаточно докера из 4х компонентов(нжинкс, веб, апи, бд) из готовых образов, который даже разраб без особых знаний девопс осилит саппортить (ладно, и развернуть тоже).
Ладно, там даже ансиблом с супервизорд можно это без проблем развернуть и хотдеплоить, но это уже олдскул и не модно. :)
З.Ы. И отдельно - про неиспользование в проде. Заносить кубер скрипты только для деплоя тестовых стейджингов - это уже слишком смешно. Конфигурационные тестирование, не? :)
Ну для такой ситуации мы скорее посоветуем клиенту Kubernetes IaaS от Яндекс облака или других облаков, чтобы Яндексные админы заботились о доступности этого кубера
И в такой схеме это как раз не смешно, а прям то что нужно для бизнеса — геморроя минимум, дорогих девопсеров не надо нанимать, а эффект от фича-стендов для бизнеса ощутимый и конкретный.
Конечно, разработчики могут сказать что-то типа "как же так, у нас будет кубер в тесте, но не будет в проде", но по факту объективных аргументов тут не будет
А насчет конфигурационного тестирования — какая доля продуктов, у которых одна и та же фича в одном и том же докер контейнере не будет работать чисто из-за того, что в проде нет кубера?
Повторяемость окружений в тесте и проде это уже проблемы другого порядка, которая может и не возникнуть, а эффект для бизнеса от отдельных окружений под фичу четкий и легко измеримый
Какая доля продуктов? Да почти все. Особенно для компаний без штатной девопс экспертизы (ведь они к вам обратились). Обычный косяк - на тестовые задеплоилось, на прод нет, так как весь деплоймент разный. В одном месте я помню чуть ли не каждый третий деплой в прод летал по этой причине. Поэтому и придумано оное конфигурационное тестирование- когда тестовые среды используют все тоже самое, что и прод (с отличием ввиде секреток, хостов/роутов и автоскейлинга) - такие косяки минимальны, так как выкладка уже проверена на тестовом стенде
Комментарий удален автором поста
Вся статья как раз про настройку всего этого добра — мы тоже думали, что Kubernetes и развертывание нужных образов по отдельным урлам это мастхев, но оказалось что есть много компаний, которые продолжают тестировать все фичи на одном тестовом сервере
А насчет контейнеров — они действительно мастхев, но например если в качестве оркестратора используется Docker swarm, то автоматом разворачивать окружения под ветки не получится. Так что одной контейнеризацией не обойтись, нужен еще правильный оркестратор
Ну и финально — чтобы сам тестировщик развернул и потушил окружение нужной ему ветки как раз и нужно настроить всю эту среду
Комментарий удален автором поста
Простите заранее за некоторый негатив
Сама задачи нескольких окружений под фичи - очень классная, в контексте тех самых очередей.
Но 90% того что приведено в обосновании - это диагноз системной проблемы в разработке и управлении беклогом в продукте, которая несколькими окружениями не лечится никак. Системные проблемы лечат системным образом, в том числе: несколько фич в параллель у разработчика, незаконченные фичи, конфликтующие фичи - что делать в интеграции и пр.
Может показаться, что несколько фичей в параллели у разработчика это плохо и лучше чтобы она была одна. Но по факту у разрабов даже с норм процессами получается так:
- сегодня закончил задачу, отдал смотреть тестировщику
- на след день взялся за небольшой баг, который надо побыстрее докатить до продакшна, быстро пофиксил и опять надо показать тестировщику
- дальше взялся за следующую крупную задачу, параллельно тестировщик выкатил фидбек по той первой задаче
В итоге процессы нормальные, а всё равно нужно 3 сервера — под первую задачу, где надо что-то пофиксить, под вторую, которую нужно срочно посмотреть и под третью, которую еще никто не видел
А насчет незаконченных и конфликтующих фичей — плохо если это происходит постоянно. Но если периодически в ответ на изменения ситуации в наши турбулентные времена надо что-то приостановить, то доделывать чисто из-за того что уже начали нелогично.
И если из-за этого приходится еще прикладывать усилия чтобы "оторвать" задачу с тестового сервера, то это вдвойне грустно
Так что система в процессах с частой сменой приоритетов поможет прям ОЧЕНЬ сильно, а в стандартных, нормальных поможет тоже сильно. Потому что как ни крути разработчик не будет ждать, пока тестер протестит задачу, он возьмет новую
У разрабов так получается, когда не налажены процессы в разработке. Когда процессы налажены - такого нахлёста нет.
Баг не надо показывать тестировщику конечно же, когда вы делаете хот фикс. Если это хот фикс, то он скорее всего пойдёт прямо на стейджинг. Если это фикс, то он должен оказаться на интеграционном стенде, а не показанным тестировщику. В большом кол-ве проектов правильным является локальный стенд на машине разработчика, если проект маленький - как раз для ведения разработки фичи. А в больших проектах есть разные способы обеспечить фича неймспейсы. В целом, не хочется устраивать лекцию из комментария моего. Безусловно инфраструктура с тестированием должна быть. Вопрос в том, что к проблемам надо правильные решения подбирать. Иначе затыкая одну проблему не её решением, а затычкой - проблема остаётся и фактически продолжает отъедать время. Та же поддержка зависших бранчей продолжит поедать время разработчиков, как минимум на восстановление сборки и интеграции спустя время (зависимости внешние и внутренние соответственно).
Люди продают девопс услуги. Какой смогли пример придумать, такой и написали.
абсолютно согласен
пример размещён публично. Поэтому комментируется публично.
читают пример разные люди - им полезно понимать, что это под продажу пример, а не решение обозначенных проблем, как мне кажется
Ну изначально мы всё-таки разработчики, DevOps у нас появился позже. Поэтому пример взят не из головы, а из типовой разработки у нас в компании и в компаниях-клиентах
Расскажете своё видение, как у разработчика может быть не больше одной фичи в работе? В работе то есть не доведено до продакшна в разных стадиях
Это когда фича закончена, бранч влит в дев и тот в стенде
А разработчик занят другой фичей.
Да, я в одной замечательной компании приходил в ситуацию, которую запустили. Там было 40 зависших бранчей, которые подвесили за год. И это не говоря, о том, что завесили за 8 лет истории.
Не поверите - решилось всего 1 переговорами с оунером. Просто показав стоимость поддержки такого зависания.
Дропнули все в итоге. Внимательно согласовали механизм приоритезации и не меняли больше, перестав перекидываться на фичу до окончания разработки приоритезированной, оцененной, взятой в работу. Компания работает и ей пользуется в РФ ну процентов 5 населения, наверное.
То есть вашим решением было не брать разработчику другие задачи в работу, пока тестировщик не протестирует?
решение очевидно в повышении качества решений разработчика и налаживании процессов разработки на уровне модулей, которые делаются без тестировщика
И да, завершённая задача в модуле, прошедшая ревью, зарытая модульными тестами и пр составляющими нормальный dod - да, такая задача вполне закончена и может не ждать никакого тестировщика. Дальше при баге на уровне интеграции вы делаете в dev-у фикс. Это позволяет вам не вешать бранчи, не возвращаться к бранчам и пр. И на чамом деле позволяет снизить проблемы в интеграции - ведь у вас ещё несколько разработчиков рядом пишут свои задачки и им надо их тоже вливать в dev и тоже гнать на интеграцию. В целом мероприятия для снижения проблем на интеграции в виде бекмерджей раз в пару дней максимум - это не простая, но обязательная культура.
Это всё абсолютно справедливо для задач на бэкенд, где модульные тесты и код ревью срезают абсолютное большинство багов
Но вот с фронтендом ситуация другая. Фронтенд меняется очень часто, поэтому модульные тесты на него обычно занимают больше времени чем приносят пользы. Мы обычно пишем автотесты на часто переиспользуемые компоненты и там эффект ощутим, но в большинстве ситуаций это лишняя нагрузка
А самая важная часть, ради которой обычно и заводятся динамические окружения это верстка. Автотестами её покрывать нецелесообразно, потому что она часто меняется и чтобы протестить во всех версиях всех браузеров нужны колоссальные усилия
Если заставлять ревьюеров на код ревью проверять верстку во всех браузерах, то затраты вырастут колоссально. Именно поэтому такие баги обычно отлавливаются руками тестировщиков
Именно поэтому в статье пример про желтые кнопки и перекраску интерфейса — динамические окружения приносят больше всего пользы именно в работе с фронтендом
Комментарий удален автором поста
Комментарий удален автором поста
Молча. Если больше одной таски в работе, и вторая не емерженси хотфикс - значит с процессом/пайплайном разработки проблемы. Впрочем если у конторы нет автодеплоя, то там общая квалификация очевидна, и процессы врядли будут кардинально лучше, чем общий технический уровень
А что делать, когда задачу доделал и ждешь результата тестирования от тестировщика? Сидеть и ждать?
Юнт тесты на нее писать вестимо. Для этого стенд не нужен.
Стенды нужны в первую очередь тестированию (юниты к нему тоже относятся), а не разработке, так как оная вполне может локально поднимать в докере компоненты с использованием какой то общей дев базы и тп. А вот тестированию надо, чтобы среда была стейбл + новая фича, а не ввиде месива из фичей. У вас же в статье основной упор на разработку, что не верно.
Я понимаю почему он там - его проще продать варварам, чем тестирование. Но таки в реальности именно тестирование основной заказчик тестовых сред и автодеплоев туда
С юнит тестами не всё так просто:)
На бэкенде мы обычно делаем как вы говорите — всё покрываем тестами и довольно редко используем динамические окружения и тестировщики если тестят методы API, то уже на общем деве
А вот с фронтендом не всё так просто — автотесты имеет смысл писать либо на очень стабильный функционал, либо на какие-то часто переиспользуемые компоненты. Автотесты на верстку в большинстве случаев пустая трата времени
И вот тут и возникает типовой кейс — фичу на фронтенде должны проверить тестировщики и пока они ее проверяют разработчик должен взять следующую задачу или просто сидеть без дела. А у тестировщиков может быть в какие-то моменты очередь на тестирование, так что разработчику сидеть без дела ну просто неприлично
В итоге — в любом случае у разработчика получается как минимум 2 незавершенные задачи, которые надо независимо показывать коллегам. Так что 2 незавершенные задачи "в работе" это абсолютно норм, особенно для фронтендеров
А насчет того, кому проще продать — деньги крутятся у бизнеса и с ним надо говорить на языке бизнеса. У тестировщиков может быть много потребностей, но если на чем-то бизнес теряет деньги, то лучше ему напрямую об этом сказать, что я и сделал в статье:)
"так получается, когда не налажены процессы в разработке"
То есть если процессы налажены, то разработчик сидит и ждет пока протестируют его фичу, а не берет следующую?
Насчет багов: насчет хотфикса согласен, а насчет "если это фикс, то он должен оказаться на интеграционном стенде" не согласен — если на этот интеграционный стенд выкатили еще несколько фичей, то они могут повлиять на тестирование этого фикса, на выходе та же проблема, которую я описывал в статье
"В большом кол-ве проектов правильным является локальный стенд на машине разработчика" - если речь про выделение каждому разработчику по серверу, то я детально описал этот кейс в статье — будут наслаиваться фичи одного разработчика друг на друга.
Но если вы говорите про то, что нормально иметь тестовый сервер прям на компьютере разработчика, то это совсем странно — отключился от интернета / выключил комп - тестировщик не может тестить
А насчет затыкания проблем — так вся статья как раз про то, что люди пытаются менять процессы, не сделав абсолютно гигиенической истории с фича стендами
Ну и последнее — поддержка зависших бранчей не поедает время. Если фича зависла, то ее никто не трогает, она не мешает разработке других фичей и ее не надо отрывать от тестового сервера, тратя на это доп ресурсы. Когда фича станет опять актуальной, то возможно нужно будет потратить доп время на актуализацию, но так происходит в любом случае, если мы откапываем что-то старое
Комментарий удален автором поста
В идеальном мире у разраба в работе в данный момент одна фича. Хотел бы я в такой мир. Но реальность более жестока
На то он и идеальный мир:) но к этому можно и нужно стремиться, хотя бы не в плане незавершенной работы в целом.
Когда одну фичу тестят тестировщики, по другой код смотрит ревьюер, по третьей пришли баги, но вот именно в разработке одна фича
У нас в целом такая схема сохраняется если нет каких-то из ряда вон выходящих событий
Комментарий недоступен
Разворачивать продукты с платной лицензией типа сапа и динамикса под каждую фичу действительно либо не получится, либо слишком дорого, но при классической разработке получается довольно эффективно:)
База данных тоже отдельная на каждый пулл реквест разворачивается?
Развертывание бд под фичу выходит за гигиенический минимум, который нужен прям всем и о котором я пишу в статье, но такое мы тоже делали
можно просто схему под ветку разворачивать в той же БД
Да разные способы есть, интересно как это у автора реализовано
У нас в конторе это уже реализовано, могу подтвердить - очень хорошая штука, особенно в связке с интеграционными тестами, которые можно запускать в конфигурации "Реальный сервис и набор стабов других сервисов"
Вот у нас тоже давно реализовано, но недавно поняли что есть много компаний, для которых это всё ещё не является стандартом