Как стать автором
Обновить
354.88
KTS
Создаем цифровые продукты для бизнеса

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

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров3.5K

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

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

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

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

Почему один рабочий сервер на всю команду — не ок

Новые фичи не соприкасаются и все вместе отправляются в продакшн после тестирования. 
Новые фичи не соприкасаются и все вместе отправляются в продакшн после тестирования. 

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

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

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

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

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

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

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

Проектов на сервере становится так много, что сервер может «сломаться».
Проектов на сервере становится так много, что сервер может «сломаться».

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

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

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

Решение в лоб #1. Очередь на тест

Разработчикам приходится ждать своей очереди, чтобы воспользоваться сервером. 
Разработчикам приходится ждать своей очереди, чтобы воспользоваться сервером. 

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

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

Решение в лоб #2. Не хватает одного сервера — сделаем несколько

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

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

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

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

Как решить проблему по-человечески: динамические окружения

Каждая фича тестируется на отдельном сервере. У каждого разработчика столько серверов — сколько фичей сейчас в работе. 
Каждая фича тестируется на отдельном сервере. У каждого разработчика столько серверов — сколько фичей сейчас в работе. 

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

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

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

Чем динамические окружения хороши

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

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

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

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

А как настроить динамические окружения?

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

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

Будем рады провести консультацию для вас и вашей команды и помочь в настройке динамических окружений поверх Kubernetes. 

Пишите в телеграм: ссылка

Теги:
Хабы:
Всего голосов 35: ↑27 и ↓8+23
Комментарии25

Публикации

Информация

Сайт
kts.tech
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия