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

Question

Некоторое время назад я создал скрипт с использованием Python, скрипт выполнит некоторые действия в экземпляре на основе файла конфигурации.

В этом я создал 2 файла конфигурации.

Config.py

instance= <Production url> 
Value1= A 
Value2= B 
... 

TestConfig.py

instance= <Development url> 
Value1= C 
Value2= D 
... 

Так что, когда я хочу, сценарий для выполнения задач в случае разработки, чтобы сделать тесты, я просто импортировать TestConfig.py вместо Config.py.

Main.py

# from Config import * 
from TestConfig import * 

Проблема возникает, когда я обновить скрипт с помощью Git. Если я хочу запустить скрипт в разработке, я должен вручную изменить файл, это означает, что у меня будут непредвиденные изменения на сервере.

Выполнение этого изменения занимает около 1 минуты моего времени, но я чувствую, что делаю что-то неправильно.

Знаете ли вы, есть ли стандартный или правильный способ выполнения таких задач?

Answer 1

Экспортировать переменные среды на своих машинах и выбирать параметры на основе этой переменной окружения.

Answer 2

Использование что:

try: 
    from TestConfig import * 
except ImportError: 
    from Config import * 

На производстве, удалить TestConfig.py

Answer 3

Я думаю Django решает этот вопрос лучше всего с local_settings.py. На основе этого подхода. в конце все вашего импорта (после from config import *), просто добавьте:

# Add this at the end of all imports 
# This is safe to commit and even push to production so long as you don't have local_config in your production server 
try: 
    from local_config import * 
except ImportError: 
    pass 

И создать local_config.py на каждую машину. Что это будет делать, так это импортировать все из config, а затем снова с local_config, переопределяя глобальные параметры конфигурации, если они имеют то же имя, что и настройки внутри config.

Answer 4

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

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

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

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