～～ For engineers who have not been able to get over the crazy development style ～～
The JDK feature release cycle is now a 6-month cycle. Unless you have an LTS version or paid support, a new version will end support for the previous version. It's easy to imagine a new version of the JDK being released in the middle of a long development span and should be considered in advance. It is possible to proceed with the development with a fixed version during the development period, but it is required to be the latest JDK version at the time of release of the developed software and C / O of the system. Therefore, it is essential to develop a development infrastructure that allows regression testing to be performed cyclically.
When it comes to Java 11, APIs that were previously marked as Deprecated but were still available may be removed. There is also a need to be able to quickly catch up on the impact of these changes.
As of Java 9, there are changes such as Project Jigsaw, and APIs that have already been deleted and internal implementation classes that could be referenced so far There are changes such as being unable to refer to it. Let's prepare for the migration to Java 11 by building and checking the operation with Java 9 at the time when Java 9 is available. It has less impact when migrating to Java 11.
Java 11 changes include JEP 320, which removes Java EE, CORBA, etc. that have been deprecated in Java 9. When considering migrating from Java 8, you will need to rewrite to these alternative external libraries. In Java EE, it will be transferred to Jakarta EE, so it will be necessary to rewrite the package name and so on.
--java.xml.ws (JAX-WS, related technology SAAJ and Web service metadata)
At the same time, it is necessary to prepare for the version upgrade of the dependent external library. It is natural to prepare for the security patch release, but it is easy to imagine that these external libraries will be upgraded as the JDK is upgraded. Again, there is a need for regression testing to be easy to perform.
For version control of dependent libraries, use a package manager or a build tool such as Maven or Gradle with such features.
Digesting test cases one by one with the human hand is no longer obsolete. The only way to perform regression testing cyclically and easily is to automate it. It is not realistic to build all the source code and execute all the test code on the development work PC, so prepare a dedicated server.
However, it costs more to measure coverage and write reusable test code to ensure quality. (Never have to be TDD or Test-First.) Needless to say, when testing code that affects DB etc., use a mock or write test code that can be cleaned up properly at the end of the test.
There are some parts that are difficult to automate in system development with screens. Here, for the purpose of "quickly catching up the influence of the version upgrade of JDK and dependent libraries", it would be good if "it works as usual" can be tested.
Introduce CI tools such as Jenkins and Travis CI to automate source code builds, test code execution, and more. Set to build as soon as the source code changes are reflected. It will be executed behind the scenes of development work such as performing static inspection, executing test code, and measuring coverage.
In addition, by making good use of virtualization technologies such as cloud (IaaS, PaaS, SaaS, etc.), SDI (Software Defined Infrastructure), and Docker, it is possible to quickly build a verification environment that reflects changes in development resources. is.
I don't think it's possible that you don't version control your development resources these days. What you couldn't do with SVN can be done with Git. What you can do with SVN is more convenient with Git. It's easy to imagine that version control and revision control will be complicated. Get started with Git servers with Pull-Request capabilities, such as GitHub and GitBucket, right away. Especially if configuration management cannot be rigorous.
Consider choosing one of the following:
--Extended with paid support for Oracle JDK 8 --Migrate to Oracle JDK 11 with paid support from Oracle --Migrate to free OpenJDK 11 (However, if it does not become LTS, you need to make a renewal plan in a 6-month cycle)
According to the schedule in here, general use will be available on 9/25. It's about to come ... Let's prepare a perfect system and wait with excitement.
It seems that the Release Candidate version is available in the Fedora 27 Updates repository.
Recommended Posts