Комментарии 25
Идея хорошая.
Но а где вариант "разработчик тестирует фичу локально"? Если уж говорим про тестирование разработчиками.
Объяснение для технарей: работают динамические окружения так: разработчик пушит отдельную ветку на гите, затем по отдельной ссылке получает независимую копию проекта, которую можно показать менеджеру и тестировщику.
разработчик по этой ссылке получает образ для скачивания или развернутый на сервере?
По ссылке будет развернутый на сервере проект
А если проект это десятки ссылок и зависимостей?
У меня в проекте свыше 100 компонентов, и пишутся они разными командами, плюс базы данных, состояние которых должно быть консистентным релизной ветке, и размер баз достаточно значительный.
Всем решением свое место. Тестирование на одном сервере вполне может быть рабочим решением.
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
Но а где вариант "разработчик тестирует фичу локально"? Если уж говорим про тестирование разработчиками.
Тогда не получится прорекламировать что " Мы же можем настроить динамические окружения за 2 недели."
вы всерьез рассматриваете вариант, в котором тестировщики и менеджеры смотрят фичу на компе разработчика?:)
Это хорошая возможность для какого-нибудь пет проекта, но для продакшна это ж моветон
Тестировщики смотрят фичу на своем компе, менеджеры могут смотреть фичу на компе разработчика, если им это вдруг надо.
Но вообще для демонстрации фичи для менеджеров, организовывается специальный демо митинг, где показывают и рассказывают. Какой конкретно при этом инстанс используется - зависит от выступающего и проекта.
Чтобы менеджер сам лично ковырял фичу - какого уровня менеджер имеется ввиду тогда?
Ну и обычно есть тестовый сервер. Их не обязательно должно быть десять или сто.
Частая ситуация - QA, UAT, pre-prod, prod.
Четыре статических енва.
Может мы просто про разное говорим
Чтобы тестировщик смотрел фичу на своём компе, он же не должен разворачивать на своем компе полную версию сервиса?
А насчет тестового сервера - хоть 2, хоть 4 проблемы те же самые, что описаны в статье:
Фичи влияют друг на друга
Если какие-то фичи откладываются или зависают, то их надо руками отрывать с тестового стенда и не забыть еще это сделать до того как всё разломается
У нас это называется:
"фича-инфраструктура" - временное окружение со своими временными репозиторями пакетов, бд и т.п., и "фича-стенд" - стенд для тестировщика/аналитика, развернутых на базе "ФИ". на нём происходит функциональная приема и тестирование, устранение выявленных багов. Когда всё проверено и готово - тогда код попадает в мастер затронутых пакетов.
С базами данных как порешали?
Ага, и другими сервисами, в (микро)сервисной архитектуре
Все зависит от конкретного окружения, например: можно использовать операторы в kubernetes и с помощью init-контейнеров заливать данные; в яндекс облаке есть интересный инструмент data transfer, с ним и питоном в обнимку не сложно организовать процесс изготовления обезличенных данных из продовой/препродовой среды (о нем писали в курсе про динамические среды - https://cloud.yandex.ru/training/devops)
Так я про решение этой задачи в вашем конкретном решении по "отдавать версию под каждую фичу" из статьи спрашиваю, зачем мне ссылки на курсы. "Мы оставили это за скобками и БД решением не покрыты" - простая и понятная фраза, хоть и не объясняет как же каждая отдельная фича самостоятельно может существовать, если в реализации фичи задействованы БД.
В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Это не сайт с объявлениями, а технический - если пишите про динамические тестовые стенды, то где оно?
Блин, а ведь кто-то прочитает и подумает ...
Давайте отделять мух от котлет. Чтобы тестить фичи независимо, надо иметь ТРИ вещи.
фича-бренчи (ну иначе а как вы хотите собрать приложение с этой фичей) и процесс работы в репозитории под эту идеологию
окружение под фичу/человека, или метод его создания на лету
деплой фичи на окружение
Все просто "А" "и" "Б". Как в считалочке детской. Два объекта и связь между ними.
Работа в репозитории является первичной. Ну если вы не можете собрать приложение в варианте "стабильная версия" + "желтый фон" - в этом моменте можно заканчивать. Почему автор статьи начал сразу с конца - не ясно. Наверное потому что это типа очень легко и все умеют :) Либо потому что на эту часть консалтинг не распространяется. Но на практике это так не всегда. Точнее наплодить мильон фич легко, вот собрать из них к сроку работающий продукт ...
Второй момент - это выделение окружения для сборки. Понятно, задача зависит напрямую от архитектуры. Для монолита или близких к ним - один подход, для микросервисов - второй. Плюс надо понимать, что это все в общем, а дьявол в деталях. Но я так понимаю, эти детали тоже считаются микроскопическими и ими заниматься не интересно. Либо "мы умеет только в кубер", а кто не с нами - те лузеры и неудачники.
Третье - ура. У нас есть команда, которая генерит фичи в бренчах, есть среды - можно деплоить. Так это как раз самое неинтересное. Банальный Jenkins творит "чудеса" которые были доступны миру еще Х десятилетий назад (да и под капотом там часто "технологии" постарше многих комментаторов). Зашел, выбрал версию, тыкнул "бубочку", глотнул чайку и вперед.
А в реальном мире так все может не работать, и не работает, так как есть два пряпятствия:
merge, так как фичи могут задевать одни и те же сервисы, и тест фич по отдельности без теста merge не лучшая идея
зависимость между сервисами
Понятно, что тут тоже статья это опускает, да и зачем :)
-------------
Ну а задача как поднять много сред - тоже мне бином ньютона. Банально локально поднял нужный контейнер "А*" локально, настроенный на стабильную среду и дело в шляпе. Бесплатно и как "два пальца". Понятно способ не единственный, но ... камон ... тут вообще и проблемы то нет
Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Много где чего-то нет. Это нормально. Но ... ну блин, конвееров CI/CD выше крыши. Технически это не проблема. Проблема не получить оптимизацию в стиле "doing shit faster"
А это как раз работа в репозитории в первую очередь. Если у вас хаос там - смысл ускорять его перенос по средам?
Да и статья - ну такое. По большому счету это неинтересно. В худшем случае закрывается Devops за 4-5 килобаксов в месяц
Это работает ровно до того момента, когда поднятие еще одной копии инфраструктуры не выливается с большие требования по железу. Еще у вас может быть прод, засыпанный микросервисной крошкой, для соедининения которой воедино нужно привлечь половину обслуживающего ее персонала.
Вы никогда не сократите Тime Тo Мarket, если будете тестировать все фичи на одном сервере