配置文件位置
这里主要讲的是，配置文件不要跟源码放在一个目录。比如我新建了一个 django project，然后用了里面的 settings 来作为我代码的配置。你项目目录可能是这样的
mysite/
├── apps
│ ├── account
│ │ ├── control.py
│ │ ├── __init__.py
│ │ ├── urls.py
│ │ └── views.py
├── settings.py
这里 settings.py 跟源码放在同一个目录。这样会很出这个问题，如果你每次更新线上环境的时候，都是把源码打成一个包（例如 deb 包 )，然后安装的时候，替换这个目录。这样你每次线上的配置都会给你覆盖掉。例如我线上配置了每次登陆系统的用户是 50，你这个新包里的配置是一个默认值，那这样就不一致了。
所以，代码还是代码，配置还是配置，不要混在一起，虽然很简单，但是很有必要考虑。
这里应该在 project 源码外面新建一个目录 conf，来存放配置文件。
project/
├── conf
│ └── settings.py
├── mysite
│ └── apps
│ └── account
│ ├── control.py
│ ├── __init__.py
│ ├── urls.py
│ └── views.py
这样每次每次更新都不会覆盖配置文件，并且原来的配置文件可以作为配置模板，不负责配置实例。
配置本地化
对于前面的问题，你不打算新建一个目录存放配置的话，或许可以通过支持配置本地化来解决，也就是支持服务有自己的配置，不会因为配置文件更新而被覆盖，比如你在代码层面支持 local_settings.py 每次读取配置的时候，会先从 local_settings.py 里读取，然后再从 settings.py 里读取。
服务支持获取最新配置
如果你的配置文件经常修改，并且每次服务都需要用到最新配置，那么可能需要服务在代码层面支持检测配置文件是否被更新，更新了则使用最新配置。
如果你用服务线程定期去检测配置文件，然后更新自己内存里的值，这也可以，首先生产环境需要支持配置自动部署更新，比如我通过集群里一个节点推送到其他节点，实现全部更新。或者使用一些开源服务，由该基础配置服务提供统一接口，其他服务通过该接口读取配置，这样实现起来可能会更简单。总之，各取所需。