Käsitteletkö useita ympäristöjä useita projekteja varten yhdellä koneella?

Tarkastellaanpa tyypillistä työympäristöä seuraavassa yrityksessä ohjelmistotalo. Sinulla on muutama asiakas, joilla on erilaiset ympäristöt. Jotkut suosivat MySQL:ää, toiset Postgresiä. Yksi sovelluksesi versio tarvitsee Java 11 ja toinen Java 17. Frontend tarvitsee npm 12:n tai 16:n, koska käytät eri versioita ohjelmistosta kulmikas. Lopuksi sinulla on kolmiulotteinen array, joka sisältää kaikkien tietokantojesi, backend- ja frontend-versioiden yhdistelmät. Kuulostaa pahalta, mutta eräänä päivänä pomosi sanoo...

Moniavaruusympäristön juuret

Edellä kuvattu tilanne ei ole mitenkään harvinainen. Siirtyminen kieli- tai kehysversioiden välillä, tietokantojen päivitykset tai yksinkertaisesti asiakkailta tulevat erilaiset vaatimukset voivat kääntää kaikki kokoonpanot ylösalaisin. Meillä pitäisi olla ratkaisu, joka auttaa meitä hallitsemaan näitä muutoksia ja joka vastaa muutamia oletuksia ja/tai vaatimuksia ja/tai tavoitteita:

• helppokäyttöinen - yksi komento kokoonpanon tai version muuttamiseksi,
• rikas kirjasto - pitäisi tukea useita teknologioita ja "asioita" (kirjastoja, kehyksiä, sovelluksia),
• laajennettavissa - sinun pitäisi tarjota mahdollisuus lisätä liitännäisiäsi.

Tässä artikkelissa keskityn kolmeen alueeseen. Ensimmäinen on Javan ja JVM:n työkalut. Toinen on yleiskäyttöiset työkalut. Kolmas on se, miten voimme käyttää telakkaa tavoitteidemme saavuttamiseksi.

​

Olen Java ja työskentelen JVM:n parissa.

Kun olet Java-kehittäjä tai, yleisemmin, työskentelet JVM-tekniikat, niin voit käyttää SDKMAN!. Tämä on erittäin mukava ja helppokäyttöinen työkalu, joka tukee monia kirjastoja, kehyksiä ja kieliä.

Asennusprosessi SDKMAN! Se on melko yksinkertaista. Sinun täytyy ajaa:

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

ja sitten

lähde "$HOME/.sdkman/bin/sdkman-init.sh"

Nyt voit hallita Java, Scala ja Maven versiot.

Versioiden hallinta - esimerkki

Tässä esimerkissä asennamme ja päivitämme muutaman työkalun version. Tämä on vain pieni osa käytettävissä olevista työkaluista.

Asennus

Oletetaan, että uusi projekti käyttää Java 17. Sinulla ei ole mitään Java asennettu versio. Haluat asentaa sen ja lisäksi lisätä Maven Daemon -työkalun, jotta rakentaminen nopeutuisi. Sinun on siis asennettava myös Maven. Sitä varten sinun on suoritettava kolme yksinkertaista komentoa:

$ sdk install java 17-open

$ sdk asenna maven 3.8.4

$ sdk asentaa mvnd 0.7.1.

Kunkin työkalun asennuksen lopussa sinulta kysytään, haluatko tehdä siitä oletusarvon:

Tahdotko, että Java 17-open asetetaan oletusarvoksi? (Y/n):

Tämä on tärkeää, kun asennat uuden version kirjastosta tai kielestä, koska SDKMAN! asettaa tämän oletusversion globaaliksi kaikille nykyisen käyttäjän päätelaitteille.

Versioiden tarkistaminen ja päivittäminen

SDKMAN! joutuu aika ajoin päivittämään indeksit. Tällöin saatat saada viestin, että käyttämiesi työkalujen versiot ovat muuttuneet. Voimme tarkistaa, mitkä versiot ovat saatavilla kirjoittamalla seuraavalla tavalla sdk ls. Osoitteessa sdk ls maven:

Saatavilla olevat Maven-versiot

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

    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



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

paikallinen versio

tällä hetkellä käytössä

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

Kuten yllä näkyy, Mavenilla on uudempi versio kuin käyttämämme versio. Sama koskee myös mvnd (0.8.2) ja Java (19-open). Päivitetään kaikki. Sitä varten meidän tarvitsee vain kutsua install-komentoa, mutta tällä kertaa emme käytä version määrittelyä:

$ sdk asentaa mavenin

$ sdk install mvnd

$ sdk asenna java

Mutta jotain väärää tapahtui. Maven ja mvnd on oikeat versiot, mutta Java on versio 17.0.5-tem. Tämä johtuu siitä, että työkalun "uusinta" versiota valvoo sen myyjä, ei paikallinen SDKMAN.Kuka tämä myyjä on? SDKMAN!:ssa myyjä on joku, joka voi julkaista version. Sanotaan kuitenkin, että asennamme lopulta version. 19-avoin, ja teimme siitä oletusarvon, mutta jostain syystä meidän on käytettävä 17-avoin.

Paikalliset versiot ja terminaalikohtainen versionhallinta

​
Voimme määrittää oletus versio työkalusta, joka on maailmanlaajuinen kaikille projekteille ja päätelaitteille. Mutta kun tarvitsemme tietyn version, meillä on kaksi tapaa tehdä se. Ensimmäinen on käyttää sdk käyttää komennon joka kerta, kun haluamme käyttää työkalun tiettyä versiota nykyisessä päätelaitteessa. Toinen on laatia versioluettelo .sdkmanrc tiedosto, joka on tallennettu projektin mukana.

Ensimmäinen vaihtoehto on tarkoitettu yksittäiskäyttöön, mutta toinen on suunniteltu tiimityöskentelyyn ja kokoonpanojen jakamiseen seuraavien kesken. joukkue jäsenet.

SDKMANin hyvät ja huonot puolet!

SDKMAN! on erittäin helppokäyttöinen, ja siinä on laaja kirjasto tuettuja työkaluja, kehyksiä ja kieliä. Se toimii Linuxissa, MacOS:ssä ja Windowsissa. Toisaalta tämä työkalu on JVM-keskeinen ja vaatii tekijän hyväksynnän myyjäksi. Lisäksi mekaniikan .sdkmanrc on erittäin huono ja voi hidastaa hakemistojen vaihtamista merkittävästi.

Haluaisin käyttää monia muita kieliä

Jos sinun on käytettävä useita kieliä ja työkaluja, sinun kannattaa tutustua seuraaviin tuotteisiin asdf. Tämä työkalu keskittyy "korkean tason" työkaluihin. SDKMAN! -ohjelmasta löydät monia Java-kohtaisia työkaluja, kuten Bpipe tai Znai, mutta asdf tarjoaa paljon enemmän työkaluja, jotka eivät ole niin erityisiä. Tietenkin jotkut näistä työkaluista ovat päällekkäisiä, esimerkiksi Java, Tomcat tai mvnd ovat saatavilla molemmissa.

Kun haluat käyttää asdf, sinulla on oltava git ja curl asennettu. Sen jälkeen voit vain:

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

ja lisää nämä rivit ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/completions/asdf.bash

Nyt voit asentaa liitännäisiä ja työkaluja suosikkiversioissasi.

Plugin-pohjainen hallinta

Toisin kuin SDKMAN!, asdf käyttää liitännäisiä työkalujen hallintaan. Ennen kuin voit asentaa työkalun, sinun on siis asennettava lisäosa. Palataanpa takaisin esimerkkiprojektiimme ja yritetään konfiguroida ympäristö käyttäen seuraavia ohjeita asadfsdf.

Ensin meidän on asennettava lisäosat:

asdf-lisäosan lisääminen java

asdf-lisäosa lisää maven

asdf plugin add mvnd

Sitten voimme asentaa työkalut:

asdf install java openjdk-17

asdf asentaa maven 3.8.4:n

