S'assurer que vos applications restent à jour est important et difficile. Ce document décrit les étapes de base permettant aux développeurs Java de se familiariser avec les pratiques DevOps. Il ne s'agit en aucun cas d'une liste exhaustive. La plupart de ces idées sont issues des études de recherche et d'évaluation DevOps de DORA, qui fournissent une présentation plus complète des bonnes pratiques. Autres sources : Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Accélérez : la science du Lean Software et du DevOps : créer et faire évoluer des organisations technologiques très performantes par Nicole Forsgren, PhD, Jez Humble et Gene Kim, et Software Engineering at Google (Présentation de l'ingénierie logicielle chez Google), réalisée par Titus Winters, Tom Manshreck et Hyrum Wright.
Avant de lire cette page, il est recommandé de lire la section Configurer un environnement de développement Java.
Les besoins de chaque organisation de développement sont uniques, mais un système de base peut être construit à l'aide de l'une des piles technologiques suivantes :
| Exemple de pile technologique 1 | Exemple de pile technologique 2 |
|---|---|
|
|
Un système simple conçu avec ces composants peut vous permettre d'améliorer la qualité et le temps de cycle. Cela peut également vous permettre de maintenir facilement votre code à jour avec les dernières corrections de bugs et mises à jour de sécurité.
Contrôle des versions
Une étude (Page 17 ,Page 14 ,Page 31 etPage 60 ) a trouvé quele contrôle des versions pour le code source combiné à l'automatisation et aux tests améliore la qualité et apporte de nombreux autres avantages.
- Cloud Source Repositories [Guide de démarrage rapide] propose un workflow Git gratuit pour votre code source.
- Artifact Registry [Conteneurs ][Packages Java] est parfait pour conserver les artefacts Java que vous créez.
GitHub, Gitlab et Bitbucket sont également de bons emplacements pour votre code source.
Tests automatiques
Les tests continus peuvent être essentiels à votre réussite en utilisant la plupart de ces techniques. Pour en savoir plus sur les bonnes pratiques en matière de test, consultez le chapitre sur les tests de fiabilité dans le livre sur l'ingénierie SRE et le blog Google Testing.
Les développeurs Java sont principalement concernés par les tests unitaires automatisés et les tests d'intégration. JUnit, Tests avec Spring, Apache Maven Surefire et Tests avec Gradle pour Java sont des ressources utiles pour les développeurs Java.
Intégration continue/Automatisation du déploiement
L'intégration continue et l'automatisation des déploiements utilisent des tâches DevOps modernes. Développer, tester et déployer
- Cloud Build [Guides de démarrage rapide] [Spécifique à Java] [Déploiement] [Déclencheur] fournit un système de compilation facile à utiliser gratuit (120 minutes de compilation/jour) ou abordable pouvant être facilement personnalisé pour la plupart des tâches.
- Tekton est un projet Open Source qui vous permet d'adapter facilement les idées Cloud Build à vos systèmes.
- Spinnaker est une plate-forme de livraison continue multicloud Open Source qui vous aide à publier des modifications logicielles rapidement et avec une grande fiabilité. Elle vous aide à gérer le processus de lancement et de rollback des systèmes logiciels complexes.
- GitHub Actions est une solution tierce qui vous permet de facilement configurer des tests et de les exécuter sur GitHub.
- Il existe également de nombreuses autres solutions telles que GitLab, Circle CI et Travis CI.
Bibliothèques clientes Google Cloud
Il existe de nombreuses façons d'utiliser les services Google, mais nous vous recommandons de suivre les instructions de la page Bibliothèques clientes Cloud. Pour Java, la bibliothèque Libraries-BOM permet de vous assurer que vous utilisez des versions compatibles de chaque artefact.
Si vous choisissez d'utiliser vos propres versions des bibliothèques clientes, il est possible qu'un artefact incompatible soit sélectionné. C'est ce qu'on appelle le problème de dépendance au diamant. Si vous devez toujours choisir vos bibliothèques individuelles, mettez-les à jour une par une et vérifiez si la mise à jour a introduit une erreur. Les dernières versions sont toujours répertoriées sur cette page ou peuvent être trouvées en effectuant une recherche sur Maven-Central.
Maintenir les dépendances à jour
Pour vous protéger contre les activités malveillantes, il est essentiel de maintenir vos dépendances à jour. De nombreux outils tiers vous aident à y parvenir :
Lorsqu'ils sont correctement configurés, ces outils vous aident à maintenir vos dépendances à jour. Lorsque vous combinez les tests automatisés et l'intégration continue / le déploiement continu, le flux se présente comme suit :
- L'automatisation des dépendances propose une modification de votre contrôle de source.
- Le système de compilation continue compile et teste la modification.
- Une personne examine la proposition et, si elle est acceptable, accepte la modification, éventuellement avec d'autres modifications.
- Une fois les modifications acceptées, une proposition est envoyée au système de livraison continue afin de publier le code en production. (ou votre processus personnalisé est suivi.)
Utiliser un environnement d'exécution Java (JRE) compatible
Le JRE, un sous-ensemble du kit de développement Java, se trouve au-dessus de votre système d'exploitation, et fournit le logiciel et les ressources nécessaires pour exécuter une application Java. La plupart des utilisateurs préfèrent utiliser la dernière version LTS en production pour pouvoir accéder aux mises à jour, à la sécurité et aux corrections de bugs. Il est généralement possible de passer à un JRE plus récent, même si votre code est compilé sur un JDK antérieur.
Si vous travaillez avec plusieurs versions de JDK, SDKMAN! peut vous aider à utiliser et à gérer différentes versions de JDK.
Utiliser des conteneurs (Google Kubernetes Engine, Cloud Run, clusters Anthos)
Si vous utilisez des conteneurs Docker avec RenovateBot ou DependaBot, le bot propose régulièrement des mises à jour de votre JRE et de votre JDK. Veillez à conserver le JDK et le JRE sur la même version.
Dans la plupart des cas, nous vous recommandons d'utiliser Jib pour conteneuriser vos applications Java.
Si vous mettez à jour manuellement votre fichier Dockerfile, il vous suffit de remplacer le JRE par le plus récent et de le recompiler.
Utiliser Compute Engine
Ces applications sont généralement très spécifiques. Nous vous recommandons d'utiliser un script de démarrage. Pour effectuer la mise à niveau, vous devez mettre à jour le script.
Environnement flexible App Engine
Compatible avec Java 8 uniquement.
Environnement standard App Engine
Consultez Migrer votre application App Engine de Java 8 vers Java 11.
Utiliser une version LTS du kit de développement Java
Le JDK est un ensemble d'outils permettant de développer des applications Java. Les nouvelles fonctionnalités de langage sont liées à un JDK particulier. Nous vous recommandons d'épingler votre utilisation à un JDK doté d'une version avec support à long terme (LTS), en effectuant une mise à niveau vers la version LTS suivante si nécessaire. Nous vous recommandons d'utiliser la dernière version mineure de la version LTS majeure épinglée.
La plupart des utilisateurs souhaitent synchroniser le JDK et le JRE. Parfois, ce n'est pas possible (par exemple lorsque le JDK n'est plus accepté) et vous devez compiler avec un JDK plus récent et l'exécuter sur un JRE antérieur.
Pour effectuer cette opération avec Maven, procédez comme suit :
Définissez le niveau de langue dans lequel vous souhaitez coder et le JRE cible. Mettez à jour votre fichier pom.xml comme suit (pour Java 8) : xml
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
Pour passer à Java 11, vous devez le remplacer par :
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
Si vous utilisez Gradle, mettez à jour votre fichier build.gradle pour Java 8 avec la commande suivante :
compileJava {
sourceCompatibility = 1.8
targetCompatibility = 1.8
}
Ou pour Java 11 :
compileJava {
sourceCompatibility = 11
targetCompatibility = 11
}
Notez que, pour Java 8 et les versions antérieures, le préfixe 1. (1.7 pour Java 7, 1.8 pour Java 8) a été supprimé après Java 8.