Gestire più ambienti per più progetti su un'unica macchina?

Diamo un'occhiata all'ambiente di lavoro tipico di un'azienda di software house. Avete alcuni clienti che hanno ambienti diversi. Alcuni preferiscono MySQL, altri Postgres. Una versione della vostra applicazione ha bisogno di Java 11 e un altro Java 17. Frontend ha bisogno di npm 12 o 16 perché si usano versioni diverse di angolare. Infine, si ha un array tridimensionale che contiene le combinazioni di tutti i DB, le versioni del backend e del frontend. Sembra brutto, ma un giorno il vostro capo dice...

Radici di un ambiente multiverso

La situazione descritta sopra non è rara. La migrazione tra versioni di linguaggi o framework, gli aggiornamenti dei database o semplicemente le diverse esigenze dei clienti possono stravolgere tutte le configurazioni. Dovremmo avere una soluzione che ci aiuti a gestire questi cambiamenti, una soluzione che corrisponda ad alcuni presupposti e/o requisiti e/o obiettivi:

• facile da usare - singolo comando per modificare una configurazione o una versione,
• ricca biblioteca - dovrebbe supportare più tecnologie e "cose" (librerie, framework, applicazioni),
• estensibile - dovreste offrire la possibilità di aggiungere i vostri plugin.

In questo articolo mi concentrerò su tre aree. La prima è quella degli strumenti per Java e JVM. La seconda è quella degli strumenti di uso generale. La terza è come utilizzare docker per raggiungere i nostri obiettivi.

​

Sono un esperto di Java e lavoro su JVM

Quando si è un Sviluppatore Java o, più in generale, si lavora con Tecnologie JVMè possibile utilizzare SDKMAN!. È uno strumento molto bello e facile da usare che supporta molte librerie, framework e linguaggi.

Il processo di installazione di SDKMAN! È piuttosto semplice. È necessario eseguire:

curl -s "https://get.sdkman.io" | bash

e poi

source "$HOME/.sdkman/bin/sdkman-init.sh"

Ora è possibile gestire il proprio Java, Scala e Maven versioni.

Gestione delle versioni - esempio

In questo esempio, installeremo e aggiorneremo la versione di alcuni strumenti. Questo è solo un piccolo sottoinsieme degli strumenti disponibili.

Installazione

Supponiamo che il vostro nuovo progetto usi Java 17. Non avete alcun Java installata. Si vuole installarla e, inoltre, aggiungere uno strumento Maven Daemon per rendere le compilazioni più veloci. Quindi, è necessario installare anche Maven. Per farlo, è necessario eseguire tre semplici comandi:

$ sdk installare java 17-open

$ sdk installare maven 3.8.4

$ sdk installare mvnd 0.7.1

Al termine dell'installazione di ogni strumento, vi verrà chiesto di renderlo predefinito:

Si desidera che Java 17-open sia impostato come predefinito? (Y/n):

Questo è importante quando si installa una nuova versione di una libreria o di un linguaggio, perché SDKMAN! imposterà la versione predefinita come globale per tutti i terminali dell'utente corrente.

Controllo delle versioni e aggiornamento

Di tanto in tanto, SDKMAN! deve aggiornare gli indici. Durante questa operazione, si potrebbe ricevere un messaggio che segnala la presenza di nuove versioni degli strumenti utilizzati. È possibile verificare quali versioni sono disponibili digitando sdk ls. Per sdk ls maven:

Versioni di Maven disponibili

================================================================================

    3.8.6 3.3.3

    3.8.5 3.3.1

3.8.4 3.2.5

    3.8.3 3.2.3

    3.8.2 3.2.2

    3.8.1 3.2.1

    3.6.3 3.1.1

    3.6.2 3.1.0

    3.6.1 3.0.5

    3.6.0 3.0.4

    3.5.4

    3.5.3

    3.5.2

    3.5.0

    3.3.9



================================================================================

versione locale

attualmente in uso

================================================================================

Come abbiamo visto sopra, Maven ha una versione più recente di quella che utilizziamo. Lo stesso vale per mvnd (0.8.2) e Java (19-open). Aggiorniamo tutto. Per farlo, basta richiamare il comando install, ma in questo caso non usiamo uno specificatore di versione:

$ sdk installare maven

$ sdk installare mvnd

$ sdk installare java

Ma è successo qualcosa di sbagliato. Maven e mvnd hanno versioni corrette, ma Java ha una versione 17.0.5-tem. Questo perché la versione "più recente" dello strumento è controllata dal suo fornitore e non da SDKMAN! Chi è questo fornitore? Un venditore in SDKMAN! è qualcuno che può pubblicare una versione. Tuttavia, diciamo che alla fine installiamo 19-apertoe l'abbiamo reso predefinito, ma per qualche motivo dobbiamo usare 17-aperto.

Versioni locali e gestione delle versioni per terminale

​
Possiamo configurare un predefinito versione di uno strumento che è globale per tutti i progetti e i terminali. Ma quando abbiamo bisogno di una versione specifica, abbiamo due modi per farlo. Il primo è quello di utilizzare il file sdk usa ogni volta che si vuole usare una versione specifica di uno strumento nel terminale corrente. La seconda è preparare un elenco di versioni in un file .sdkmanrc che viene memorizzato nel progetto.

Mentre la prima opzione è destinata all'uso singolo, la seconda è stata progettata per lavorare con i team e condividere le configurazioni tra i vari gruppi. squadra membri.

Pro e contro di SDKMAN!

SDKMAN! è molto facile da usare e dispone di una ricca libreria di strumenti, framework e linguaggi supportati. Funziona su Linux, MacOS e Windows. D'altra parte, questo strumento è incentrato sulla JVM e richiede l'accettazione dell'autore come fornitore. Inoltre, la meccanica di .sdkmanrc è molto scarso e potrebbe rallentare notevolmente il processo di modifica delle directory.

Vorrei utilizzare molte altre lingue

Se avete bisogno di utilizzare molti linguaggi e strumenti, dovreste dare un'occhiata a asdf. Questo strumento si concentra su strumenti di "alto livello". Mentre in SDKMAN! si possono trovare molti strumenti specifici per Java, come Bpipe o Znai, asdf offre molti più strumenti, ma non così specifici. Naturalmente, alcuni di questi strumenti si sovrappongono, ad esempio Java, Tomcat o mvnd sono disponibili in entrambi.

Quando si desidera utilizzare asdfè necessario avere git e ricciolo installato. Dopodiché, è sufficiente:

clicca su https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2

e aggiungere queste righe in ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/completamenti/asdf.bash

Ora è possibile installare plugin e strumenti nelle versioni preferite.

Gestione basata su plugin

A differenza di SDKMAN! asdf utilizza i plugin per gestire gli strumenti. Quindi, prima di poter installare uno strumento, è necessario installare un plugin. Torniamo al nostro progetto di esempio e proviamo a configurare l'ambiente usando asadfsdf.

Per prima cosa, è necessario installare i plugin:

plugin asdf aggiungere java

plugin asdf aggiungere maven

plugin asdf aggiungere mvnd

Poi possiamo installare i nostri strumenti:

asdf installa java openjdk-17

asdf installa maven 3.8.4

asdf installare mvnd 0.7.1

E ancora una volta, a differenza di SDKMAN! asdf non cambia nulla nel nostro ambiente. Quando proviamo a usare java, riceviamo un messaggio di errore del tipo:

Non è stata impostata alcuna versione per il comando Java

Considerare l'aggiunta di una delle seguenti versioni nel file di configurazione in ~/.tool-versions

java openjdk-17

Dobbiamo creare il file .versioni degli strumenti nella home directory per gestire le versioni predefinite.

Versioni locali e globali

Aggiornamento delle versioni del software con asdf è piuttosto semplice. Basta installare una nuova versione. Poiché questo processo non influisce sull'ambiente, possiamo farlo in qualsiasi momento e in qualsiasi punto del file system. Quando vogliamo usare una versione specifica di un software, dobbiamo creare nella cartella del progetto una cartella .versioni degli strumenti che possono essere condivisi tra i membri del team. Ricordate che è necessario garantire che tutti i membri del team abbiano asdf e i plugin installati. L'elenco dei plugin che si possono trovare qui.

Conflitti di versione

asdf non supporta solo linguaggi di programmazione, framework e strumenti come vim o kubernetess. Supporta anche i database. In questo caso, potremmo installare più versioni di Postgres, ad esempio, ma solo un'istanza potrebbe essere eseguita. Questo perché asdf esegue i comandi direttamente sul sistema operativo senza alcun livello di separazione. Questo porta a problemi come "porta già in uso" e conflitti sulle risorse.

Pro e contro

asdf è un ottimo strumento se si desidera lavorare in un ambiente poliglotta. Supporta molti strumenti, linguaggi e framework. L'architettura basata su plugin rende molto semplice l'estensione. Tuttavia, alcuni degli strumenti presenti nella libreria richiedono un lavoro supplementare durante l'installazione per fornire tutte le dipendenze necessarie. asdf non funziona su Windows, nemmeno su WSL.

Ultimo ma non meno importante: Docker

Quando parlo del conflitto delle porte, molti di voi conoscono la soluzione.

Docker potrebbe aiutarci in alcuni casi. Ne parlo per dovere, perché questo strumento è così grande e complesso che non possiamo parlarne in un solo articolo.

Insieme a Docker, dovremmo usare un file docker-compose che ci dà la possibilità di coordinare ambienti multi-contenitore.

Pro e contro di Docker

Docker ci aiuta a gestire strumenti che necessitano di risorse specifiche, come porte o file. Separa le istanze in contenitori e ci dà il pieno controllo su di esse. Tuttavia, Docker è uno strumento che introduce molta complessità nel nostro ambiente di lavoro e in alcuni casi può essere problematico. Uno di questi casi di utilizzo di Docker in un test è descritto in uno dei nostri precedenti articolo.

Riassumendo

So che non ho descritto tutti gli strumenti che possono essere utilizzati per gestire le versioni degli strumenti. Ce ne sono molti altri, come jEnv che potrebbe sostituire SDKMAN,

o NVM che possiamo usare per gestire npm o RVM per Ruby. Mi sono concentrato sugli strumenti che ho "testato sul campo di battaglia" e che posso consigliare a chiunque.