-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#1432 导致我的配置流程失效 #1560
Comments
本地开发可以使用本地开发模式。 不建议在项目中通过配置文件覆盖,因为比较容易把本地配置文件误提交到远端仓库。 |
我确实把本地开发模式给忘了,一直没用过。
|
可以有个增加一个dev环境,数据取自本地文件,不提交到后端,那样就可以相互隔离了。
发自我的 iPhone
… 在 2018年10月13日,11:10,hexinzhe ***@***.***> 写道:
我确实把本地开发模式给忘了,一直没用过。
不过您说的误提交,
如果是指提交到远程仓库之后会导致其余环境下 apollo 的配置也会被覆盖的话,并不会。
如果是指提交到远程仓库后会导致干扰其它的人本地配置的话,确实是,但本地开发模式也有同样的问题,这种事情无法避免。
本地开发模式倒是能解决,但问题是一大坨配置又塞到源码里面了,原本只需要“继承” apollo 的绝大部分配置,需要修改的地方手动覆盖即可(与你们的 public ns 思路一致),现在则变成了本地配置与 apollo 不能并存,本地想要修改,就不能用 apollo,这是不是不太合适呢?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@qmwu2000 不太明白,我的意思是本地开发模式不能复用 apollo 的配置,没有想要完全隔离呀 |
我指的误提交是指代码中的配置文件如果优先级高于apollo,那么一旦这些文件随代码提交之后,在实际运行的时候就会生效,从而导致问题。 所以,对于本地开发的临时配置,一般是通过其它外部化的方式解决,比如-D参数,比如本地模式中的本地配置文件等,这类方式杜绝了本地配置错误随代码提交的可能。 还有一种方式是每个开发都在apollo上创建一个集群,然后本地server.properties中指定idc=对应的集群名字,也能实现开发之间互不影响。 |
ok,明白,我也看到之前有别人提到这个问题,但是这种情况很好解决,这个配置文件不打到包里就行了,不管是配置 maven 生命周期还是配置 ci 流程都好办,并且还是个一劳永逸的操作。如果因此就在本地禁止 apollo,好像有点因噎废食吧。 |
有一个办法可以实现你的目标:
该方式能工作的原因是在Apollo中有预埋逻辑,会去尝试读取该文件作为namespace配置的补充,详细可以参考DefaultConfig.java |
没毛病,多引了一个 namespaces: <copy todir="${project.build.outputDirectory}/META-INF/config/">
<fileset dir="${project.build.outputDirectory}/">
<include name="application-dev.properties"/>
</fileset>
</copy> 就可以了。 |
多谢各位了 |
你好,请问下这个复制文件在pom文件中是怎么添加的? |
我看一些人会需要 apollo 配置能覆盖本地的,并且在最新版本中还“修复”了这个问题。
但其实我一直在利用这个特性来实现本地开发修改隔离,方便开发时开发人员自行修改,如果使用 -D 毕竟不是那么方便,本地配置可能很多。只要打包的时候将这个本地配置剔除出去就行了,线上所有配置还走 apollo 即可。结果 1.1 改策略之后我本地就不能覆盖远程配置了,希望能提供一种选项能退回之前方式,或者你们有什么最佳实践分享一下?
The text was updated successfully, but these errors were encountered: