Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.Небольшой Time To Market позволяет бизнесу опережать конкурентов и быстрее получать прибыль от продуктов. Даже Греф еще в 2016 году говорил, что главное для IT-компаний — выводить продукт на рынок быстрее. Чтобы решить эту проблему компании пытаются оптимизировать процессы — чаще запускают эксперименты, создают кросс-функциональные команды на замену отдельным департаментам разработки и дизайна. Однако они упускают из вида, что время до выхода продукта на рынок можно сократить, если перестать тестировать задачи на одном сервере. Подробнее о том, почему так происходит, расскажу ниже.Почему один рабочий сервер на всю команду — не окНовые фичи не соприкасаются и все вместе отправляются в продакшн после тестирования.Когда все разработчики команды тестируют свои задачи на одном сервере, сначала все работает нормально. Фичи затрагивают разные части проекта и не противоречат друг другу.Фичей становится больше, они начинают наслаиваться друг на друга. Прежде чем показать свою доработку менеджерам и тестировщикам, нужно расчистить место от мешающих фичей.Однако со временем таски разработчиков наслаиваются и начинают мешать тестированию друг друга — особенно когда у одного разработчика одновременно несколько незавершённых задач в работе. Проблема обостряется, когда часть задач встали на холд, а новые таски с ними пересекаются. Упрощенный пример: в компании было решено перекрасить сайт в желтый и протестировать нововведение на общем сервере. Редизайн всего сайта — серьезное изменение, поэтому согласование затянулось. Вместо этого была поставлена новая задача: перекрасить в желтый цвет только одну кнопку сайта.Разработчик, ответственный за эту задачу, столкнется с проблемой — на общем сервере весь сайт желтый, из-за чего тестирование новой желтой кнопки невозможно. Для решения этой ситуации разработчику придется искать часть кода, которая пересекается с его задачей. Затем согласовывать с теми, кто эту фичу делал и тестировал, что её можно удалить из тестового сервера. А затем тратить время на вычищение этого участка кода с тестового сервера. Получается, что помимо самой задачи разработчику придется разбираться еще и с тем, кто и что делал, какие фичи актуальны, а какие — нет. В результате, драгоценное время разработчиков тратится не на новые фичи, а на бессмысленную суету, и TTM растёт.Проектов на сервере становится так много, что сервер может «сломаться».Когда на сервере всего несколько конфликтующих изменений, с этим не так сложно справиться. Можно потратить дополнительные ресурсы и разобрать каждый конфликт вручную. Однако рано или поздно накапливается критическое количество конфликтных изменений, которое в итоге ломает весь сервер и полностью останавливает возможность тестирования фичей. Итог: новые фичи не доставляются до пользователя. У многих возникает соблазн решить эту проблему одним из двух простых способов. Подробнее о них ниже, но, спойлер, решить проблему «в лоб» не получится.Решение в лоб #1. Очередь на тестРазработчикам приходится ждать своей очереди, чтобы воспользоваться сервером.Одно из логичных решений проблемы — заставить разработчиков пользоваться сервером по-очереди. Так их задачи не будут взаимодействовать, а значит и не будут конфликтовать. В этом случае создается бутылочное горлышко, которое тормозит работу. Помимо ожидания своей очереди для тестирования фичи, сотрудники теряют время на обсуждение очередности работы с сервером. В результате процесс введения изменений затягивается.Решение в лоб #2. Не хватает одного сервера — сделаем несколькоУ каждого разработчика есть собственный сервер под свои задачи, но несколько фичей одного сотрудника наслаиваются друг на друга.Кто-то решает проблему конфликтов изменений, создавая несколько серверов: по одному на каждого разработчика. Этот вариант кажется более логичным. Разработчики работают независимо друг от друга, а значит не пересекаются друг с другом.Однако разработчики редко работают одновременно только над одной задачей. Как правило, разработчики по одной задаче пишут код. По другой ждут фидбека от менеджера, по третьей — фидбека от тестировщика по исправленному багу, а по четвёртой — фидбека по код-ревью от коллеги. В этом случае разработчикам приходится либо постоянно исправлять конфликты изменений, либо перезаливать ту задачу, которую первее нужно показать менеджеру.Как решить проблему по-человечески: динамические окруженияКаждая фича тестируется на отдельном сервере. У каждого разработчика столько серверов, сколько фичей сейчас в работе.Динамические окружения — это подход, при котором для тестирования каждой фичи автоматически разворачивается полная копия сервиса, который сейчас доступен пользователям. Но к этой копии применены изменения, касающиеся только одной новой фичи. Простыми словами: суть динамических окружений в том, чтобы выдавать каждому разработчику столько серверов, сколько фичей у него находится в работе. Каждую фичу можно показать менеджеру и тестировщику на отдельном сервере. Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику. Чем динамические окружения хорошиМожно выделить несколько преимуществ динамических окружений:— Экономия времени. Динамические окружения создаются и удаляются автоматически, поэтому разработчики не тратят время на то, чтобы положить изменения на сервер.— Изолированные задачи. Динамические окружения предотвращают конфликты изменений — если один разработчик что-то сломал на одном из своих тестовых серверов, это не повлияет на работу других своих задач и задач других разработчиков. — Доступность в любой момент. Благодаря динамическим окружениям разработчики могут использовать сервер в любой момент. Им не нужно ждать своей очереди для тестирования рабочих фичей.А как настроить динамические окружения?Внедрить динамические окружения — единоразовая работа. Если в команде нет людей, которые уже раньше это делали, то средние затраты по нашим опросам занимают 4-6 человеко-месяцев в зависимости от квалификации инженеров и сложности проекта. Мы же можем настроить динамические окружения за 2 недели. Проконсультируем и быстро настроим динамические окружений. Пишите в телеграм: ссылка
Картинки — огонь!)
Спасибо! Очень старались:)
Мало того, что статья классная, так и картинки прикольные, за это точно лайк
Спасибо!!!
Актуальная проблема крутое решение
Спасибо!
У вас прям отдельные сервера? Сейчас же с приходом Kubernetes + CI/CD эта проблема решается достаточно легко, даже сам тестировщик сможет развернуть, а потом потушить окружение из нужной ему ветки. Контейнеры в 21 веке маст хев в любой разработке