Vai vienā datorā varat strādāt ar vairākām vidēm vairākiem projektiem?

Apskatīsim tipisku darba vidi uzņēmumā programmatūras māja. Jums ir vairāki klienti, kuriem ir dažādas vides. Daži dod priekšroku MySQL, citi - Postgres. Vienai jūsu lietojumprogrammas versijai ir nepieciešama Java 11, un vēl viens Java 17. Frontend ir nepieciešams npm 12 vai 16, jo jūs izmantojat dažādas versijas leņķa. Visbeidzot, jums ir trīsdimensiju masīvs, kas satur visu jūsu DB, backend un frontend versiju kombinācijas. Izklausās slikti, bet kādu dienu jūsu priekšnieks saka...

Multiversālas vides saknes

Iepriekš aprakstītā situācija nav nekas neparasts. Migrācija starp valodas vai ietvara versijām, datubāzu atjauninājumi vai vienkārši atšķirīgas klientu prasības var apgāzt visas konfigurācijas. Mums ir jābūt risinājumam, kas palīdz mums pārvaldīt šīs izmaiņas, kas atbilst dažiem pieņēmumiem un/vai prasībām, un/vai mērķiem:

• viegli lietojams - viena komanda, lai mainītu konfigurāciju vai versiju,
• bagāta bibliotēka - jāatbalsta vairākas tehnoloģijas un "lietas" (bibliotēkas, ietvarprogrammas, lietotnes),
• paplašināms - jums vajadzētu piedāvāt iespēju pievienot savus spraudņus.

Šajā rakstā pievērsīšos trim jomām. Pirmā ir Java un JVM rīki. Otrā ir vispārējas nozīmes rīki. Trešā ir par to, kā izmantot docker lai sasniegtu mūsu mērķus.

​

Es esmu Java un strādāju ar JVM

Kad esat Java izstrādātājs vai, vispārīgāk, strādājat ar JVM tehnoloģijas, tad varat izmantot SDKMAN!. Tas ir ļoti jauks un viegli lietojams rīks, kas atbalsta daudzas bibliotēkas, struktūras un valodas.

Uzstādīšanas process SDKMAN! Tas ir diezgan vienkārši. Jums ir nepieciešams palaist:

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

un pēc tam

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

Tagad varat pārvaldīt Java, Scala un Maven versijas.

Versiju pārvaldība - piemērs

Šajā piemērā mēs instalēsim un atjaunināsim dažu rīku versijas. Šī ir tikai neliela pieejamo rīku apakškopa.

Uzstādīšana

Pieņemsim, ka jūsu jaunais projekts izmanto Java 17. Jums nav Java instalēta versija. Jūs vēlaties to instalēt un papildus pievienot Maven Daemon rīku, lai paātrinātu kompilēšanu. Tātad jums ir jāinstalē arī Maven. Lai to izdarītu, ir jāizpilda trīs vienkāršas komandas:

$ sdk instalēt java 17-open

$ sdk instalēt maven 3.8.4

$ sdk install mvnd 0.7.1

Katra rīka instalēšanas beigās jums tiks uzdots jautājums par tā noklusējuma iestatīšanu:

Vai vēlaties, lai Java 17-open tiktu iestatīta kā noklusējuma iestatījums? (Y/n):

Tas ir svarīgi, ja instalējat jaunu bibliotēkas vai valodas versiju, jo SDKMAN! uzstādīs šo noklusējuma versiju kā globālu visiem pašreizējā lietotāja termināļiem.

Versiju pārbaude un atjaunināšana

Laiku pa laikam SDKMAN! ir jāatjaunina indeksi. Tā laikā jūs varētu saņemt paziņojumu, ka ir dažas jaunas versijas jūsu izmantotajiem rīkiem. Mēs varam pārbaudīt, kuras versijas ir pieejamas, ierakstot sdk ls . Par sdk ls maven:

Pieejamās Maven versijas

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

    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



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

vietējā versija

pašlaik lietošanā

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

Kā redzams iepriekš, Maven ir jaunāka versija nekā tā, ko mēs izmantojam. Tas pats attiecas uz mvnd (0.8.2) un Java (19-open). Atjaunināsim visu. Lai to izdarītu, mums vienkārši jāizsauc instalēšanas komanda, bet šoreiz mēs neizmantosim versijas noteicēju:

$ sdk instalēt maven

$ sdk instalēt mvnd

$ sdk instalēt java

Taču notika kaut kas nepareizs. Maven un mvnd ir pareizas versijas, bet Java ir versija 17.0.5-tem. Tas ir tāpēc, ka rīka "jaunāko" versiju kontrolē tā pārdevējs, nevis vietējais SDKMAN! kas ir šis pārdevējs? Pārdevējs SDKMAN! ir kāds, kas var publicēt versiju. Tomēr pieņemsim, ka mēs beidzot instalējam 19 atvērts, un mēs to padarījām par noklusējuma iestatījumu, bet kāda iemesla dēļ mums ir nepieciešams izmantot 17 atvērts.

Vietējās versijas un per-terminālu versiju pārvaldība

​
Mēs varam konfigurēt noklusējuma rīka versija, kas ir globāla visiem projektiem un termināļiem. Bet, ja mums ir nepieciešama konkrēta versija, mums ir divi veidi, kā to izdarīt. Pirmais ir izmantot sdk lietošana komandu ikreiz, kad vēlamies izmantot konkrētu rīka versiju pašreizējā terminālī. Otrais ir sagatavot versiju sarakstu .sdkmanrc fails, kas tiek saglabāts kopā ar projektu.

Pirmā iespēja ir paredzēta vienreizējai lietošanai, bet otrā ir paredzēta darbam komandās un konfigurāciju koplietošanai starp komanda locekļi.

SDKMAN plusi un mīnusi!

