Size: a a a

2021 March 12

N

Nikita in ctodailychat
Oleg Batashov
Всем привет!
По словам Антона задумались про дистрибуцию и через mac app store, так что я снова к вам с вопросом:
- кто нибудь знает, можно ли публиковать DMG с другими ценами на лицензию, если ты опубликовал приложение в MAS - или атата сразу прилетит и выкинут из стора?
- и можно ли включать в DMG функционал, запрещённый стором - например автоапдейты
Если есть опыт, поделитесь пожалуйста
Автоапдейт можно включать
источник

OB

Oleg Batashov in ctodailychat
Спасибо, Никита!
Получается что у стора обязательно должны быть условия выгоднее для юзеров.
И наоборот чтобы из DMG было дешевле, нельзя - потому что тогда не выгодно идти в стор, правильно понял?
При этом как оформляется покупка в dmg не важно - например можно просто ссылку на сайт вместо in-app purchase?
источник

N

Nikita in ctodailychat
Oleg Batashov
Спасибо, Никита!
Получается что у стора обязательно должны быть условия выгоднее для юзеров.
И наоборот чтобы из DMG было дешевле, нельзя - потому что тогда не выгодно идти в стор, правильно понял?
При этом как оформляется покупка в dmg не важно - например можно просто ссылку на сайт вместо in-app purchase?
да
источник

ЖЖ

Жираф Жирафович... in ctodailychat
DMG вы вообще можете распространять как хотите. Макось хоть и движется к огораживанию, но пока ещё не такая закрытая как iOS
источник

AR

Anton Revyako in ctodailychat
Oleg Batashov
Всем привет!
По словам Антона задумались про дистрибуцию и через mac app store, так что я снова к вам с вопросом:
- кто нибудь знает, можно ли публиковать DMG с другими ценами на лицензию, если ты опубликовал приложение в MAS - или атата сразу прилетит и выкинут из стора?
- и можно ли включать в DMG функционал, запрещённый стором - например автоапдейты
Если есть опыт, поделитесь пожалуйста
everything's better with bluetooth Anton :)
источник

DT

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

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

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

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

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

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

ИМ

Илья Макеев... in ctodailychat
А есть вариант сделать приложение менее зависимым в тестировании к базе, чтобы деплой занимал адекватное время?
источник

O

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

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

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

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

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

Скажите, есть ли у кого-нибудь опыт организации чего-нибудь похожего, или я хочу странного и всё можно организовать как-то иначе?
Никакого магического решения я не знаю. Все обычно упирается в бюджет и зависимость самих приложений. Единственное что, я крайне не рекомендую тестовую среду как-либо связывать с любой другой и тем более продом, рано или поздно стрельнет в формате "ой, а я думал там трафик завернут".
источник

O

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

O

Onlinehead in ctodailychat
А на счет скейлится- кубик то хорошо скейлится, гораздо лучше бюджета на инфраструктуру:)
источник

DT

Dmitry Tsybin in ctodailychat
Илья Макеев
А есть вариант сделать приложение менее зависимым в тестировании к базе, чтобы деплой занимал адекватное время?
Когда приложение — это middleware между rich ui и БД, то обычно это сложно. И допустим с базой даже можно порешать (например, запускать локальный инстанс), но там же и другие микросервисы в зависимостях есть. У Dropbox и Airbnb есть статейки, что для таких задач у них супер-дупер-мок-сервис, который в продакшене слушает трафик и умеет потом отдавать из mock-сервера всё что ты хочешь +- автоматически, но они для этого много сделали и достаточно долго туда шли. А руками всё замокать — это мягко говоря непросто и тоже достаточно долгий путь.
источник

ИМ

Илья Макеев... in ctodailychat
под приложением я имел в виду все микросервисы со всеми базами
источник

ИМ

Илья Макеев... in ctodailychat
wiremock?
источник

DT

Dmitry Tsybin in ctodailychat
Onlinehead
А на счет скейлится- кубик то хорошо скейлится, гораздо лучше бюджета на инфраструктуру:)
под словом “скейлится” я имел ввиду не количество нод Кубика, а бюджет, мейнтейнс самих кластеров и приложений в них (что если приложение одной команды плохо работает в окружении другой — кто это будет чинить? на масштабе это прямо много.
источник

ИМ

Илья Макеев... in ctodailychat
походу проблемы из разряда "делай норм будет норм" =)
источник

DT

Dmitry Tsybin in ctodailychat
Onlinehead
Обычно подобное решается тяжелой автоматизацией с авторазверткой зависимых сервисов в каком-то виде, наливкой дампов баз и т.д. Простого решения тут нет, придется разворачивать все, что требуется для тестирования. Потом можно пооптимизировать чего-нить, если нужно, базы там реюзать и т.п.
Я когда-то работал в Я.Картах и там на уровне приложений можно было всё это сделать — подменить URL любого сервиса для любого другого. На тестовой среде с запросами вместе летала мапа “Service:URL” и это хорошо работало. Но там это решалось тем, что все микросервисы были написаны на одном стеке и поддержка была зашита в http-server
источник

DT

Dmitry Tsybin in ctodailychat
Илья Макеев
походу проблемы из разряда "делай норм будет норм" =)
нет, проблемы из разряда “на большом маштабе редкие события становятся не такими уж и редкими”
источник

ИМ

Илья Макеев... in ctodailychat
более менее простой и бескровный способ - действительно мокать сервисы других команд для тестов автоматических, а для всякого регресса - держать несколько инстансов каждого сервиса, чтобы команды могли к ним подключаться и не мешать друг другу
источник

MS

Max Syabro in ctodailychat
пацаны
источник

MS

Max Syabro in ctodailychat
hcaptcha ебанулась
источник