Фон:
Шаг 1 -> У нас есть окно, которое запускает модульные и функциональные тесты приложения, запустив его в тестовом режиме с определенным конфигурация.
Шаг 2 -> После успешного выполнения шага 1 мы запускаем интеграционные тесты приложения, запустив его в тестовом режиме с другим набором конфигурации в другом окне.
Шаг 3 -> После успешного выполнения шага 2 мы запускаем тесты производительности приложения, запустив его в производственном режиме в окне тестирования производительности.
Шаг 4 -> После успешного выполнения шага 3 сборка считается стабильной, и поле UAT обновляется с использованием этой базы кода, и приложение запускается в производственном режиме для проверки и обратной связи с клиентами.
Шаг 5 -> С GO от клиента производственная коробка обновляется с помощью базы кода.
Теперь, из вышеперечисленных шагов мы видим, что на шагах 1 и 2, когда приложение работает в тестовом режиме, оно имеет другую конфигурацию. То же самое и с шагами 3,4 и 5.
Какова рекомендуемая практика в таких ситуациях? У нас были файлы конфигурации YAML, но лично я чувствовал, что поддерживать множество файлов конфигурации не имеет смысла. Итак, я изменил практику
«Файл конфигурации для каждой среды»
на
«Файл конфигурации для каждого режима рельсов, перенос переменных в среду Linux» .
Я на правильном пути? Не мое действие, упростить вещи?
Каковы плюсы и минусы этих двух подходов?