Всем добрый вечер :)

Немного отредактировал вопрос и подвинул вниз, народ стягивается к вечеру.

У кого есть опыт организации одновременной работы с несколькими версиями стороннего API?

Контекст - у Azure есть API для виртуальных десктопов версий v1 и v2 без обратной совместимости.

Сценарии использования - всеми новыми десктопами рулить через v2, а созданными через v1 - через v1
При этом 90% полей и юз кейсов будут те же, только разные апи - новое лучше интегрировано в  Azure, его RBAC и UI

Думал о branch by abstraction из trunk-based, но он больше о переходе с X на Y по описанию

Наверняка есть конкретные паттерны, практики или идеи на этот счёт
Изобретать велосипед очень не хочется

Спасибо!

Спасибо, наверно я плохо сформулировал вопрос
Ansible playbooks - это ответ на вопрос чем автоматизировать какие-то сценарии развертывания?

Добавляю контекст - они уже автоматизированы через v1 API + PowerShell скрипты

Ручка нашего API ходит в API Azure + используется PowerShell для части развертывания где идёт работа с on-premise active directory

BFF - как я понял задуман как разные наборы ручек API для разных клиентов вроде веб/мобилка- iOS/Android
У нас клиент один, это веб админка

Вопрос в том, как добавить параллельно поддержку ещё одной версии Azure API
То есть большая часть кода развертки одинакова, отличия будут в тех частях где ходим в апи

И какая-то диспетчеризиция - клиент удаляет старый десктоп в админке (создан через V1) - удаляем через V1
Создаёт новый десктоп и редактирует/удаляет - через V2

Это напоминает какую-то схему или проблему с well known решением?
Понимаю что пули нет, но ищу куда подглядеть :)

Спасибо, наверно я плохо сформулировал вопрос
Ansible playbooks - это ответ на вопрос чем автоматизировать какие-то сценарии развертывания?

Добавляю контекст - они уже автоматизированы через v1 API + PowerShell скрипты

Ручка нашего API ходит в API Azure + используется PowerShell для части развертывания где идёт работа с on-premise active directory

BFF - как я понял задуман как разные наборы ручек API для разных клиентов вроде веб/мобилка- iOS/Android
У нас клиент один, это веб админка

Вопрос в том, как добавить параллельно поддержку ещё одной версии Azure API
То есть большая часть кода развертки одинакова, отличия будут в тех частях где ходим в апи

И какая-то диспетчеризиция - клиент удаляет старый десктоп в админке (создан через V1) - удаляем через V1
Создаёт новый десктоп и редактирует/удаляет - через V2

Это напоминает какую-то схему или проблему с well known решением?
Понимаю что пули нет, но ищу куда подглядеть :)

@SergeAx С точки зрения клиента, рулить - использовать нашу админку для управлениями своими десктопами в облаке Azure
По юз кейсам все одинаково, разница в том, что созданные после релиза поддержки V2 десктопы будет видно и в админке Azure
Что создано через V1 - увы нет, только через API видно (собственно киллер фича, не все клиенты могут в API/powershell скрипты чтобы себе что-то развернуть)
Microsoft выкатили V2 и клиентам стало проще, нам - надо его поддерживать тоже
С точки зрения разработки, управлять - запускать код, создавать десктопы в Azure API, настраивать on-premise active directory, смесь дотнета и скриптов на powershell

Спасибо, наверно я плохо сформулировал вопрос
Ansible playbooks - это ответ на вопрос чем автоматизировать какие-то сценарии развертывания?

Добавляю контекст - они уже автоматизированы через v1 API + PowerShell скрипты

Ручка нашего API ходит в API Azure + используется PowerShell для части развертывания где идёт работа с on-premise active directory

BFF - как я понял задуман как разные наборы ручек API для разных клиентов вроде веб/мобилка- iOS/Android
У нас клиент один, это веб админка

Вопрос в том, как добавить параллельно поддержку ещё одной версии Azure API
То есть большая часть кода развертки одинакова, отличия будут в тех частях где ходим в апи

И какая-то диспетчеризиция - клиент удаляет старый десктоп в админке (создан через V1) - удаляем через V1
Создаёт новый десктоп и редактирует/удаляет - через V2

Это напоминает какую-то схему или проблему с well known решением?
Понимаю что пули нет, но ищу куда подглядеть :)

BFF -> скрывает реализацию от клиентского приложения. Пусть он думает о том, какое API использовать

Спасибо Ярослав, про mashup почитаю
А чем это отличается от просто одного API, у которого внутри ручки решается в чье стороннее API дальше идти?