～～ Für Ingenieure, die den verrückten Entwicklungsstil nicht überwinden konnten ～～
Der JDK-Feature-Release-Zyklus ist jetzt ein 6-Monats-Zyklus. Sofern Sie nicht über eine LTS-Version oder kostenpflichtigen Support verfügen, wird der Support für die vorherige Version durch eine neue Version beendet. Es ist leicht vorstellbar, dass eine neue Version des JDK mitten in einer langen Entwicklungsspanne veröffentlicht wird und im Voraus in Betracht gezogen werden sollte. Es ist möglich, während des Entwicklungszeitraums mit einer festen Version mit der Entwicklung fortzufahren, es muss jedoch zum Zeitpunkt der Veröffentlichung der entwickelten Software und der C / O des Systems die neueste JDK-Version sein. Daher ist es wichtig, eine Entwicklungsinfrastruktur zu entwickeln, mit der Regressionstests zyklisch durchgeführt werden können.
Wenn es um Java 11 geht, können APIs entfernt werden, die zuvor als veraltet markiert waren, aber noch verfügbar waren. Es ist auch notwendig, die Auswirkungen dieser Änderungen schnell nachholen zu können.
Ab Java 9 gab es Änderungen wie Project Jigsaw, bereits gelöschte APIs und interne Implementierungsklassen, auf die bisher verwiesen werden konnte Es gibt Änderungen, z. B. dass Sie nicht darauf verweisen können. Bereiten wir uns auf den Übergang zu Java 11 vor, indem wir den Vorgang mit Java 9 zu dem Zeitpunkt erstellen und überprüfen, zu dem Java 9 verfügbar ist. Es hat weniger Auswirkungen bei der Migration auf Java 11.
Zu den Java 11-Änderungen gehört JEP 320, mit dem in Java 9 veraltete Java EE, CORBA usw. entfernt werden. Wenn Sie eine Migration von Java 8 in Betracht ziehen, müssen Sie diese alternativen externen Bibliotheken neu schreiben. In Java EE wird es an Jakarta EE übertragen, sodass wir Maßnahmen ergreifen, z. B. den Paketnamen nach Bedarf neu schreiben.
--java.xml.ws (JAX-WS, verwandte Technologie SAAJ und Webdienst-Metadaten)
Gleichzeitig muss das Versions-Upgrade der abhängigen externen Bibliothek vorbereitet werden. Es ist natürlich, sich auf die Veröffentlichung von Sicherheitspatches vorzubereiten, aber es ist leicht vorstellbar, dass diese externen Bibliotheken aktualisiert werden, wenn das JDK aktualisiert wird. Auch hier müssen Regressionstests einfach durchgeführt werden.
Verwenden Sie den Paket-Manager und erstellen Sie Tools wie Maven und Gradle mit diesen Funktionen für versionierte Bibliotheken.
Es ist nicht mehr veraltet, Testfälle einzeln mit menschlichen Händen zu verdauen. Die einzige Möglichkeit, Regressionstests zyklisch und einfach durchzuführen, besteht darin, sie zu automatisieren. Es ist nicht realistisch, den gesamten Quellcode zu erstellen und den gesamten Testcode auf dem Entwicklungsarbeits-PC auszuführen. Bereiten Sie daher einen dedizierten Server vor.
Es kostet jedoch mehr, die Abdeckung zu messen und wiederverwendbaren Testcode zu schreiben, um die Qualität sicherzustellen. (Muss niemals TDD oder Test-First sein.) Verwenden Sie beim Testen von Code, der sich auf die Datenbank usw. auswirkt, einen Schein- oder Testcode, der am Ende des Tests ordnungsgemäß bereinigt werden kann.
Es gibt einige Teile, die bei der Systementwicklung mit Bildschirmen schwer zu automatisieren sind. Um "den Einfluss des Versions-Upgrades von JDK und abhängigen Bibliotheken schnell nachzuholen", wäre es hier gut, wenn "es funktioniert wie gewohnt" getestet werden kann.
Führen Sie CI-Tools wie Jenkins und Travis CI ein, um die Erstellung von Quellcode, die Ausführung von Testcode und mehr zu automatisieren. Stellen Sie den Build ein, sobald die Änderungen des Quellcodes berücksichtigt werden. Es wird hinter den Kulissen der Entwicklungsarbeit durchgeführt, z. B. statische Inspektion durchführen, Testcode ausführen und Abdeckung messen.
Durch die gute Nutzung von Virtualisierungstechnologien wie Cloud (IaaS, PaaS, SaaS usw.), SDI (Software Defined Infrastructure) und Docker ist es außerdem möglich, schnell eine Verifizierungsumgebung zu erstellen, die Änderungen der Entwicklungsressourcen widerspiegelt. ist.
Ich denke nicht, dass es heutzutage möglich ist, dass wir die Version der Entwicklungsressourcen nicht verwalten. Was Sie mit SVN nicht machen konnten, können Sie mit Git machen. Was Sie mit SVN tun können, ist mit Git bequemer. Es ist leicht vorstellbar, dass das Versionsmanagement und das Revisionsmanagement kompliziert sein werden. Beginnen Sie sofort mit Git-Servern mit Pull-Request-Funktionen wie GitHub und GitBucket. Insbesondere, wenn das Konfigurationsmanagement nicht streng ist.
Wählen Sie eine der folgenden Optionen:
Gemäß dem Zeitplan in hier wird die allgemeine Verwendung am 25. September verfügbar sein. Es kommt gleich ... Bereiten wir ein perfektes System vor und warten gespannt.
Es scheint, dass eine Release Candidate-Version im Updates-Repository von Fedora 27 bereitgestellt wird.
Recommended Posts