И это прекрасно

обратная?

В смысле этот чат не подходит (

А расскажи, что делаете?

Потому что непонятно в чем толк платного размещения

я считаю, что можно при следующих условиях:
1) внятно описываешь что делать, своими словами, не больше полутора абзацев
2) пишешь сколько бабок
3) ссылка на полную вакансию без preview
4) сообщество в любой момент может сказать «чет много рекламы» и будет мораторий на рекламу

NFT игру )

я считаю, что можно при следующих условиях:
1) внятно описываешь что делать, своими словами, не больше полутора абзацев
2) пишешь сколько бабок
3) ссылка на полную вакансию без preview
4) сообщество в любой момент может сказать «чет много рекламы» и будет мораторий на рекламу

вы чо, криптокотики это же хайп прошлой волны)

Привет, хочу снова посоветоваться с сообществом, в этот раз про CI/CD для микросервиов && Kubernetes. А именно меня интересует устройство тестовых сред.

Пререквизит к вопросу:
Система состоит из микросервисов, весь продакшен задеплоен в один кубернетес-кластер.

Дальше описание проблемы:
В процессе разработки команды хотят как-то тестировать свой код до того, как он попадёт в мастер, откуда он улетит в Canary и дальше в Prod (либо наоборот из мастера в релизный бранч — не суть важно).
При этом чтобы потестировать, сервисы часто нужно задеплоить — из-за зависимостей от других сервисов и от всяких там баз данных. Т.е. можно всё замокать и тестировать локально, но это обычно сложно и к этому нужно долго идти. Естественная реакция на эту задачу — поднять каждой команде по кубернетес-кластеру и пусть туда деплоят и тестируют. Но мне кажется, что это не очень хороший способ, который плохо скейлится — команд со временем становится много, сервисов тоже много, и деплоить полную копию всего продакшена из N сервисов ради теста одного — не звучит как оптимальное решение, плюс мейнтенс кучи кубер-кластеров будет отнимать ресурсы.

В целом у меня в голове такая картинка: есть один тестовый кластер, куда задеплоены все сервисы со всей нужной инфраструктурой (версии допустим аналогичной продакшену). И дальше есть возможность для любого сервиса один из инстансов задеплоить другой версии (например, из бранча) и как-то принудительно пустить трафик через эту “тестовую версию”. Т.е. если ничего не делать, то на запрос ответит продакшен-версия, но если передать какой-нибудь заголовок типа “service_name=test”, то весь запрос обработается тестовым инстансом.

Наверняка есть какой-нибудь способ организовать всё это:
1. Из buzzword-ов я слышал service mesh, но как ни начну туда копать — всё сложно получается.
2. Ещё можно как-то поднимать девелопмент/тестовые версии в Minikube, но всё равно не понятно как через эти версии траффик пускать.
3. Ещё я видел вариант, когда под бранч создаётся короткоживущий кубернетес-кластер, на котором всё тестируется и он тушится — тут возникает масса вопросов от “какие версии сервисов деплоить в этот кластер” до того, что разворачивание кластера с базами под PR может быть долгим и сложным.

Скажите, есть ли у кого-нибудь опыт организации чего-нибудь похожего, или я хочу странного и всё можно организовать как-то иначе?

+

Ищем мидл+ фронта (vue.js + vuex). Свежий проект (ниша — киберспорт-гемблинг), SPA на Vue 2, фронт делали с подрядчиками. Свежая команда: опытный тимлид (бэк), опытный диз, опытный QA.

Условия:
-Полный ремоут
-Оформление через ИП с компенсацией налогов. Вилка — 100к-200к (широко, но как есть 😀)
-Компенсация 50% английского + конфы по специальности
Возможно придется трогать легаси в старых продуктах (jquery), но недолго.

Оч хотим найти ответственного спеца, который умеет коммуницировать и ответственно делать то, на что закоммитился. Подробней здесь: https://www.notion.so/tastydrop/Middle-Frontend-Developer-Vue-js-Vuex-FT-04972d3b15f14edea3cfff744fd6fb9c. Откликнуться можно в лс

ps вопрос к админам — норм? ищу для себя офк, не рекрутер