Пусть разработчик реагирует на доступ к стадии с рабочей станции: плохая практика?

У нас есть 3 среды: Dev (локальная для их рабочей станции) -> Staging -> Production

Разработчики React хотят иметь доступ к промежуточным бэкендам, чтобы иметь реальные данные и работать с реальными вариантами использования.

Несмотря на то, что разработчики React утверждают, что это безвредно, поскольку они не могут вносить какие-либо изменения, я чувствую себя неловко, позволяя им использовать staging в качестве собственного тестового бэкенда.

Я имею в виду... конечно, промежуточная среда должна быть изолирована от среды разработки и производства (по крайней мере, теоретически). Но как они могут быть эффективными, если им приходится размещать серверную среду с ручной синхронизацией БД на своей рабочей станции?

Это плохая практика? Как бы вы это сделали?


reactjs development-environment staging
person Kelindil    schedule 03.12.2018    source источник
comment
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что это бизнес-правило/решение.   -  person user2864740    schedule 04.12.2018
comment
Независимо от моего близкого голосования, мои два цента: сохраняйте среды отдельными, чтобы избежать введения искусственных зависимостей, ошибок и (если это когда-либо имеет значение) раскрытия данных.   -  person user2864740    schedule 04.12.2018
comment
Второстепенный вопрос (Как реализовать ..?), выделенный как отдельный вопрос, может быть более подходящим для SO, но для этого потребуется более конкретный контекст. В моей организации, например, у нас есть отдельные экземпляры SQL (и сегментированные сети), включая общий кластер базы данных разработки, для каждой среды. Таким образом, разработчики могут работать с общим набором данных/схемой разработки-интеграции, не затрагивая среды автоматизации-тестирования/тестирования/постановки/производства. Схема и справочные данные продвигаются и синхронизируются по мере необходимости.   -  person user2864740    schedule 04.12.2018

Ответы (1)


arrow_upward
0
arrow_downward

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

Наверняка есть и другие варианты:

  • Создайте третью среду, которая служит серверной частью для разработки внешнего интерфейса, оставив в покое промежуточную и производственную среду. Часто для тестирования выпуска может потребоваться использовать промежуточную среду, поэтому может быть неплохо иметь третью среду, которая всегда содержит последние изменения, над которыми разработчику может понадобиться поработать.
  • Каждый разработчик может предоставить и запустить свою собственную среду, работающую где-то удаленно (aws, gcp и т. д.), возможно, с разными версиями серверных служб.
  • Запускайте все локально (в идеале просто запускайте что-то вроде docker compose) и заполняйте данные.

Между четырьмя вариантами (с использованием промежуточной среды, с использованием новой третьей среды, у каждого разработчика есть собственная удаленная среда и запуск локально) необходимо рассмотреть компромиссы каждого подхода и оптимизировать его для вашего приложения/бизнеса.

Новые удаленные среды, очевидно, требуют денежных затрат и, вероятно, требуют некоторой работы, чтобы начать работу.

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

Использование вашей промежуточной среды, вероятно, требует минимальных усилий, поскольку среда уже существует. Если при этом нет очевидных проблем, вероятно, стоит попробовать и потратить время/ресурсы на другой вариант, если в конечном итоге возникнут проблемы, вызванные его использованием для этой цели.

person TLadd    schedule 04.12.2018