 |
1
bt Mar 6, 2017  1
设置环境变量然后读取对应的配置文件？
|
 |
2
QAPTEAWH Mar 6, 2017
弄三个分支： dev 、 master 、 master_with_conf 。
dev 搞完后 merge 到 master 上，再把 master_with_conf rebase 到 master 上。 ------master---master_with_conf \ / .--dev-- |
 |
3
huweitxdy Mar 6, 2017
线上配置和本地开发的配置文件应该分成 2 个独立的文件，线上的那个文件只存在 master 里就可以了
|
 |
4
BigUncleLee Mar 6, 2017
把配置文件添加到.ignore 文件中
|
 |
6
mogita Mar 6, 2017
我目前了解的比较不错的方案：
1 、 env.example 入仓库，部署实例后 mv 成 env ，不要 add 这个 env 。 2 、约定好 env 的存放位置，只要在工程目录之外的就行，比如 /var/project/env ，然后程序里去读这个位置的 env ，绕开 env 入仓库的问题。 我们目前在用方案 1 。 |
 |
7
hekunhotmail Mar 6, 2017
切换 env 还要修改整个配置文件？ 做个开关吧，开关文件存一些全局环境变量， 两个配置文件， dev.cfg ， release.cfg ， env 不同读取不同的
|
 |
8
donghui Mar 6, 2017
不同配置分成不同的文件夹
或者配置与代码分离 |
 |
9
game3108 Mar 6, 2017
配置文件为啥不 ignore 呢？
|
 |
10
cxbig Mar 6, 2017
配置文件分 2 类：
1. 几乎是静态、无敏感信息的 做成模板文件上传，如.env.prod 、.env.staging ，部署或本地开发酌情选用并 cp 到.env ，.env 加 gitignore 2. 带有敏感信息的 不上传 repo ！可以做成特定模板，在部署的时候通过所使用的语言将占位符替换成敏感信息直接部署到服务器 可参考 Capistrano （基于 erb 模板）或 Ansible （基于 Jinja2 模板）的配置信息部署方案 |
 |
11
zhustec Mar 6, 2017 via Android
设置 2 个配置文件 production.config development.config 代码里根据环境读取相应配置文件，环境可用环境变量指定，可以设置不指定环境时默认为 production 或者 development
|
 |
12
irory Mar 6, 2017
每个环境对应单独配置文件呀 ...
|
 |
13
zero1234888 Mar 6, 2017
1.首先建立站点工作模式（ dev,beta,release ）把你的一堆配置项变成一个配置项
2.把这个配置项摘出来放进一个 baseSetup.config 里面保证除了必要的大改之外不会被动到 3. git update-index --assume-unchanged PATH 在 PATH 处输入要忽略的文件,把这个文件忽略掉,省得每次 git status 的时候跳出来烦人…… |
 |
14
GOOD21 Mar 6, 2017
目前在用的方案： link
dev.conf 和 pro.conf 同时提交到版本库， conf.conf 加入 ignore 开发环境： ln -nsf dev.conf conf.conf 线上环境： ln -nsf pro.conf conf.conf |
 |
15
sarices Mar 6, 2017
配置应该忽略的啊，然后线上部署的时候自动部署配置文件，而不是 push 到服务器上
|
 |
17
LinusTor OP @zero1234888 非常感谢.git 的这个命令还真没用过.等会儿研究下.
|
 |
18
xiaowei4895 Mar 6, 2017
个人觉得 git 的分支，只是文件版本的管理，不适合用来做环境的区分。
建议用打包脚本或者环境变量来进行环境的区分。 |
|
19
LinusTor OP @cxbig 嗯嗯.是的哈.一些数据库连接字符串等还是不能传 repo 的.除非仓库本来就是 private 的.
但是对于 py 的代码.部署的话也只是更新下仓库.重启下服务等.不会设计到部署编译. 貌似使用系统环境变量是不错的办法.这样也不会污染代码仓库.线上线下环境变量配置不同的就可以了. |
 |
21
crayygy Mar 6, 2017 via iPhone
我一般的解决方法是加到 ignore ，不过 Rails 给我一个启发，可以存同一个文件， production 和 development 分别用文件内的不同数据就好了。调用的时候声明一下当前环境再决定加载哪部分。
|
|
22
sarices Mar 6, 2017
@liangliangyy 配置文件别人也能修改那个是你们管理的问题了，部署我觉得最起码应该停止网站切换到维护模式，更新代码，然后更新配置文件等等，最后再重新开启。
|
 |
23
scriptB0y Mar 6, 2017
我在 django 的做法是：
settings 里面根据环境不同的配置（例如 debug ），使用从别的文件 import 的方式。这个文件本地、服务器各一份， gitignore 忽略。 另外，不要用 master 发布，从 master checkout 一个 release 分支，每次觉得可以发布就用 release 分支从 master 合并， 并且打上 tag ，这样可以保证快速回滚。 |
 |
24
nicevar Mar 6, 2017
这个需求与 git 没多大关系，不管你是做前段后端还是客户端开发，测试和正式环境都能通过配置来解决的， maven 的 properties 、 gradle 的 build variant ，尽量配置成不依赖特定环境的最省事
|
|
25
LinusTor OP @sarices 嗯哈 抱歉没表达清楚.我说的是在开发时候.配置文件更新了.然后别人开发的时候为了代码同步环境统一.肯定也要更新配置文件.这样如果没有在仓库里面的话只能靠手动更新了.
|
|
26
LinusTor OP |
 |
27
bearzk Mar 6, 2017
我的方法是 production, staging, local 都有不同的 config 文件,根据 env 使用一种, local config 被 `.gitignore` 忽略
还有推荐使用 gitflow https://github.com/petervanderdoes/gitflow-avh `master`, `develop`, `feature/*` 管理起来比较方便 也有方便的 release 流程 |
 |
28
TIGERB Mar 6, 2017
部署的时候初始化不同环境的配置文件么
|
 |
29
Waterm Mar 6, 2017
@bearzk 我也是用这种方法的。这样一来可以灵活配置自己本地的调试环境，二来进行多人协作时别人也能区分清楚。如果是做些个人小项目直接 gitignore 吧。
|
 |
30
SoloCompany Mar 6, 2017
出发点就不对，代码分支不应该和配置沾上任何关系，如果你的配置足够复杂，可以把配置单独建一个 repo
如果只是简单的配置，而且不存在敏感数据，可以所有配置都放到源码里面，执行的时候根据执行环境动态决定加载哪一套配置 |
|
31
cxbig Mar 6, 2017
@sarices 现在比较推崇无缝部署，如 Capistrano 等自动部署工具或 Blue-Green-Deployment 等策略。切换到维护模式越少越好。
|
 |
32
Felldeadbird Mar 7, 2017
开发的版本库不要和配置有任何直接的挂钩。否则团队其他成员一旦不知情下修改了。那些配置信息也被同步到生产环境中，将会带来严重的影响。
|
 |
33
ubear1991 Mar 7, 2017
用不同的配置文件。 master 就用 master 结尾的， dev 就用 dev 结尾的。
|
Select Language