将大型应用程序从spring 3.0.x升级到4.1.x - 我应该遵循哪些最佳实践/程序？

Question

我已经使用Spring大约一年了,而且我已经足够舒服地使用它了,但我在大多数情况下都避免跳过引擎盖.

我的任务是升级从Spring 3.0.x到Spring 4.1.x的大型关键任务企业应用程序.

制作像这样的大型,不可避免的挑剔和复杂变化的最佳实践是什么？(任何超出'扔进jar文件,看看会发生什么'和'阅读文档:http://spring.io/ '会非常有帮助)

系统:

• Java 6 - jax-b/-p/-ws /,Apache Commons,

• Spring 3.0.5 - 通常(核心,上下文,bean等),MVC,AOP,ORM,JDBC,Acegi

• Hibernate 3.5

• 雄猫6

• 0单元测试或任何类型的自动测试.

• Maven依赖管理和构建自动化.

• 半控制器使用注释进行请求响应映射,一半使用simpleFormController模式,一半使用自动装配,一半使用xml连接.

• 数百个观点,数十个控制器.

到目前为止我采取的步骤:

• 准备一个(主要是自动化的)回归测试脚本(以便我可以确保我没有破坏任何东西)

• 我开始一次阅读"升级指南","升级到3.1","升级到3.2"并对听起来很熟悉的事情做笔记,但我想我需要更深入地了解在我对此作为一种详尽的方法充满信心之前,我们的系统,以及一般的春天.这通常感觉像是一种随意的方法,这不是我想要的这种复杂的变化.

我的问题:

• 对于像这样的工作,哪些步骤/程序被认为是"最佳实践"？

• 对你这样的工作来说,有什么东西可以作为'陷阱'吗？

Answer 1

显然,不会有"标准"的推荐做法,因为每次迁移/升级都是不同的.这是我的想法:

1. 要求,要求,要求

   回归测试脚本是一个很好的开始.如果有完整的功能/功能文档,那么迁移的"成功标准"很简单.

   如果文档不完整/不存在,则进行双重和三重检查以确保通过测试捕获所有"要求".创建文档也可能是一个好主意.并让产品经理/主管签字.即使在简单的系统中,您也会惊讶地发现有多少"隐藏"的要求.如果没有全面的要求,就有可能低估迁移所需的工作量.

   根据时间表设定正确的期望至关重要.也许一个敏捷的方法,每周两次演示你已经取得了多少进步将有助于让每个人都在同一页上.

2. Spring项目已经发展了很多.学习时间预算.

   这可能是一个很大的问题.自Spring 3.x以来,Spring项目和Java开发已经发展了很多.重大变化包括:

   • Java 8的功能
   • JavaConfig(与xml配置相对)
   • Acegi现在是Spring Security
   • Spring项目通常使用Spring Boot
   • 从Maven切换到Gradle用于构建项目
   • 使用Jenkins(或其他CI工具)的完整CI
   • 单元和集成测试已经转向使用注释(和模拟框架)