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

Upgrading large application from spring 3.0.x to 4.1.x - What best practices / procedures should I follow?

提问by Paul

I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.

我已经使用 Spring 大约一年了，我使用它很舒服，但我在很大程度上避免了在引擎盖下跳来跳去。

I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.

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

What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens'and 'read the documentation here: http://spring.io/'would be very helpful)

进行这样的大型、不可避免的挑剔和复杂更改的最佳实践是什么？（除了“放入 jar 文件，看看会发生什么”和“在这里阅读文档：http: //spring.io/”之外的任何内容都会非常有帮助）

The system:

系统：

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

• Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi

• Hibernate 3.5

• Tomcat 6

• 0 unit tests or automated testing of any kind.

• Maven dependency management and build automation.

• Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.

• Hundreds of views, scores of controllers.

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

• Spring 3.0.5 - 常规（核心、上下文、bean 等）、MVC、AOP、ORM、JDBC、Acegi

• 休眠 3.5

• 雄猫6

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

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

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

• 数百个视图，数十个控制器。

Steps I've taken so far:

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

• Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)

• I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.

• 准备了一个（主要是自动化的）回归测试脚本（这样我就可以确保我没有破坏任何东西）

• 我已经开始一次通读“升级指南”，“升级到 3.1”、“升级到 3.2”并对听起来很熟悉的事情做笔记，但我认为我需要更深入地了解在我确信这是一种详尽无遗的方法之前，我们的系统，以及整个春天。这通常感觉像是一种随意的方法，这不是我想要的如此复杂的变化。

My questions:

我的问题：

• What steps/procedures are considered 'best practice' in these for a job like this?

• Does anything jump out at you as a 'gotcha' for a job like this?

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

• 对于这样的工作，有什么让你觉得“陷阱”的吗？

回答by Jigish

Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:

显然，不会有“标准”的推荐做法集，因为每次迁移/升级都是不同的。这是我的想法：

1. Requirements, requirements, requirements

   Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.

   If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.

   It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.

2. Spring projects have evolved a lot. Budget for learning time.

   This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:

   • Java 8 features
   • JavaConfig (as opposed to xml configuration)
   • Acegi is now Spring Security
   • Spring projects typically use Spring Boot
   • Switch from Maven to Gradle for building projects
   • Full CI using Jenkins (or other CI tools)
   • Unit and integration testing have moved on to using annotations (and mock frameworks)

1. 要求，要求，要求

   回归测试脚本是一个很好的开始。如果有特性/功能的完整文档，那么迁移的“成功标准”很简单。

   如果文档不完整/不存在，则进行双重和三次检查以确保所有“需求”都被您的测试捕获。创建文档也可能是一个好主意。并让产品经理/主管在上面签字。即使在简单的系统中，您也会对有多少“隐藏”需求感到惊讶。在没有全面要求的情况下，低估迁移所需的工作量的风险很大。

   在时间表方面设定正确的期望非常重要。也许采用双周演示您取得的进展的敏捷方法将有助于让每个人都保持一致。

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

   这可能是一个大问题。Spring 项目和 Java 开发自 Spring 3.x 以来有了很大的发展。重大变化包括：

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

回答by abarisone

Well, it is not easy to answer you question since there are many things to be taken into account.

嗯，回答你的问题并不容易，因为有很多事情需要考虑。

First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guidethat's coming directly from the 'source'.

首先，我建议您使用直接来自“源”的从Spring Framework 的早期版本迁移指南。

I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries. Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts. Take also a look to the dependency updates section.

我会特别提醒您注意“强制最低依赖版本”部分，该部分向您推荐了一些广泛使用的库的最低版本级别。显然，当您插入这些新版本时，它们会带来一些可能会产生冲突的传递依赖项。另请查看依赖项更新部分。

Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).

还要记住在您的 pom 文件中正确定义依赖项的范围，因为其中许多可以由您正在使用的基础设施（即 Tomcat）提供。

I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.

我认为您将需要迁移到 Java 7 或 8，并且 Tomcat 也应该更新到版本 7 或更好的 8。

Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).

此外，尝试使用 maven 尽可能自动化您的构建和测试环境，同时采用像 Jenkins（或 Hudson，如果您喜欢该产品）这样的 CI 环境。

It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.

对每个小方法/代码段执行单元测试也非常重要，因为它会使集成测试更容易。

You should also become familiar with Spring 4.x new featuresand try to exploit them especially those regarding testing improvements. A little resume of new features is the following:

您还应该熟悉Spring 4.x 的新特性并尝试利用它们，尤其是那些与测试改进相关的特性。新功能的小简历如下：

• Removed Deprecated Packages and Methods
• Java 8 Support
• Java EE 6 and 7 become the baseline
• Groovy Bean Definition DSL
• Core Container Improvements
• General Web Improvements
• WebSocket, SockJS, and STOMP Messaging
• Testing Improvements with extreme use of annotations

• 删除了不推荐使用的包和方法
• Java 8 支持
• Java EE 6 和 7 成为基准
• Groovy Bean 定义 DSL
• 核心容器改进
• 一般网络改进
• WebSocket、SockJS 和 STOMP 消息传递
• 极端使用注释的测试改进

Take also a look to Spring MVC Test Tutorialby Petri Kainulainen that can give you a lot of informations about testing.

还可以看看Petri Kainulainen 的Spring MVC 测试教程，它可以为您提供很多有关测试的信息。

回答by bhantol

You have to have answer to the following before you proceed.

在继续之前，您必须回答以下问题。

Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?

是否只需要升级某些依赖项的库和运行时？

OR

或者

You really want to get the most out of Spring 4.x ?

您真的想充分利用 Spring 4.x 吗？

Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.

一旦你决定了这一点，你就可以采取适当的做法。您创建的那些回归脚本将在这两种情况下都有帮助。如果您能想到一些粗略的一次性实用程序，它会使用一些有效的输入来访问每个公共 API 并捕获输出，并且无法在这两个世界中进行比较，这可能会有所帮助，但可能不适用于您的情况。

So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.

因此，如果您想从 Spring 4.x 中受益，我建议您关注生产力方面并创建这些内容的清单。

You may redesign the whole app in Spring 4 as if it is a new application.

您可以在 Spring 4 中重新设计整个应用程序，就好像它是一个新应用程序一样。

Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.

一旦你可以设想未来的状态。下一个问题简化为从 A 点到 B 点，即最佳迁移路径问题。

回答by sachin k

From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's Spring Integration 3.0 to 4.0 Migration Guideon Github.

从 Migrating from Spring 3 to Spring 4，您可能会从Github 上Spring 项目的Spring Integration 3.0 到 4.0 迁移指南中获得一些帮助 。

Hope it helped!

希望有帮助！