部署项目时一直用文件夹方式部署项目，近期尝试使用WAR包项目部署，遇到了下面的问题：
上传文件位置指定本地路径，但由于独立在项目外，还需要单独配置项目才能访问
公司项目数量多（1台服务器200左右，20台左右）时，每个项目这样配置，运维工作十分繁重
维护时只调整了一个css或JS文件，却要重新打包发布
对比之前文件夹方式，实在是很麻烦，想问下有经验的同学：
你遇到的使用WAR包方式的应用场景是什么？
如何解决我遇到的问题？
Following the voice in heart.
以下是我的实战运维经验：
配置应当是独立于项目的，这样可以只打一次war包，而运用到不同环境上；
运用自动化运维工具，如SaltStack、Ansible或Jenkins来帮助你批量操作；
如果预料到静态资源会频繁改动，最好跟Java项目分开来，部署到不同站点，或者用nginx做分流；
建议部署程序去解压war文件（而不是让Tomcat自己来解压），停掉Tomcat，ROOT目录用ln -s定向到新的目录，再启动Tomcat，这样Tomcat会跑得更流畅；
旧有的目录暂时不要删，如果部署错了，用ln -s把ROOT目录切换到旧的，就能实现快速回滚。
实际经验：我经手过的项目都是在weblogic上以目录的形式发布，目录结构：
DOMAINS --域 └─domainA --域A └─apps --应用 └─app1 --应用1 ├─deploy --部署 │ ├─src --Java源代码（仅限项目实施开发的源代码，不包含应用库的源代码），服务器统一编译一次防止Java版本问题以及编码问题 │ └─war --标准war包结构 ├─patch --增量更新目录 ├─runtime --运行时目录，日志，用户文件之类的 └─tmp --临时目录
我按照这种标准结构写了若干shell脚本来运维任务自动化，就是启停，监控，更新什么的，其实也就花了几天时间，代码也不多，但是现在我再也没有手动干过运维的事情了。
基本流程就是：代码开发提交-->SVN导出增量更新包-->上传至服务器-->服务器上执行
改一个html页面都要重新打包，万一打错文件进去咋办？ 静态的可以单独发布，那我他妈就改一个JAVA也要重新打包就活该啦？
没有一个容器是真正在war包里面发布和服务应用的，都是解压到某个临时位置，war包是压缩格式，你让任何一个容器每服务一个请求都去读取压缩文件里面的资源肯定会有性能问题的（至少JSP都是这样）。
这是我的个人经手的一些小型项目的解决方案，大型项目，你可能需要全流程工具链，就是什么持续集成什么的。
以下是我的实战运维经验：
配置应当是独立于项目的，这样可以只打一次war包，而运用到不同环境上；
运用自动化运维工具，如SaltStack、Ansible或Jenkins来帮助你批量操作；
如果预料到静态资源会频繁改动，最好跟Java项目分开来，部署到不同站点，或者用nginx做分流；
建议部署程序去解压war文件（而不是让Tomcat自己来解压），停掉Tomcat，ROOT目录用ln -s定向到新的目录，再启动Tomcat，这样Tomcat会跑得更流畅；
旧有的目录暂时不要删，如果部署错了，用ln -s把ROOT目录切换到旧的，就能实现快速回滚。
实际经验：
我经手过的项目都是在weblogic上以目录的形式发布，目录结构：
我按照这种标准结构写了若干shell脚本来运维任务自动化，就是启停，监控，更新什么的，其实也就花了几天时间，代码也不多，但是现在我再也没有手动干过运维的事情了。
基本流程就是：代码开发提交-->SVN导出增量更新包-->上传至服务器-->服务器上执行
改一个html页面都要重新打包，万一打错文件进去咋办？ 静态的可以单独发布，那我他妈就改一个JAVA也要重新打包就活该啦？
没有一个容器是真正在war包里面发布和服务应用的，都是解压到某个临时位置，war包是压缩格式，你让任何一个容器每服务一个请求都去读取压缩文件里面的资源肯定会有性能问题的（至少JSP都是这样）。
这是我的个人经手的一些小型项目的解决方案，大型项目，你可能需要全流程工具链，就是什么持续集成什么的。