有一个团队用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"
这不好。
这是我的想法如何解决它。
每个版本都有特殊的 config 文件,其中包含必需的变量名称,描述和默认值(如果有):甚至可以使用 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.
这将使我们能够在任何环境中部署应用程序并在需要时更新配置。
你喜欢我的主意吗?您如何使用环境配置管理?是否有现成的工具?答案 0 :(得分:2)
有很多不同的策略。所有这些都很好,取决于最适合你的。
至于整个应该让devs获得prod,它实际上取决于每个公司的基础。对于每次出现问题时调用开发人员的小型公司,无论该问题是服务器还是应用程序相关,显然开发人员都需要访问该框。
DevOps不是要让devs访问这个盒子,而是让devs能够使用基础架构作为服务,能够使用配置Y生成带有应用程序X的新实例,并将他们的应用程序推送到没有操作的环境中。在像我们这样的大公司中,它允许开发人员管理他们放在服务器上的应用程序。操作不应该关心他们的版本是什么,这就是我们的工作,他们的工作就是保持服务器正常运行。
答案 1 :(得分:1)
我非常不同意你的观点,即开发者不应该访问prod或staging环境。正是这种态度导致团队互相反对,而不是与其他团队合作。
但是要回答你的问题:你正在考虑什么通常被称为持续集成(http://en.wikipedia.org/wiki/Continuous_integration)并转向devops。理想情况下,您应该瞄准神奇的“单击自动部署”。来自Flickr的人写了很多关于他们如何实现这一目标的博客(和书籍)。 无论如何......围绕这个领域有很多工具。你可能想看看像Hudson / Jenkins或Puppet / Chef这样的东西。