SDKMAN! ir ļoti viegli lietojams, un tam ir bagātīga atbalstīto rīku, ietvaru un valodu bibliotēka. Tā darbojas Linux, MacOS un Windows. No otras puses, šis rīks ir orientēts uz JVM, un tam ir nepieciešams autora piekrišana būt par piegādātāju. Turklāt mehānika .sdkmanrc ir ļoti slikta un var ievērojami palēnināt direktoriju maiņas procesu.

Es vēlētos izmantot daudzas citas valodas

Ja jums ir nepieciešams izmantot daudzas valodas un rīkus, jums vajadzētu aplūkot asdf. Šis rīks ir vērsts uz "augsta līmeņa" rīkiem. Lai gan SDKMAN! var atrast daudzus Java specifiskus rīkus, piemēram, Bpipe vai Znai, asdf piedāvā daudz vairāk rīku, bet ne tik specifiskus. Protams, daži no šiem rīkiem pārklājas, piemēram, Java, Tomcat vai mvnd ir pieejami abos.

Ja vēlaties izmantot asdf, jums ir jābūt git un curl uzstādīts. Pēc tam jūs vienkārši:

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

un pievienojiet šīs rindas ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Tagad varat instalēt spraudņus un rīkus iecienītākajās versijās.

Uz spraudņiem balstīta pārvaldība

Atšķirībā no SDKMAN!, asdf rīku pārvaldībai izmanto spraudņus. Tātad, pirms varat instalēt rīku, ir jāinstalē spraudnis. Atgriezīsimies pie mūsu piemēra projekta un mēģināsim konfigurēt vidi, izmantojot asadfsdf.

Vispirms mums ir jāinstalē spraudņi:

asdf spraudnis pievienot java

asdf spraudnis pievienot maven

asdf spraudnis pievienot mvnd

Pēc tam varam instalēt rīkus:

asdf instalēt java openjdk-17

asdf instalēt maven 3.8.4

asdf instalēt mvnd 0.7.1

Un atkal, atšķirībā no SDKMAN!, asdf neko nemaina mūsu vidē. Kad mēs mēģinām izmantot java, mēs saņemam šādu kļūdas ziņojumu:

Komandai Java nav iestatīta versija

Apsveriet iespēju konfigurācijas failā ~/.tool-versions pievienot vienu no šādām versijām

java openjdk-17

Mums ir nepieciešams izveidot failu .tool-versions sākuma direktorijā, lai pārvaldītu noklusējuma versijas.

Vietējās un globālās versijas

Programmatūras versiju atjaunināšana ar asdf ir pavisam vienkārša. Mēs vienkārši instalējam jaunu versiju. Tā kā šis process neietekmē vidi, mēs to varam izdarīt jebkurā laikā un jebkurā failu sistēmas vietā. Ja vēlamies izmantot kādu konkrētu programmatūras versiju, mums projekta direktorijā ir jāizveido .tool-versions failu, ko var kopīgot komandas locekļi. Atcerieties, ka jums ir jāgarantē, ka visiem komandas locekļiem ir asdf un instalēti spraudņi. Spraudņu saraksts, kurā var atrast šeit.

Versiju konflikti

asdf atbalsta ne tikai programmēšanas valodas, ietvarstruktūras un rīkus, piemēram, vim vai kubernetess. Tā atbalsta arī datubāzes. Tādā gadījumā mēs varētu instalēt vairākas, piemēram, Postgres versijas, bet varētu palaist tikai vienu gadījumu. Tas ir tāpēc, ka asdf izpilda komandas tieši operētājsistēmā bez atdalīšanas slāņa. Tas rada tādas problēmas kā "ports jau tiek izmantots" un resursu konfliktus.

Priekšrocības un trūkumi

asdf ir ļoti labs rīks, ja vēlaties strādāt poligloti runājošā vidē. Tas atbalsta daudzus rīkus, valodas un ietvarstruktūras. Uz spraudņiem balstītā arhitektūra ļauj to ļoti viegli paplašināt. Tomēr ar dažiem tā bibliotēkā esošajiem rīkiem instalēšanas laikā ir nepieciešams veikt papildu darbu, lai nodrošinātu visas nepieciešamās atkarības. asdf nedarbojas operētājsistēmā Windows, pat ja WSL.

Pēdējais, bet ne mazāk svarīgais - Docker

Kad iepriekš runāju par ostas konfliktu, daudzi no jums zina risinājumu.

Docker dažos gadījumos varētu mums palīdzēt. Es to pieminēju no pienākuma, jo šis rīks ir tik liels un sarežģīts, ka mēs to nevaram apspriest vienā rakstā.

Kopā ar Docker mums vajadzētu izmantot docker-compose rīks, kas dod mums iespēju koordinēt vairāku konteineru vidi.

Docker plusi un mīnusi

Docker palīdz mums pārvaldīt rīkus, kuriem nepieciešami konkrēti resursi, piemēram, porti vai faili. Tas nodala gadījumus konteineros un nodrošina pilnīgu kontroli pār tiem. Tomēr Docker ir rīks, kas mūsu darba vidē ievieš daudz sarežģījumu un dažos gadījumos var radīt problēmas. Viens no šādiem gadījumiem, kad Docker tiek izmantots testā, ir aprakstīts vienā no mūsu iepriekšējām raksts.

Rezumējot

Es zinu, ka neesmu aprakstījis visus rīkus, kurus var izmantot rīku versiju pārvaldībai. To ir daudz vairāk, piemēram. jEnv kas varētu aizstāt SDKMAN,

vai NVM ko varam izmantot, lai pārvaldītu npm vai RVM vietnē Rubīns. Es koncentrējos uz rīkiem, kurus "pārbaudīju kaujas laukā" un kurus varu ieteikt ikvienam.