V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
qping
V2EX  ›  科技

JAVAEE 项目中的开发、测试、部署整个流程有什么自动化的工具吗?

  •  
  •   qping · 2014-09-19 10:22:43 +08:00 · 5230 次点击
    这是一个创建于 3478 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在项目使用了一个问题平台,只能作为记录用(记录问题和修改的文件以及svn版本号),大量工作是人工做的,
    比如:
    配置管理员打出各问题增量包
    测试人员更新代码
    配置管理员每周打出各项目的多问题增量包
    现场获取增量包,测试,并手动更新到各应用服务器

    现在有个问题,项目数量多的人员过饱和工作了,如何改善这个流程?

    了解了下持续集成和相关工具,但是持续集成是基于整包的。有没有类似增量集成自动化的工具呢?

    公司现在用的是svn....
    第 1 条附言  ·  2014-09-19 11:05:51 +08:00
    我处的项目更多的是维护和一些新增需求,要求是尽快的能够更新到现场
    而且项目整包是1G,整包发布不现实
    (就不要吐槽项目的优化了,因为历史原因,个人感觉这个项目1 2年后就要被推翻了)
    7 条回复    2014-09-19 14:03:55 +08:00
    wintersun
        1
    wintersun  
       2014-09-19 10:49:48 +08:00   ❤️ 1
    不太明白这个增量包是个什么东东? 一堆更新了的java class?jsp?

    但是SVN是有branch特性的。一般的做法是:基于当前的Trunk版本,可以为将来某天发布、具备某些特性、修复某些bug创建一个branch(其实就是另一个代码库),程序员对这个branch的代码进行更新,测试人员也基于这个branch进行测试。达到要求后,使用branch中的代码进行编译、全新发布;发布成功,将branch中的变更merge回Trunk,Trunk继续成为下一个branch的基线代码库。 merge这个动作都是基于源代码的,而且都要求哪个程序员改动的,哪个就负责merge回Trunk库,遇到多个程序员修改同一部分代码,要求他们内部协调,一般都不会有太大的代码冲突。

    如果你的增量包就是我理解的那样,的确工作量大而且容易出错,配置管理形同虚设!请牢记:配置管理应该主要基于源代码(不是绝对,但应该是绝大多数),而非编译后的目标文件。
    hcymk2
        2
    hcymk2  
       2014-09-19 10:57:26 +08:00   ❤️ 1
    qping
        3
    qping  
    OP
       2014-09-19 11:02:45 +08:00
    @wintersun 诚如你所说,增量包包含 class jsp js还有其他资源文件,可以直接更新到服务器上。

    我的理解你看对不对:你说的流程感觉更像产品开发阶段,我处的项目更多的是维护和一些新增需求,要求是尽快的能够更新到现场,而且项目整包是1G(就不要吐槽项目的优化了,因为历史原因,个人感觉这个项目1 2年后就要被推翻了),整包发布不现实
    qping
        4
    qping  
    OP
       2014-09-19 11:06:59 +08:00
    @hcymk2 谢谢,我了解过一些持续化集成的工具,虽没有上手,感觉与我们的需求不是很符合,还是很感谢!
    davepkxxx
        5
    davepkxxx  
       2014-09-19 11:14:19 +08:00   ❤️ 1
    maven配合jenkins
    qping
        6
    qping  
    OP
       2014-09-19 11:30:43 +08:00
    @davepkxxx 这么多人推荐,那我仔细研究下吧,谢拉
    wintersun
        7
    wintersun  
       2014-09-19 14:03:55 +08:00
    @qping maven配合jenkins估计也解决不了你的问题。
    我觉得你需要的是一个程序(Ant?Java?Python?)来帮你处理编译后文件的更新问题,大致流程如下:
    1、下载和解压目标WAR文件到某个文件夹,这个WAR文件也就是你已经发布到产品服务器上的那个,本质都是zip格式,你懂的
    2、查找文件更新:给定一个日期(上次发布的日期?),通过该日期比对源文件的最后更新日期(SVN?本地?),决定是否将该源文件对应的class文件或jsp、js等复制到目标WAR文件夹(假定已经完成编译和其他资源处理)
    3、重新压缩WAR文件夹为WAR文件
    4、你最好还是基于Branch来,否则在Trunk中有些不必要的文件更新也会纳入进来

    —————————————————————分割线——————————————————
    说回Maven+Jenkins,我理解你们的处境,别说1G,就算是几十兆的包我都容忍不了,呵呵。
    我采取的办法是在生产环境(不一定是服务器,可以是自己的机器或者客户方提供的部署用的机器),使用楼上提到的Maven+Jenkins(当时还叫Hudson),SVN不在生产环境本地都没有关系,只要能联网更新,进行编译、打包,最终的war包要么自动发布上去,要么手工ftp上去,要么U盘copy上去…… 第一次会比较慢,因为要更新所有的源代码并编译,还要下载jar包…… 当然,你可以预先把一个本地的Maven Repository复制到Jenkins服务器上!

    总之,不要人工去更新那些war包。

    如果你们没有用Maven,用Ant也是可以的,如果你们连Ant都没有用,那就从Maven开始重构吧!
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3246 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 13:55 · PVG 21:55 · LAX 06:55 · JFK 09:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.