当我们修改好代码准备上线时,第一个遇到的问题就是如何编译项目?如何发布项目?
play提供了比较简单的编译命令,可以一键式打包,打包的命令是:
play war youapplication -o outpath
youapplication:是你项目的路径名称,表示你要打包编译哪个项目
-o:表示你要将打好后的包输出到那个路径
outpath:即是你的输出路径
编译好后我们只要像普通web项目一样,将war包丢到tomcat中启动就可以了.
以上是一个整包替换的过程,比较初级,也比较花时间,没有任何思考和技术可言,对于一个更新频率不是很高的项目来说,掌握这点基础的运维手段已经可以应付.但是很多项目更新频率非常高,经常是一天一更新,每次都进行整包试的替换,每次都是手动的编译打包,上传,重启服务,虽然机械,但在自动化高效率的今天,这些手段未免太过低级,因此才有了后面自动打包部署编译的需求.
那么我们需要怎么样自动化呢?
- 首先我们要知道我们编译了什么,有哪些是我们需要的,哪些是我们不需要的.
解决这个问题的最佳方法是观察实践(这里属于我们内部自己的尝试研究,方法不是很科学,但实践验证了我们是正确的),先完整的编译出一个包,然后我们以此删减其中我们觉得不需要的内容,启动项目,观察项目运行是否正常.play项目打包后,会出现这么几个文件:
youapplication
|
- WEB-INF
|
-application
-classes
-framework
-lib
-resources
-web.xml
依次查看包中的内容,可以发现,编译好的主要类文件都处在application包中,该包中的东西稍后会重点介绍.
classes包中主要包含了一些项目的配置文件的副本,观察发现,他和application包下的conf包中的文件一模一样,实验之后发现,play在编译成war后,配置文件主要是读取application包下的conf中的文件,因此这个classes可以认定是一个不需要的包.可以直接删除,不影响正常运行.
framework包下主要是play自带的一些错误提示界面
lib包是整个项目需要依赖的jar包,包括play的jar包和项目单独引入的jar包,这个包中的内容若有新的jar包引入,也是需要每次添加的.
resources包下是一些国际化的配置文件信息,可以直接删除,不影响正常运行.
我们重点的看一下application包下的文件.可以发现,该包下的内容和我们项目的包名结构是一样的,所以我们更新,主要也是更新了这里面的内容,但是编译后,单独多出了一个precompiled包,打开这个文件夹后,发现他下面包含了2个文件夹,java和templates.
java包中就是我们编译好后的class文件,发现它与我们的项目结构是完全一样的,这个包中的内容是我们.java文件更新需要更新的内容或者说打补丁的位置.
templates包中是play模板生成的文件,其中包括路由routes文件的本地化缓存文件(conf),模板的本地化缓存文件(app),我们更新时,若改动了routes,则需要清空该文件夹下同名文件中的内容,否则我们此次修改的内容将不会生效,因为play会优先读取缓存中的文件.相应的,若我们修改了view下的模板文件,我们也需要清空该文件夹下同名文件中的内容.注意!!:这里是清空,不是删除,若删除了这些文件,play会报template not found错误,具体原因我还没有仔细研究过,日后会对源码进行一次具体分析,感觉这里也是play的一个不太好理解的地方和反常的地方,可能理解的还不够深刻吧.这个包中的我们主要需要清空的是如有手动修改的routes文件,和模板缓存文件
接下来看一下app文件夹下的东西,我们意外的发现,整个项目的源码,.java文件竟然都在这里面!这里也是play的一个坑,或者说不合理的地方,因此这些.java文件也是我们可以直接删除的东西.那么我们的模板文件呢,这一部分是我们需要保留的,也是我们真正需要更新的内容,因此我们保留views包作为模板更新的主要内容.后面我会介绍怎么打包才能过滤掉这些没有编译的源码文件
然后我们看conf包下的内容,这个包顾名思义就是我们的配置文件了,千万不要和外面的calsses这个马甲包搞混了哦,这边也是我们亲自踩过坑得出的实践教训.一般我们对项目的改动无非是增加了路由,或者是修改了application.conf中的一些配置项.这边我给出一个比较好的实践.每次更新时整个替换routes文件,因为我们可能增加了许多路由.每次涉及到application.conf文件改动时,做好相应的记录,项目更新人员根据配置文件改动记录,去修改整个文件,而不是整个替换.这边为什么要这么做呢,为什么不是整个替换?因为我们日常开发过程当中是分开发环境和生产环境的,可能还有测试啊,巴拉巴拉一大堆,每个开发的环境都是不一样的,相应的配置文件中的信息也是不一样的,若有人疏忽提交了配置文件的改动,但是更新的人又没有注意,导致错误的配置文件上线,也会引起很多麻烦.play在多环境开发这块提供的不是很灵活,很多配置需要我们手动的区分,相比较传统spring框架来说,这一块也是paly的弱点和不足.
然后是test包,lib包和tmp包,其中tmp包会存放项目的一些二进制文件,可以直接删除;
lib包是项目的jar包依赖,但是真正读取的jar包不是在application中的lib包,而是外层的lib包,因此也可以直接删除;
test包是存放项目单元测试的地方,可以删除,另外还有一些其他的例如日志logs包等,都是和项目无关的包,都是可以删除的
最后是我们的静态资源包,public,这里面是我们用到的图片资源,css,js等静态资源,这里面的东西我们也是保留,整个替换到项目中就好,这个不涉及太多技术要点
总结一下我们每次更新需要做的操作:
1.替换整个app包下的views文件
2.替换整个percompiled包下的内容,若涉及到手动的修改了模板文件或路由文件,需要将这个包下的缓存文件清空
3.替换整个public文件
4.替换conf下的routes文件,若修改了application.conf文件,则需要单独的修改,不要整个替换
5.若有新的jar包引入,则需要在WEB-INF--lib包中添加新的包,或删除旧的包
其他一些不需要的文件,在第一次整包替换的时候我们就可以删除,不需要每次都删一遍,因为我们后面也不会去提换这些文件.一般第5步也是比较少的.这些步骤可以根据具体的更新需求调整,不是每一次更新都需要的.
到这里我们已经解决了我们需要什么的问题,下一篇我在继续说如何优化我们的编译过程,加速编译的速度和自动编译