～～ Pour les ingénieurs qui n'ont pas réussi à surmonter le style de développement fou ～～
Le cycle de publication des fonctionnalités JDK est désormais un cycle de 6 mois. Sauf si vous disposez d'une version LTS ou d'un support payant, une nouvelle version mettra fin au support de la version précédente. Il est facile d'imaginer qu'une nouvelle version du JDK sortira au milieu d'une longue période de développement et devrait être envisagée à l'avance. Il est possible de procéder au développement avec une version fixe pendant la période de développement, mais il est nécessaire qu'il s'agisse de la dernière version de JDK au moment de la publication du logiciel développé et du C / O du système. Par conséquent, il est essentiel de développer une infrastructure de développement permettant d'effectuer des tests de régression de manière cyclique.
En ce qui concerne Java 11, les API qui étaient auparavant marquées comme obsolètes mais qui étaient toujours disponibles peuvent être supprimées. Il est également nécessaire de pouvoir rattraper rapidement l'impact de ces changements.
À partir de Java 9, il y a eu des changements tels que Project Jigsaw, et des API qui ont déjà été supprimées et des classes d'implémentation internes pouvant être référencées jusqu'à présent Il y a des changements tels que l'impossibilité de s'y référer. Préparons la migration vers Java 11 en construisant et en vérifiant le fonctionnement avec Java 9 au moment où Java 9 est disponible. Il a moins d'impact lors de la migration vers Java 11.
Les modifications de Java 11 incluent JEP 320, qui supprime Java EE, CORBA, etc. qui ont été déconseillés dans Java 9. Lorsque vous envisagez de migrer à partir de Java 8, vous devrez réécrire dans ces bibliothèques externes alternatives. Dans Java EE, il sera transféré à Jakarta EE, nous prendrons donc des mesures telles que la réécriture du nom du package si nécessaire.
--java.xml.ws (JAX-WS, technologie associée SAAJ et métadonnées de service Web)
Dans le même temps, il est nécessaire de préparer la mise à niveau de la version de la bibliothèque externe dépendante. Il est naturel de se préparer à la publication des correctifs de sécurité, mais il est facile d'imaginer que ces bibliothèques externes seront mises à niveau au fur et à mesure de la mise à niveau du JDK. Encore une fois, il est nécessaire que les tests de régression soient faciles à réaliser.
Utilisez Package Manager et créez des outils tels que Maven et Gradle avec ces fonctionnalités pour les bibliothèques dépendant de la version.
La digestion de chaque cas de test avec des mains humaines n'est plus obsolète. La seule façon d'effectuer des tests de régression de manière cyclique et facile est de les automatiser. Il n'est pas réaliste de construire tout le code source et d'exécuter tout le code de test sur le PC de développement, alors préparez un serveur dédié.
Cependant, il coûte plus cher de mesurer la couverture et d'écrire du code de test réutilisable pour garantir la qualité. (Ne jamais avoir à être TDD ou Test-First.) Inutile de dire que lorsque vous testez du code qui affecte la base de données, etc., utilisez un code de test simulé ou écrivez qui peut être nettoyé correctement à la fin du test.
Certaines parties sont difficiles à automatiser dans le développement de système avec des écrans. Ici, dans le but de "rattraper rapidement l'impact de la mise à niveau du JDK et des bibliothèques dépendantes", il serait bon que "cela fonctionne comme avant" puisse être testé.
Introduisez des outils CI tels que Jenkins et Travis CI pour automatiser la création de code source, tester l'exécution du code, etc. Défini pour construire dès que les modifications du code source sont reflétées. Il sera effectué dans les coulisses des travaux de développement tels que l'inspection statique, l'exécution du code de test et la mesure de la couverture.
De plus, en faisant bon usage des technologies de virtualisation telles que le cloud (IaaS, PaaS, SaaS, etc.), SDI (Software Defined Infrastructure) et Docker, il est possible de créer rapidement un environnement de vérification qui reflète les changements dans les ressources de développement. est.
Je ne pense pas qu'il soit possible que nous ne gérions pas la version des ressources de développement de nos jours. Ce que vous ne pouvez pas faire avec SVN peut être fait avec Git. Ce que vous pouvez faire avec SVN est plus pratique avec Git. Il est facile d'imaginer que la gestion des versions et la gestion des révisions seront compliquées. Commencez tout de suite avec les serveurs Git avec des fonctionnalités Pull-Request, telles que GitHub et GitBucket. Surtout si la gestion de la configuration n'est pas rigoureuse.
Pensez à choisir l'un des éléments suivants:
Selon le calendrier en ici, l'utilisation générale sera disponible le 25/09. Il est sur le point de venir ... Préparons un système parfait et attendons avec enthousiasme.
Il semble qu'une version release candidate soit fournie dans le référentiel des mises à jour de Fedora 27.
Recommended Posts