I have inherited some legacy Java code that needs to be updated to a new release in the near future. I am looking for opinions to see if my migration strategy sounds reasonable and to hear from anyone who might have any alternative suggestions or useful comments. I have read all sorts of language compatibility summaries, but I haven't come across anything that relates on how I might best approach a migration having to do with more than one box/server.
Java X is the version of Java that I inherited
Java Y is the version of Java that we would like to migrate to in the very near term
Java Z is the version of Java that is the next major release after Java Y
At this time, Java Z does not appear to be an option. We plan to remove some current dependencies after the update to Java Y. These dependencies are currently preventing us from updating to Java Z.
Our version control system has the following stages, each stage with its own server.
Dev --> Unit --> System --> Qual --> Production
When code is moved from one stage to the next, a build and redeploy will eventually take place on that server. All servers are currently running Java X.
As a first step, I wanted to see what kind of problems we might run into with the update. So, I updated my developer box to Java Y and testing seems to be going well. Now, what might be the best approach going forward?
My gut feeling is that we should update the Dev server to use Java Y, then test, then upgrade the next server -- as long everything still looks good (rather than update all of the servers to Java Y at one time). My initial plan is for the other developers to remain on Java X until the migration has completed -- through production. My reasoning is that this avoids potential incompatibilities having to do with any of the newly added language features until our Java Y roll-out is complete. Then, once the other developer boxes are updated, they would be on the same Java Y version that all of our servers are running.
Does this sound like a reasonable plan? Is there anything in particular I need to be watching out for? I'm open to all suggestions, other than "just jump straight into Java Z"... that just isn't an option for now.
Your approach is fine but where are your test cases ?
I have migrated java web projects from Java 1.3 to Java 7. My past experience says that having good test cases [ and it coverage] is alwasy better as it gives confidence that app is working fine after java migration.
Make sure that you write test cases to achieve 100% [ if not 100% , go as closer as you can ] code coverage. Cobertura is the tool to find code coverage.
Oracle certified JPA Developer (1Z0-898),Oracle certified Java 8 Programmer I (1Z0-808), Oracle Java Web Service Developer (1z0-897), Oracle certified Java 7 Programmer, SCJA 1.0, SCJP 5.0, SCWCD 5.0, Oracle SQL Fundamentals I, CIW Certified Ecommerce specialist
Robert Eugene wrote:Does this sound like a reasonable plan?
Yup. And it's very good that you're thinking about it.
Another alternative that might be worth considering, especially if Java Y is a "stable" release: Work backwards - ie, change your production environment first and then work backwards through your staging systems.
It sounds counter-intuitive, but it can work very nicely if you already have test rigs in place specifically for testing version changes - ie, testing that the system still works the way it's supposed to on a new release ("friendly beta" users can also be a huge help for these sorts of situations) - the reason being that "production" is usually the most stable and "tested" part of your environment to begin with, so you don't have to worry about being bombarded with untested updates while you're doing your release testing.
And while that's going on, or even after the changeover, there's generally no problem with migrating from one of your other areas (on an earlier release) because Java versions are (with very few exceptions that I know of) backwards-compatible.
Also: assuming that the testing you do for your production environment is the most thorough, it paves the way for a smooth transition for your other areas; since you already know that most of the testing has been done at the "sharp end" - a form of quality assurance if you like.
A warning though: it's not the "standard" approach, so you may find that you have a bit of a learning curve.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop