我目前正在研究一个已经测试了一段时间的j2ee项目.现在我们正在解决部署过程中的一些问题.具体来说,战争中嵌入了许多文件(一些xml文件和.properties),这些文件需要部署不同的版本,具体取决于您是在开发,测试还是生产环境中.像loglevels,连接池等的东西
所以我想知道开发人员如何构建他们部署webapps的过程.您是否将尽可能多的配置卸载到应用程序服务器?在部署之前以编程方式替换设置文件吗?在构建过程中选择一个版本?手动编辑战争?
您还可以通过应用程序服务器的静态库在多大程度上提供依赖关系,以及您自己在战争中投放了多少?所有这些只是为了了解目前常见(或可能是最佳)实践的一些想法.
我认为如果属性是特定于机器/部署的,那么它们属于机器.如果我要在战争中把事情包起来,它应该是无法实现的,这意味着没有任何特定于它正在运行的机器.如果战争中有与机器相关的属性,这个想法就会破裂.
我喜欢做的是使用properties.example文件构建一个项目,每台机器都有一个.properties,它存在于war可以访问它的某个地方.
另一种方法是拥有蚂蚁任务,例如开发战争,阶段战争,生产战争,并将项目的一组属性作为战争构建中的一部分.我不喜欢这个,因为你最终会在单个服务器上将文件位置等内容作为项目构建的一部分.
我在一个单独的服务器团队为我们的应用程序执行QA和Production服务器配置的环境中工作.每个应用程序通常部署在QA中的两个服务器和生产中的三个服务器上.我的开发团队已经发现,最好是通过把尽可能多的配置尽可能在战争中(或耳)到服务器上需要的配置的量最小化.这使服务器配置更容易,并最大限度地减少了服务器团队错误配置服务器的可能性.
我们没有特定于机器的配置,但我们确实有特定于环境的配置(Dev,QA和Production).我们有一些存储在war文件中的配置文件,这些配置文件由环境命名(例如dev.properties,qa.properties,prod.properties).我们在服务器VM的java命令行上放置-D属性来指定环境(例如java -Dapp.env = prod ...).应用程序可以查找app.env系统属性并使用它来确定要使用的属性文件的名称.
我想如果你有少量特定于机器的属性,那么你也可以将它们指定为-D属性.Commons Configuration提供了一种将属性文件与系统属性组合在一起的简便方法.
我们在服务器上配置连接池.我们将连接池命名为每个环境都相同,只需将分配给每个环境的服务器指向相应的数据库即可.应用程序只需要知道一个连接池名称.