将大型应用程序从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?
问题描述
我已经使用Spring大约一年了，使用它我已经很舒服了，但是在大多数情况下，我避免跳入引擎盖.
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 3.0.x升级到Spring4.1.x.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
进行这样的大型，不可避免的挑剔和复杂变化的最佳实践是什么? (除了之外的所有内容，'将其扔入jar文件中，看看会发生什么情况'和'，请在此处阅读文档://spring.io/'会很有帮助)
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)
系统:
-
Java 6-jax-b/-p/-ws/，Apache Commons，
Java 6 - jax-b/-p/-ws/, Apache Commons,
春季3.0.5-常规(核心，上下文，bean等)，MVC，AOP，ORM，JDBC，Acegi
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
休眠3.5
Tomcat 6
0个单元测试或任何类型的自动化测试.
0 unit tests or automated testing of any kind.
Maven依赖管理和构建自动化.
Maven dependency management and build automation.
半个控制器使用批注进行请求响应映射，一半使用simpleFormController模式，一半自动装配，一半与xml挂钩.
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.
到目前为止我已经采取的步骤:
Steps I've taken so far:
-
准备了一个(基本上是自动化的)回归测试脚本(以便可以确保我没有破坏任何东西)
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
我已经开始一次阅读升级指南"，分别是升级到3.1"，升级到3.2"，并在听起来很熟悉的地方做笔记，但我认为我需要在我对这是一种详尽的方法充满信心之前，请对我们的系统有更深入的了解，并且总的来说请适时了解.通常，这感觉就像是一种偶然的方法，这不是我想要的如此复杂的更改.
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.
我的问题:
-
对于这样的工作，哪些步骤/过程被认为是最佳实践"?
是否有任何事情像这样的工作成为您的陷阱" ?
推荐答案
很显然，不会存在标准"的推荐做法集，因为每次迁移/升级都是不同的.这是我的想法:
Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
-
要求，要求，要求
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.
春季项目已经发展了很多.学习时间预算.
Spring projects have evolved a lot. Budget for learning time.
这可能是一个大难题.自Spring 3.x以来，Spring项目和Java开发已经发展了很多.重大变化包括:
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
- Java 8功能
- JavaConfig(与xml配置相反)
- Acegi现在是Spring Security
- Spring项目通常使用Spring Boot
- 从Maven切换到Gradle以构建项目
- 使用Jenkins(或其他CI工具)进行完全CI
- 单元和集成测试已转向使用注释(和模拟框架)
这篇关于将大型应用程序从Spring 3.0.x升级到4.1.x-我应遵循哪些最佳实践/程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
