Да, имеем в виду не полную миграцию с помощью ИИ, а изменение рутинных правок, что ускорило ручной перенос. В статье при этом указали причины, почему нельзя скормить весь код и сделать переход. Cypress используем, так как это общепринятый инструмент, но в настоящее время все больше и больше переходим на Playwright.
добрый день! учесть все сразу в одном прогоне нереально, потому что там могут быть как условный 0, так и 99..9 Но периодическое попадание в разные места вполне возможно, учитывая то, что мы тестируем UI, и динамические данные скорее имитируют реального пользователя, который с некоторой вероятностью может сделать необычное действие
Если рассматривать отказ от Expo в уже существующем проекте, то это будет трудный процесс, так как придётся пересматривать зависимости, искать что-то подходящее и обновлять код.
Если отказываться именно от инфраструктуры EAS, то здесь проблем больших не будет, если есть знание, как собираются приложения для android/ios, как публикуются приложения в сторы. EAS позволяет не заботиться о том как собирается приложение, как оно публикуется или обновляется, это всё настраивается один раз, а дальше делается по нажатию кнопок) Без EAS просто придётся делать всё вручную
не мы — как говорится в статье, технологию разработали в SoundCloud :)
на API Gateway BFF действительно похож — в некоторых источниках его называют вариацией этого паттерна. главное различие — BFF, как правило, ориентирован на один тип клиента. в результате такая архитектура оказывается проще, а модуль — легче
спасибо за вопросы. для МП у нас выставлено REST API, работаем по HTTP. Событий для мобильного клиента, они работают с нами как с синхронным API в виде запрос-ответ.
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/
Неискушённым читателям можем ответить, что Kubernetes — оркестратор микросервисов, который призван автоматизировать поддержку пула микросервисов в рабочем состоянии :) Он обеспечивает их доступность, масштабируемость, балансировку нагрузки и т.д… А бизнес-логику он не хранит — для этого и нужны решения, про которые идёт речь в статье. Они используются непосредственно в исходном коде, чтобы упростить контроль бизнес-логики, отвечающей за распределение вызовов по микросервисам, т.е. по отдельным составным частям бизнес-процессов.
измерить очень легко – есть прямые затраты на создание и настройку одного микросервиса. с шаблоном это не занимает больше 1-2 часов от первых шагов до деплоя (пока без бизнес-логики)
сложнее измерить косвенные затраты, связанные с качеством, оно сильно зависит от самой команды и разработчиков в ней. если команда не ровная по навыкам, шаблон помогает выровнять картину, плюс компания быстрее получает результат от новичков.
создание новых микросервисов, переработки и обновления старых — разные истории, и для обновления шаблоны не подойдут.
что касается второй части вашего комментария, то у нас таких проблем не возникает, потому что шаблон используется для создания сервисов, а не подключается как библиотека
фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами
Да, имеем в виду не полную миграцию с помощью ИИ, а изменение рутинных правок, что ускорило ручной перенос. В статье при этом указали причины, почему нельзя скормить весь код и сделать переход.
Cypress используем, так как это общепринятый инструмент, но в настоящее время все больше и больше переходим на Playwright.
добрый день! учесть все сразу в одном прогоне нереально, потому что там могут быть как условный 0, так и 99..9
Но периодическое попадание в разные места вполне возможно, учитывая то, что мы тестируем UI, и динамические данные скорее имитируют реального пользователя, который с некоторой вероятностью может сделать необычное действие
Если рассматривать отказ от Expo в уже существующем проекте, то это будет трудный процесс, так как придётся пересматривать зависимости, искать что-то подходящее и обновлять код.
Если отказываться именно от инфраструктуры EAS, то здесь проблем больших не будет, если есть знание, как собираются приложения для android/ios, как публикуются приложения в сторы. EAS позволяет не заботиться о том как собирается приложение, как оно публикуется или обновляется, это всё настраивается один раз, а дальше делается по нажатию кнопок) Без EAS просто придётся делать всё вручную
в некотором смысле, действительно сами — IDE-плагин и другие инструменты, которые мы упоминаем в тексте, сильно помогают автоматизировать процесс.
Мы не совсем свободны в выборе технологий, ориентируемся на стек заказчика. В частности, поэтому и Rabbit здесь используем
Также у нас ответы не просто клиент->RMQ->клиент, есть еще доп. рест вызовы, бизнес логика, маппинги всякие, БД
можно взглянуть и с другой стороны — BFF упрощает жизнь фронтендерам и помогает им отвязаться от многих процессов на бэкенде
не мы — как говорится в статье, технологию разработали в SoundCloud :)
на API Gateway BFF действительно похож — в некоторых источниках его называют вариацией этого паттерна. главное различие — BFF, как правило, ориентирован на один тип клиента. в результате такая архитектура оказывается проще, а модуль — легче
спасибо за вопросы. для МП у нас выставлено REST API, работаем по HTTP. Событий для мобильного клиента, они работают с нами как с синхронным API в виде запрос-ответ.
вот пока ссылка на наш радар с краткими описаниями всех технологий
это тянет на энциклопедию, мы подумаем, как продолжить эту тему
у нас было несколько постов на эту тему:
про Azure DevOps в целом — https://habr.com/ru/post/547906/
про шаблон проекта — https://habr.com/ru/post/552692/
инструменты проектной аналитики — https://habr.com/ru/post/553528/
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/
спасибо за комментарий, об этом мы подробно расскажем в следующем посте.
Неискушённым читателям можем ответить, что Kubernetes — оркестратор микросервисов, который призван автоматизировать поддержку пула микросервисов в рабочем состоянии :) Он обеспечивает их доступность, масштабируемость, балансировку нагрузки и т.д… А бизнес-логику он не хранит — для этого и нужны решения, про которые идёт речь в статье. Они используются непосредственно в исходном коде, чтобы упростить контроль бизнес-логики, отвечающей за распределение вызовов по микросервисам, т.е. по отдельным составным частям бизнес-процессов.
да, тема интересная и богатая, постараемся в будущем вернуться к ней, погрузиться в детали.
измерить очень легко – есть прямые затраты на создание и настройку одного микросервиса. с шаблоном это не занимает больше 1-2 часов от первых шагов до деплоя (пока без бизнес-логики)
сложнее измерить косвенные затраты, связанные с качеством, оно сильно зависит от самой команды и разработчиков в ней. если команда не ровная по навыкам, шаблон помогает выровнять картину, плюс компания быстрее получает результат от новичков.
создание новых микросервисов, переработки и обновления старых — разные истории, и для обновления шаблоны не подойдут.
что касается второй части вашего комментария, то у нас таких проблем не возникает, потому что шаблон используется для создания сервисов, а не подключается как библиотека
вот ссылки, которыми пользовался автор шаблона:
1) https://docs.microsoft.com/en-us/visualstudio/extensibility/how-to-use-wizards-with-project-templates?view=vs-2019 — пример от MS
2) https://github.com/dogtail9/ProjectTemplateTutorial — готовый пример с кучей полезного кода
3) https://stackoverflow.com/questions/60294380/is-there-a-way-to-add-conditions-in-vstemplates-or-a-way-to-generate-output-pro — по сути создаем Solution из разных шаблонов
спасибо за наводку на cookiecutter — изучим
мы используем стандартные функции Visual Studio для создания шаблонов с помощью текстовых шаблонов T4. распространение через маркетплейс утилит для Visual Studio — создаем VSIX-расширение, устанавливаем шаблон прямо в VS. у нас приватный репозиторий, при желании можно загрузить прямо в маркетплейс Microsoft — https://docs.microsoft.com/en-us/visualstudio/extensibility/walkthrough-publishing-a-visual-studio-extension?view=vs-2019
мы смотрели рынок, но в подробности выбора углубляться не будем, чтобы не было холиваров.
фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами