2016-04-19 17 views
2

私は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分かかりますが、何か間違っているような気がします。

この種のタスクを達成するための標準的な、または正しい方法があるかどうか知っていますか?

答えて

1

マシン上の環境変数をエクスポートし、その環境変数に基づいて設定を選択しました。

+0

あなたの答えをありがとう。私は現在、同じマシンでスクリプトを実行しています。 2つの異なるサーバー(本番環境からのものと開発環境からのもの)にスクリプトを展開し、環境変数に従って実行するようにスクリプトを変更する必要がありますか? – user3397363

2

用途:生産で

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

は、TestConfig.py

0

を削除するには、私はlocal_settings.pyで最高のDjangoアドレスこの問題を考えます。このアプローチに基づいています。

# 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を作成します(from config import *後)、すべての輸入品の終わりに、ちょうど追加。これは、configからすべてのものをインポートし、次にlocal_configからグローバルコンフィグレーション設定をオーバーライドして、configの設定と同じ名前にする必要があります。

0

スクリプト内の本番環境とテスト環境を実際に区別したい場合、他の答えは完全にきれいなソリューションです。私は別のアプローチを勧めます:あなたのコードを適切にテストするためには、全く別のテスト環境を作成し、コードを変更せずに実行する必要があります。

私はスクリプトが何をしているのかわからないので、これについての具体的な提案はできません。しかし、一般的には、実稼働環境を偽装し、完全に隔離されたサンドボックスを作成するようにしてください。サンドボックスでコードを実行するラッパースクリプトを作成し、必要に応じて入力と出力を変更して、コードを本番環境ではなくテスト環境と対話させることができます。このラッパーは、コードが実行される環境と使用する設定ファイルを選択する場所です。

このアプローチでは、コード自体からテストを抽象化し、両方を保守しやすくしています。テストのための設計は、ハードウェアにとって合理的なアプローチです。製造後のハードウェアに悩まされていますが、ラッパーやスプーフィングされたデータの管理が容易なソフトウェアにとっては意味がありません。テストを処理するために生産コードベースを変更する必要はありません。

また、テストと実稼働環境への移行を切り替えるときに、何かを変更することを忘れることもありません。

関連する問題