Вы никогда не сократите Тime Тo Мarket, если будете тестировать все фичи на одном сервере

Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.

Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.

Небольшой Time To Market позволяет бизнесу опережать конкурентов и быстрее получать прибыль от продуктов. Даже Греф еще в 2016 году говорил, что главное для IT-компаний — выводить продукт на рынок быстрее.

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

Когда все разработчики команды тестируют свои задачи на одном сервере, сначала все работает нормально. Фичи затрагивают разные части проекта и не противоречат друг другу.

Однако со временем таски разработчиков наслаиваются и начинают мешать тестированию друг друга — особенно когда у одного разработчика одновременно несколько незавершённых задач в работе. Проблема обостряется, когда часть задач встали на холд, а новые таски с ними пересекаются.

Упрощенный пример: в компании было решено перекрасить сайт в желтый и протестировать нововведение на общем сервере. Редизайн всего сайта — серьезное изменение, поэтому согласование затянулось. Вместо этого была поставлена новая задача: перекрасить в желтый цвет только одну кнопку сайта.

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

Для решения этой ситуации разработчику придется искать часть кода, которая пересекается с его задачей. Затем согласовывать с теми, кто эту фичу делал и тестировал, что её можно удалить из тестового сервера. А затем тратить время на вычищение этого участка кода с тестового сервера.

Получается, что помимо самой задачи разработчику придется разбираться еще и с тем, кто и что делал, какие фичи актуальны, а какие — нет. В результате, драгоценное время разработчиков тратится не на новые фичи, а на бессмысленную суету, и TTM растёт.

Когда на сервере всего несколько конфликтующих изменений, с этим не так сложно справиться. Можно потратить дополнительные ресурсы и разобрать каждый конфликт вручную. Однако рано или поздно накапливается критическое количество конфликтных изменений, которое в итоге ломает весь сервер и полностью останавливает возможность тестирования фичей.

Итог: новые фичи не доставляются до пользователя.

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

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

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

Кто-то решает проблему конфликтов изменений, создавая несколько серверов: по одному на каждого разработчика. Этот вариант кажется более логичным. Разработчики работают независимо друг от друга, а значит не пересекаются друг с другом.

Однако разработчики редко работают одновременно только над одной задачей. Как правило, разработчики по одной задаче пишут код. По другой ждут фидбека от менеджера, по третьей — фидбека от тестировщика по исправленному багу, а по четвёртой — фидбека по код-ревью от коллеги.

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

Динамические окружения — это подход, при котором для тестирования каждой фичи автоматически разворачивается полная копия сервиса, который сейчас доступен пользователям. Но к этой копии применены изменения, касающиеся только одной новой фичи.

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

Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику.

Можно выделить несколько преимуществ динамических окружений:

— Экономия времени. Динамические окружения создаются и удаляются автоматически, поэтому разработчики не тратят время на то, чтобы положить изменения на сервер.

— Изолированные задачи. Динамические окружения предотвращают конфликты изменений — если один разработчик что-то сломал на одном из своих тестовых серверов, это не повлияет на работу других своих задач и задач других разработчиков.

— Доступность в любой момент. Благодаря динамическим окружениям разработчики могут использовать сервер в любой момент. Им не нужно ждать своей очереди для тестирования рабочих фичей.

Внедрить динамические окружения — единоразовая работа. Если в команде нет людей, которые уже раньше это делали, то средние затраты по нашим опросам занимают 4-6 человеко-месяцев в зависимости от квалификации инженеров и сложности проекта.

Мы же можем настроить динамические окружения за 2 недели.