asdf install mvnd 0.7.1

Ja jälleen kerran, toisin kuin SDKMAN!, asdf ei muuta mitään ympäristössämme. Kun yritämme käyttää javaa, saamme seuraavan virheilmoituksen:

Komennolle Java ei ole asetettu versiota

Harkitse jonkin seuraavan version lisäämistä konfigurointitiedostoon osoitteessa ~/.tool-versions

java openjdk-17

Meidän on luotava tiedosto .tool-versiot kotihakemistossa oletusversioiden hallintaa varten.

Paikalliset ja maailmanlaajuiset versiot

Ohjelmistoversioiden päivittäminen asdf on melko yksinkertainen. Asennamme vain uuden version. Koska tämä prosessi ei vaikuta ympäristöön, voimme tehdä sen milloin tahansa ja mihin tahansa kohtaan tiedostojärjestelmässä. Kun haluamme käyttää jonkin ohjelmiston tiettyä versiota, meidän on luotava projektin hakemistoon tiedosto nimeltä .tool-versiot tiedosto, jonka tiimin jäsenet voivat jakaa keskenään. Muista, että sinun on taattava, että kaikilla tiimin jäsenillä on seuraavat tiedot asdf ja lisäosat asennettuna. Luettelo lisäosista löytyy täällä.

Versiokonfliktit

asdf tukee paitsi ohjelmointikieliä, kehyksiä ja työkaluja, kuten vimiä tai kubernetessiä. Se tukee myös tietokantoja. Tällöin voisimme asentaa useita versioita esimerkiksi Postgresista, mutta vain yksi instanssi voisi toimia. Tämä johtuu siitä, että asdf suorittaa komentoja suoraan käyttöjärjestelmässäsi ilman mitään erottavaa kerrosta. Tämä johtaa ongelmiin, kuten "portti on jo käytössä" ja resurssikonflikteihin.

Hyödyt ja haitat

asdf on erittäin hyvä työkalu, jos haluat työskennellä monikielisessä ympäristössä. Se tukee monia työkaluja, kieliä ja kehyksiä. Plugin-pohjainen arkkitehtuuri tekee sen laajentamisesta erittäin helppoa. Jotkin sen kirjastossa olevista työkaluista vaativat kuitenkin lisätyötä asennuksen aikana, jotta kaikki tarvittavat riippuvuudet saadaan käyttöön. asdf ei toimi Windowsissa, edes WSL.

Viimeisenä mutta ei vähäisimpänä - Docker

Kun puhuin edellä satamakonfliktista, monet teistä tietävät ratkaisun.

Docker voisi auttaa meitä joissakin tapauksissa. Mainitsen sen velvollisuudestani, koska tämä työkalu on niin suuri ja monimutkainen, ettemme voi käsitellä sitä yhdessä artikkelissa.

Yhdessä Dockerin kanssa meidän pitäisi käyttää docker-compose työkalu, joka antaa meille mahdollisuuden koordinoida monen kontin ympäristöjä.

Dockerin hyvät ja huonot puolet

Docker auttaa meitä hallitsemaan työkaluja, jotka tarvitsevat tiettyjä resursseja, kuten portteja tai tiedostoja. Se erottelee instanssit kontteihin ja antaa meille täyden hallinnan niihin. Docker on kuitenkin työkalu, joka tuo paljon monimutkaisuutta työympäristöömme ja voi joissakin tapauksissa olla ongelmallinen. Yksi näistä tapauksista, joissa Dockeria käytetään testeissä, on kuvattu yhdessä aiemmista tapauksistamme artikkeli.

Yhteenveto

Tiedän, etten kuvannut kaikkia työkaluja, joita voidaan käyttää työkaluversioiden hallintaan. Niitä on paljon muitakin, kuten jEnv joka voisi korvata SDKMANin,

tai NVM jota voimme käyttää npm:n tai RVM Rubyn puolesta. Keskityin työkaluihin, joita olen "testannut taistelukentällä" ja joita voin suositella kenelle tahansa.