Best practice di Java

Mantenere aggiornate le applicazioni è diventato importante e difficile. Questo documento fornisce alcuni passaggi di base per aiutare gli sviluppatori Java a iniziare a utilizzare le pratiche DevOps. Non si tratta in alcun modo di un elenco esaustivo. La maggior parte di queste idee proviene dagli studi di ricerca e valutazione DevOps di DORA, che forniscono una panoramica più completa delle best practice. Altre fonti includono: Accelera: la scienza del software Lean e DevOps: creazione e scalabilità delle organizzazioni ad alte prestazioni di Nicole Forsgren PhD, Jez Dangerously e Gene Kim; e Software Engineering at Google a cura di Titus Winters, Tom Manshreck e Hyrum Wright.

Prima di leggere questa pagina, ti consigliamo di leggere l'articolo Configurazione di un ambiente di sviluppo Java.

Le esigenze di ogni organizzazione di sviluppo sono uniche, ma un sistema di base potrebbe essere costruito utilizzando uno dei seguenti stack tecnici:

Esempio di stack tecnico 1 Esempio di stack tecnico 2
  • Cloud Source Repositories, GitHub o Bitbucket per il codice sorgente.
  • Whitesource RenovateBot per mantenere aggiornati artefatti e librerie.
  • Cloud Build per test unità / pre-invio
  • Cloud Build per il test di integrazione
  • Cloud Build per il deployment
  • GitHub per il codice sorgente.
  • GitHub Dependabot per mantenere aggiornati artefatti e librerie.
  • Azioni GitHub per il test pre-invio
  • Azioni di GitHub per i test di integrazione
  • Azioni di GitHub per il deployment

Un sistema semplice creato con questi componenti può migliorare la qualità e il tempo di ciclo. Puoi anche tenere facilmente aggiornato il codice con le correzioni di bug e gli aggiornamenti di sicurezza più recenti.

Controllo delle versioni

La ricerca (pagina 17, pagina 14, pagina 31 e pagina 60) ha rilevato che il controllo della versione per il codice sorgente combinato con l'automazione e i test prevede una qualità migliorata e molti altri vantaggi.

GitHub, Gitlab e Bitbucket sono anche un'ottima fonte di codice sorgente.

Test automatici

Un test continuo può essere fondamentale per il tuo successo utilizzando la maggior parte di queste tecniche. Per ulteriori considerazioni sulle best practice per i test, consulta il test dell'affidabilità di Capitolo sulla libro libro SRE e il blog di Google Test.

Gli sviluppatori Java si occupano principalmente di test automatici delle unità e di test di integrazione. JUnit, Testing with Spring, Apache Maven Surefire e Gradle Java test sono risorse utili per gli sviluppatori Java.

Integrazione continua / automazione del deployment

L'integrazione continua e l'automazione del deployment alimentano i moderni job DevOps. Creazione, test e deployment.

  • Cloud Build [Quickstart] [specifico di Java] [Deployment] [Trigger] offre un sistema di compilazione gratuito (120 minuti di build al giorno) o un costo facile da utilizzare, personalizzabile per la maggior parte dei job.
  • Tekton è un progetto open source che ti consente di adattare facilmente le idee di Cloud Build ai tuoi sistemi.
  • Spinnaker è una piattaforma di distribuzione continua open source e multi-cloud che ti aiuta a rilasciare modifiche del software con velocità e affidabilità elevate. che ti aiuta a gestire il processo di rilascio e rollback di sistemi software complessi.
  • Azioni di GitHub è una soluzione di terze parti che ti consente di configurare facilmente i test e di eseguirli su GitHub.
  • Esistono anche molte altre soluzioni quali Gitlab, Circle CI e Travis CI.

Librerie client di Cloud

Esistono molti modi per utilizzare i servizi Google, ma il modo migliore è quello di seguire le istruzioni riportate nella pagina delle librerie client di Cloud. Per Java, la Librerie-BOM può aiutarti a garantire che stai utilizzando versioni compatibili di ogni artefatto.

