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

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

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

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

Что такое фича-серверы (динамические окружения)

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

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

👨‍💼: «Где можно проверить новую фичу?»

👨‍💻: «Пока нигде, тестовый сервер занят»

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

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

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

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

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

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

👨‍💼🧑‍🏫👨‍✈: Решают, что 5 из 10 фич с теста должны поехать в продакшн

👨‍💻: Ругается, что ему опять придется что-то там пересобирать

Чтобы отправить в продакшн только стикеры с зелёными доработками нужно собрать отдельную версию только с этими фичами
Чтобы отправить в продакшн только стикеры с зелёными доработками нужно собрать отдельную версию только с этими фичами

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

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

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

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

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

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

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

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

👨‍💻: «Тестовый сервер разломался, потому что накопилось много старых фичей»

Если фичи слишком наслоились друг на друга, сервер может сломаться
Если фичи слишком наслоились друг на друга, сервер может сломаться

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

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

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

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

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

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

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

👨‍💻: «Сегодня я занимался только разворачиванием проекта»

<p>3й рабочий день новый сотрудник разворачивает контейнеры веб сервиса у себя на компьютере и не может взять рабочие задачи</p>

3й рабочий день новый сотрудник разворачивает контейнеры веб сервиса у себя на компьютере и не может взять рабочие задачи

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

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

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

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

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

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

С чего же начать?

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

Пишите мне в телеграм.

2525
15 комментариев

Интересно, как вы делаете раворачивание фича-бекенд-серверов? В двух словах, если можно. С фронтом, кажется, нет проблем, есть кучу сервисов типа нетлифай или AWS, где это делается "связкой" с репозиторием, или можно написать скрипт, который будет класть сборку в S3 – дешево и сердито)

Ответить

В следующей статье расскажу чуть подробнее, подпишитесь :)

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

2
Ответить

ну или новые разработчики

Ответить

Шоколад не виноват:)

А "нытьё", о котором я рассказал в статье не показатель того что программисты плохие, а что тупо нет одного инструмента

1
Ответить

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

Асинхронно прогоняются все интеграционные, performance и юнит тесты для всех комбинаций архитектур и платформ, которыми пользуются наши клиенты - Windows, macOS, Linux/AMD64, ARM, IBM... Автоматически детектируются коммиты, которые сломали что-либо. Включая perf.

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

Ответить

В предыдущей статье автор утверждал, что у них там очень много клиентов, которые о никаких CI/CD слыхом не слыхивали, и деплоят руками

Ответить

Термином "сервер" я сознательно упростил менее понятное "окружение". Технически это всё развертывается в кубернетесе и билд пропускается через стандартный процесс CI/CD, где запускаются все автотесты

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

Ответить