К какой среде API следует подключать интерфейсных разработчиков для локальной разработки? - PullRequest
0 голосов
/ 03 июля 2019

У нас есть внешняя и внутренняя команды, каждая из которых использует свою собственную технологию.

Внешней команде требуется API для кодирования.

Текущая настройка:

  • Внешняя команда подключается к API "Dev"
  • Внутренняя команда выпускает новый код в ту же среду "Dev"

Проблемы

  • Если бэкэнд-команде необходимо запустить сценарий, это влияет на среду «Dev» и, следовательно, на всех фронт-разработчиков
  • Фронт-группа подключается к общей инфраструктуре

Решения

  1. API должен быть Docker-ised.Внешние разработчики подключаются к локальному Docker API.Выглядит как лучшее решение, но требует определенных усилий и обучения от обеих команд
  2. Создайте вторичный Dev API, который использует фальшивые / фиктивные данные.Таким образом, доступность данных никогда не будет проблемой.Это может быть быстрый выигрыш, но есть недостаток в том, что он не интегрируется с «реальными» данными.Но может быть «запасной вариант».
  3. Наличие другой среды.Кажется, просто добавить еще один уровень развертывания / координации с минимальным преимуществом

Кто-нибудь может высказать соображения по поводу выше, или лучшее решение?

1 Ответ

0 голосов
/ 04 июля 2019

У вас есть два требования здесь:

  • Разработчики из обеих команд должны попробовать что-то, но хотели бы свести к минимуму влияние на других членов команды / команд
  • Вы хотите часто интегрировать переднюю и заднюю части, чтобы обеспечить совместимость кода

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

Например, разработчик может:

  • Указать dev API v1.5
  • Укажите макет версии API
  • Укажите набор тестовых данных v2.0
  • Нажмите, чтобы создать среду и запустить код
  • Запуск автоматических регрессионных тестов для подтверждения их последних работ по изменению кода

Потребуется некоторое время, чтобы настроить подобную сборку среды на основе сценариев, но она может окупиться.

Я даже видел, как разработчики запускали свою собственную непрерывную интеграцию локально, чтобы они запускали сборки среды и автоматизировали тестирование при кодировании.

Одну и ту же сборочную среду можно использовать в различных средах разработки и тестирования (сервер разработки, тестовый сервер, UAT, производство и т. Д.).

...