有一个团队使用web接口开发企业应用程序: java、tomcat、struts、mysql、REST和LDAP对外部服务的调用等等。
所有配置都存储在context.xml --tomcat特定的文件中,该文件包含通过servlet上下文可用的变量和通过JNDI资源可用的对象。
开发人员无法访问生产和QA平台(应该是这样),因此context.xml由support/sysadmin团队管理。
每个版本都有config-notes.txt,说明如下:
please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and credentials) named "barDb"这可不妙。
这是我的想法,如何解决它。
每个版本都有特殊的配置文件,其中包含所需的变量名称、描述和默认值(如果有的话):甚至可以使用web.xml。
下面是伪示例:
foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)还有一个特殊的工具,支持团队运行在部署工件上。看看它( ">“后面的文本是由支持人员输入的):
Config for version 123 of artifact "mySever".
Enter your config file location> /opt/tomcat/context/myServer.xml
+"foo" value "bar" -- already exists and would not be changed
+"userLimit" value "123" -- adding new
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db
Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.这将使我们能够在任何环境上部署应用程序,并在需要时更新配置。
你接受我的建议吗?用于环境配置管理的是什么?有现成的工具吗?
发布于 2012-04-24 01:27:38
有很多不同的策略。它们都是好的,取决于什么最适合你。
至于整个发展中国家是否能够获得prod,这实际上取决于每个公司的基础。对于每次出现问题时调用dev的小型公司来说,无论该问题是与服务器有关还是与应用程序相关,很明显,devs都需要访问该机器。
DevOps不是让devs访问盒子,而是让devs能够使用基础设施作为服务,用配置Y生成应用程序X的新实例,并将它们的应用程序推入没有操作系统的环境中。在像我们这样的大公司里,它允许的是开发人员管理他们放在服务器上的应用程序的能力。操作不应该关心他们的版本,这是我们的工作,他们的工作都是保持服务器的正常运行。
发布于 2011-11-04 01:35:12
我强烈不同意您的意见,即devs不应该访问prod或暂存环境。正是这种态度导致了团队之间的相互对抗,而不是彼此之间的竞争。
但是,要回答您的问题:您正在考虑什么通常称为持续集成( http://en.wikipedia.org/wiki/Continuous_integration ),并走向发展。理想情况下,您应该瞄准神奇的"1单击自动部署“。Flickr的人写了很多博客(和书籍)来说明他们是如何做到这一点的。不管怎样..。在这个领域有很多工具。你可能想看看哈德森/詹金斯或木偶/厨师之类的东西。
https://stackoverflow.com/questions/8003930
复制相似问题