Se scegli di scegliere le tue versioni delle librerie client, è possibile che venga selezionato un artefatto non compatibile. Questa situazione è nota come il problema della dipendenza diamante. Se devi ancora selezionare le singole librerie, aggiornale una alla volta e verifica se l'aggiornamento ha introdotto un errore. Le versioni più recenti sono sempre elencate in questa pagina oppure puoi cercarle tramite Maven-Central.

Mantieni le dipendenze attuali

Per proteggerti da utenti malintenzionati, è fondamentale tenere aggiornate le tue dipendenze. Esistono molti strumenti di terze parti che possono aiutarti a farlo:

Questi strumenti, se configurati correttamente, ti aiutano a mantenere aggiornate le tue dipendenze. Quando combini test automatici e integrazione continua/deployment continuo il flusso diventa:

  • L'automazione delle dipendenze propone una modifica al controllo del codice sorgente.
  • Il sistema di compilazione continua crea e verifica la modifica.
  • Una persona esamina la proposta e, se accettabile, la accetta, eventualmente insieme ad altre modifiche.
  • Dopo aver accettato le modifiche, viene inviata una proposta al sistema di distribuzione continua per rilasciare il codice in produzione. (oppure il tuo processo personalizzato è seguito).

Utilizza Java Java Environment (JRE) supportato

JRE, un sottoinsieme del Java Development Kit, si trova sul tuo sistema operativo e fornisce il software e le risorse necessarie per eseguire un'applicazione Java. La maggior parte degli utenti preferisce utilizzare la versione LTS più recente in produzione, in modo da avere accesso ad aggiornamenti, sicurezza e correzioni di bug. In genere è possibile eseguire l'aggiornamento a un JRE successivo anche se il codice viene compilato con un JDK precedente.

Se lavori con più versioni JDK, SDKMAN! può aiutarti a utilizzare e gestire diverse versioni JDK.

Utilizzo dei container (Google Kubernetes Engine, Cloud Run, cluster Anthos)

Se utilizzi container Docker con RenovateBot o DependaBot, il bot propone periodicamente aggiornamenti alla versione JRE e alla versione JDK e vuoi mantenere la versione JDK e JRE sulla stessa versione.

Ti consigliamo di utilizzare Jib per containerizzare le tue applicazioni Java nella maggior parte dei casi.

Se aggiorni manualmente il Dockerfile, cambia il JRE in ultimo e riesegui la build.

Utilizzo di Compute Engine

Questo approccio tende a essere molto specifico per le applicazioni. Consigliamo di utilizzare uno script di avvio. Per eseguire l'upgrade, devi aggiornare lo script.

Ambiente flessibile di App Engine

Supporta solo Java 8.

Standard App Engine

Consulta la sezione Migrazione dell'app App Engine da Java 8 a Java 11.

Usare una versione LTS del Java Development Kit

JDK è un insieme di strumenti per lo sviluppo di applicazioni Java. Le nuove funzionalità lingue sono legate a un JDK specifico. Ti consigliamo di limitare l'utilizzo a un JDK con assistenza a lungo termine (LTS), eseguendo l'upgrade alla versione LTS successiva quando è appropriata per la tua applicazione. Ti consigliamo di utilizzare la release secondaria più recente della release LTS principale bloccata.

La maggior parte degli utenti vorrà mantenere sincronizzati JDK e JRE. A volte questo non è possibile (ad esempio quando il JDK non è più supportato) e devi completarlo con un JDK successivo ed eseguirlo su un JRE precedente.

Per farlo con Maven:

Imposta il livello di lingua in cui vuoi programmare il codice e la JRE di destinazione. Aggiorna il pom.xmlfile come segue (per Java 8): xml <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target>

Per effettuare l'aggiornamento a Java 11, devi cambiarlo in:

    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

Se utilizzi Gradle, aggiorna il file build.gradle per Java 8 con:

compileJava {
  sourceCompatibility = 1.8
  targetCompatibility = 1.8
}

Oppure per Java 11:

compileJava {
  sourceCompatibility = 11
  targetCompatibility = 11
}

Tieni presente che per Java 8 e versioni precedenti, le versioni avevano un prefisso 1. (1.7 per Java 7, 1.8 per Java 8) eliminato dopo Java 8.