现在大部分都是采用maven构建的项目，但是偶尔也会遇到一些较老的项目，采用的是传统的动态Web项目。
我最近碰到这样一个项目，项目用的jar包都放在了WEB-INF/lib目录下。之前的人采用的部署方式是这样，首先在服务器上面安装好tomcat，然后将项目编译后的文件夹放到服务器某目录，假设在/home/project中，然后通过tomcat配置<Context path="/" docBase="/home/project" debug="0" reloadable="true"></Context>将编译后的文件夹映射到tomcat中，启动tomcat，项目也随之启动。
如果有代码更新，那么先在eclipse中将项目进行编译，然后本地编译好的文件和服务器上的文件进行比对，比对软件是Beyond Compare，如果有不同就将本地的文件覆盖服务器的文件。
这种部署和更新方式确实很麻烦，这种方式一旦遇到团队较大或者更新内容较多，无疑是十分麻烦的。
后面思考如何自动化部署，首先想到的是jenkins，但是jenkins一般用于maven项目的构建，因而否决了。然后想到不管采用什么方法，肯定是先要通过git将项目从仓库拉取到服务器，然后再服务器上编译好，然后再重启tomcat就可以了。沿着这个思路想到了其实可以采用javac命令编译项目，然后发现了ant，ant可以构建传统的项目，现在已经被maven取代了。不过老的项目还是只能用ant构建，解铃还须系铃人。在服务器上面安装好git后，拉取了最近的代码。然后安装了ant，编译好项目。重启tomcat即可。
至此采用自动化的方式，不是人工手动比对文件是否修改。但是过程依然很多，然后采用shell脚本，将 git拉取代码 ant编译项目 tomcat重启等步骤全部写在一个shell脚本。每次有代码提交后，只需要运行这个脚本即可。
后面发现jenkins其实是支持ant的，绕了一圈 :(
后面决定重新采用jenkins，首先配置好jenkins，将ant的build.xml文件放在源码的根目录，然后jenkins调用内置的ant执行build.xml的脚本。原本都很顺利，但是又出现了一个新的问题，ant的build.xml文件中有个步骤是将编译好的文件复制到特定文件夹，但是这一步遇到了一个错误提示”未知原因“，当时我就在思考可能是权限问题。linux系统对权限控制较好，root用户和普通用户的权限区分的很明显。虽然有思考是这个原因，但是无法验证，也没有思考到如何去查询。后来我将需要复制的文件通过root用户身份复制一遍，但是jenkins在构建后执行shell脚本时又出现了问题，明确显示”权限不足“。这样验证了我的想法，然后根据提示信息，查询到了原因。大意是jenkins在执行shell脚本时，会在系统中以一个名为jenkins的用户去执行脚本，而有些文件需要较高的权限，因而会遇到之前的问题。需要在jenkins配置文件中修改一些配置。然后解决了问题。
经过这一系列的过程，虽然大致能跑通，但是肯定有优化的地方，也或者没有。但是中间遇到很多问题，网上查询这些问题花费了较多时间，而且网上的文章参差不齐，找到完全契合你的需求的更加少。其实一般某个软件或者框架，官网的文档应该是最优最好。网上查了那么多的资料，感觉学会如果想快速搞懂一个软件或框架，需要先理清其中的一些概念，然后建立一个大概的模型，然后再学习细节，完善内容。毕竟要学的东西太多，而且这家公司学习的东西，在别家的公司不一定能复用。因此学会如何快速掌握一门新的技能或知识也是急需解决的问题，当然没有银弹，需要根据不同的情况制定不同的思考方式。