Как по нытью разработчиков понять, что вам нужны фича-серверы

Привет, это Максим Павлов из KTS.

Я уже писал о том, как фича-серверы ускоряют Time To Market.

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

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

Пока одни разработчики тестируют — другие простаивают. Работа замедляется.

Как решают проблему фича-серверы

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

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

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

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

Почему так происходит

То, что мы видим на сервере – это комбинация из разных веток, вручную собранных последним разработчиком, который выкатывал свои изменения на тестовый сервер.

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

Как решают проблему фича-серверы

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

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

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

Почему так происходит

Разработчики тестировали все задачи на одном сервере. Сначала это работало, потому что фичей было не так много и они касались разных частей проекта, поэтому не мешали друг другу. Но как только задачи стали наслаиваться, начались проблемы.

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

Тестирование всех фичей блокируется.

Как решают проблему фича-серверы

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

Ситуация: в команду пришел новый разработчик, который первый день (или даже несколько дней) занимался только развертыванием проекта у себя на компьютере и не брал рабочие задачи.

Почему так происходит

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

Как решают проблему фича-серверы

Чтобы ветки разворачивались автоматически, DevOps инженеры «программируют» выполнение всех нужных действий по развертыванию. Не имеет значения — развернуть сервис под отдельную ветку или развернуть его на компьютере разработчика.

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

Можно начать внедрять фича-серверы самостоятельно, а можно написать нам. По нашим опросам, в зависимости от опыта команды настройка фича-серверов может занимать от 4 до 6 месяцев, мы же делаем это за две недели.