Upgrading Spring Boot

dependency
upgrade
spring-boot
(Josh Zamor) #1

As we wrap up our latest release, and since we’ve recently marked over two years since our first 3.0 (non-beta) release, I wanted to start collecting feedback on how we might upgrade our services away from Spring Boot 1.X which hits EOL August 2019.

To kick this off I can start with some ideas:

  • Upgrade the Service Template today / ASAP before anyone starts a new service.
  • Upgrade the most actively developed service first - our architecture gives us some (not indefinite nor complete) flexibility in what we upgrade and when. If we upgrade the service which we predict will have the most development going forward, we’ll start learning what it takes to upgrade the rest.
  • Or alternatively upgrade the least developed / smallest code-base first. This might give us quicker feedback on how to upgrade, and exposes the team to less risk while figuring it out.
  • If we’re concerned about performance / reliability being impacted in the upgrade, one pattern I’ve heard being used is to auto-merge each commit to a parallel branch which has the upgraded framework. If the commit fails in building either the main branch or the upgraded-framework branch, then the entire build is failed so that the developer can get quick feedback if their commit works within the upgraded framework, or if it causes issues. I don’t think we need this, though maybe I’m wrong?

I know I’ve played around with a toy branch to upgrade Reference Data and hit some pretty big snags. I think other’s have as well in other services.

I’d like to gather feedback:

  • Have you experimented with upgrading?
  • What service should we upgrade first?
  • How would you propose we figure it out?
  • How would you replicate it to other services?

Best,
Josh

(Łukasz Lewczyński) #2

Sorry for a late response. Below you can see my answers to your questions:

Recently, I upgraded the spring framework in the HAPI FHIR service. It was not so hard as I supposed it will be. I only had to change some code to remove deprecated methods. I assume that in other services process will look quite similar.

Definitely, the template-service should be selected as first to upgrade. After that, I am not sure. One option is the requisition service because we often modify the code in that service but I little worry that we would get a lot of issues after upgrading and some work can be blocked because of that.

By gathering opinions from other developers and selected the best option based on that :wink: I would say we could simply go from one service to another without looking on priority or usage. For me, the alphabetic order is good as well as the usage order.

In the same way how we do with other things. Check what was changed in the given service and do the same in the current one. After that verify that service works correctly. If there is a bigger issue inform about it on slack or create a post on the forum.

Regards,
Lukasz

(Elias Muluneh) #3

I have briefly experimented with upgrading the fulfillment service to utilize Spring 5.x features that could have helped significantly. I stopped my experiment when blocked by removed support for JasperReport. The fulfillment service uses Jasper Report.

In retrospect, It appears there is a way to still continue to use jasper report but may require some refactoring to use native JasperReport APIs.