window.pipedriveLeadboosterConfig = { base: leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster on juba olemas') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Käsitleda mitut keskkonda mitme projekti jaoks ühes masinas? - The Codest
The Codest
  • Meie kohta
  • Teenused
    • Tarkvaraarendus
      • Frontend arendus
      • Backend arendus
    • Staff Augmentation
      • Frontend arendajad
      • Backend arendajad
      • Andmeinsenerid
      • Pilveinsenerid
      • QA insenerid
      • Muud
    • See nõuandev
      • Audit ja nõustamine
  • Tööstusharud
    • Fintech & pangandus
    • E-commerce
    • Adtech
    • Healthtech
    • Tootmine
    • Logistika
    • Autotööstus
    • IOT
  • Väärtus
    • CEO
    • CTO
    • Tarnejuht
  • Meie meeskond
  • Case Studies
  • Tea kuidas
    • Blogi
    • Kohtumised
    • Veebiseminarid
    • Ressursid
Karjäärivõimalused Võtke ühendust
  • Meie kohta
  • Teenused
    • Tarkvaraarendus
      • Frontend arendus
      • Backend arendus
    • Staff Augmentation
      • Frontend arendajad
      • Backend arendajad
      • Andmeinsenerid
      • Pilveinsenerid
      • QA insenerid
      • Muud
    • See nõuandev
      • Audit ja nõustamine
  • Väärtus
    • CEO
    • CTO
    • Tarnejuht
  • Meie meeskond
  • Case Studies
  • Tea kuidas
    • Blogi
    • Kohtumised
    • Veebiseminarid
    • Ressursid
Karjäärivõimalused Võtke ühendust
Tagasi nool TAGASI
2022-12-01
Tarkvaraarendus

Käsitleda mitut keskkonda mitme projekti jaoks ühes masinas?

Bartłomiej Kuczyński

Kas on olemas kuldne kesktee, et suure hulga keskkondade käsitlemiseks vaid ühe masina abil? Meie Java ekspert Bartłomiej teab vastust!

Vaatleme tüüpilist töökeskkonda ühes tarkvaramaja. Teil on mõned kliendid, kellel on erinevad keskkonnad. Mõned eelistavad MySQL-i, teised eelistavad Postgres'i. Üks teie rakenduse versioon vajab Java 11 ja teine Java 17. Frontend vajab npm 12 või 16, sest te kasutate erinevaid versioone nurgeline. Lõpuks on teil see kolmemõõtmeline massiivi, mis sisaldab kõigi teie andmebaaside, backend- ja frontend-versioonide kombinatsioone. Kõlab halvasti, kuid ühel päeval ütleb teie ülemus...

koomiksid<em> koos</em>bossiga

Multiversumi keskkonna juured

Eespool kirjeldatud olukord ei ole midagi haruldast. Migratsioon keele või raamistiku versioonide vahel, andmebaaside uuendamine või lihtsalt klientide erinevad nõuded võivad kõik konfiguratsioonid pea peale pöörata. Meil peaks olema lahendus, mis aitab meil neid muutusi hallata, mis vastab mõnele eeldusele ja/või nõuetele ja/või eesmärkidele:

  • lihtne kasutada - üks käsk konfiguratsiooni või versiooni muutmiseks,
  • rikkalik raamatukogu - peaks toetama mitmeid tehnoloogiaid ja "asju" (raamatukogud, raamistikud, rakendused),
  • laiendatav - peaksite pakkuma võimalust lisada oma pistikprogramme.

Käesolevas artiklis keskendun kolmele valdkonnale. Esimene on Java ja JVMi tööriistad. Teine on üldotstarbelised tööriistad. Kolmas on see, kuidas kasutada dokkerit meie eesmärkide saavutamiseks.

​

Ma olen Java ja töötan JVMi peal.

Kui olete Java arendaja või üldisemalt, te töötate koos JVM tehnoloogiad, siis saate kasutada SDKMAN!. See on väga kena ja kergesti kasutatav tööriist, mis toetab paljusid raamatukogusid, raamistikke ja keeli.

Paigaldusprotsess on SDKMAN! See on üsna lihtne. Sa pead jooksma:

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

ja siis

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

Nüüd saate hallata oma Java, Scala ja Maven versioonid.

Versioonide haldamine - näide

Selles näites paigaldame ja uuendame mõne tööriista versiooni. See on vaid väike osa olemasolevatest tööriistadest.

Paigaldamine

Oletame, et teie uus projekt kasutab Java 17. Sul ei ole ühtegi Java paigaldatud versioon. Te soovite selle paigaldada ja lisaks lisada Maven Daemon tööriista, et muuta koostamine kiiremaks. Seega tuleb paigaldada ka Maven. Selleks tuleb täita kolm lihtsat käsku:

$ sdk install java 17-open

$ sdk paigaldada maven 3.8.4

$ sdk install mvnd 0.7.1

Iga tööriista paigaldamise lõpus küsitakse, kas see on vaikimisi seadistatud:

Kas soovite, et Java 17-open oleks vaikimisi määratud? (Y/n):

See on oluline, kui paigaldate uue raamatukogu või keele versiooni, sest SDKMAN! seab selle vaikimisi versiooni globaalseks kõigi terminali jaoks praeguse kasutaja jaoks.

Versioonide kontrollimine ja ajakohastamine

Aeg-ajalt peab SDKMAN! uuendama indekseid. Selle käigus võite saada teate, et on olemas mõned uued versioonid tööriistadest, mida te kasutate. Saame kontrollida, millised versioonid on saadaval, kui sisestame sdk ls. Sest sdk ls maven:

Saadaolevad Maven versioonid

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

    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



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

kohalik versioon

praegu kasutusel

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

Nagu eespool näha, on Mavenil uuem versioon kui see, mida me kasutame. Sama kehtib ka mvnd (0.8.2) ja Java (19-open). Uuendame kõike. Selleks peame lihtsalt kutsuma käsu install, kuid seekord me ei kasuta versiooni täpsustajat:

$ sdk paigaldada maven

$ sdk install mvnd

$ sdk installida java

Kuid midagi juhtus valesti. Maven ja mvnd on õiged versioonid, kuid Java on versioon 17.0.5-tem. Seda seetõttu, et tööriista "uusimat" versiooni kontrollib selle müüja, mitte kohalik SDKMAN! kes on see müüja? SDKMAN! müüja on keegi, kes saab avaldada versiooni. Oletame aga, et me lõpuks installeerime 19-avatud, ja me tegime selle vaikimisi, kuid mingil põhjusel peame kasutama 17-avatud.

Kohalikud versioonid ja terminali versioonihaldus

​
Me saame konfigureerida vaikimisi tööriista versioon, mis on globaalne kõigi projektide ja terminalide jaoks. Kui aga vajame konkreetset versiooni, on meil selleks kaks võimalust. Esimene on kasutada sdk use käsk iga kord, kui me tahame kasutada mingi tööriista konkreetset versiooni praeguses terminalis. Teiseks tuleb koostada versioonide nimekiri .sdkmanrc faili, mis on salvestatud koos projektiga.

Kui esimene variant on mõeldud ühekordseks kasutamiseks, siis teine on mõeldud meeskonnatööks ja konfiguratsioonide jagamiseks järgmiste seadmete vahel. meeskond liikmed.

SDKMANi plussid ja miinused!

SDKMAN! on väga lihtne kasutada ja sellel on rikkalik toetatud tööriistade, raamistike ja keelte raamatukogu. See töötab Linuxis, MacOSis ja Windowsis. Teisest küljest on see tööriist JVM-keskne ja nõuab autori nõusolekut müüjale. Lisaks sellele on mehaanika .sdkmanrc on väga halb ja võib kataloogide muutmise protsessi märkimisväärselt aeglustada.

Tahaksin kasutada paljusid teisi keeli

Kui teil on vaja kasutada paljusid keeli ja vahendeid, siis peaksite vaatama asdf. See tööriist keskendub "kõrgetasemelistele" tööriistadele. Kui SDKMAN! leiate palju Java-spetsiifilisi tööriistu, nagu Bpipe või Znai, siis asdf pakub palju rohkem tööriistu, kuid mitte nii spetsiifilisi. Loomulikult kattuvad mõned neist tööriistadest, nt Java, Tomcat või mvnd on mõlemas saadaval.

Kui soovite kasutada asdf, peate olema git ja curl paigaldatud. Pärast seda te lihtsalt:

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

ja lisada need read ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Nüüd saate installida pluginad ja tööriistad oma lemmikversioonides.

Pistikupesa-põhine juhtimine

Erinevalt SDKMANist!, asdf kasutab tööriistade haldamiseks pluginaid. Seega, enne kui saate tööriista paigaldada, peate paigaldama plugina. Lähme tagasi meie näidisprojekti juurde ja proovime seadistada keskkonda kasutades asadfsdf.

Kõigepealt peame paigaldama pluginad:

asdf plugin lisab java

asdf plugin lisada maven

asdf plugin add mvnd

Seejärel saame paigaldada oma tööriistad:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

Ja veel kord, erinevalt SDKMANist!, asdf ei muuda midagi meie keskkonnas. Kui me üritame kasutada java't, saame veateate nagu:

Käskkirja Java jaoks ei ole versiooni määratud

Kaaluge, kas lisada üks järgmistest versioonidest oma konfiguratsioonifaili ~/.tool-versions

java openjdk-17

Me peame looma faili .tool-versioonid kodukataloogis, et hallata vaikimisi versioone.

Kohalikud ja globaalsed versioonid

Tarkvaraversioonide uuendamine koos asdf on üsna lihtne. Me lihtsalt paigaldame uue versiooni. Kuna see protsess ei mõjuta keskkonda, võime seda teha igal ajal ja igas kohas failisüsteemis. Kui me tahame kasutada mingi tarkvara konkreetset versiooni, peame looma projekti kataloogi .tool-versioonid faili, mida saab meeskonnaliikmete vahel jagada. Pidage meeles, et peate tagama, et kõigil meeskonnaliikmetel on asdf ja pluginad paigaldatud. Pistikprogrammide loetelu leiate siin.

Versioonikonfliktid

asdf toetab mitte ainult programmeerimiskeeli, raamistikke ja vahendeid nagu vim või kubernetess. See toetab ka andmebaase. Sellisel juhul võiksime paigaldada mitu versiooni näiteks Postgresist, kuid käivitada saaksime ainult ühe instantsi. Seda seetõttu, et asdf täidab käske otse teie operatsioonisüsteemis ilma eralduskihita. See toob kaasa selliseid probleeme nagu "port on juba kasutusel" ja konfliktid ressurssidega.

Plussid ja miinused

asdf on väga hea vahend, kui soovite töötada mitmekeelses keskkonnas. See toetab paljusid tööriistu, keeli ja raamistikke. Plugin-põhine arhitektuur teeb selle laiendamise väga lihtsaks. Siiski vajavad mõned tööriistad, mis tal raamatukogus on, paigaldamise ajal lisatööd, et tagada kõik vajalikud sõltuvused. asdf ei tööta Windowsis, isegi mitte WSL.

Viimane, kuid mitte vähem oluline - Docker

Kui ma räägin eespool sadamakonfliktist, siis paljud teist teavad lahendust.

Docker võiks meid mõnel juhul aidata. Ma mainin seda kohusetundest, sest see tööriist on nii suur ja keeruline, et me ei saa seda ühes artiklis arutada.

Koos Dockeriga peaksime kasutama docker-compose vahend, mis annab meile võimaluse koordineerida mitme konteineri keskkondi.

Dockeri plussid ja miinused

Docker aitab meil hallata tööriistu, mis vajavad teatavaid ressursse, näiteks porte või faile. See eraldab instantsid konteinerites ja annab meile täieliku kontrolli nende üle. Sellest hoolimata on Docker vahend, mis toob meie töökeskkonda palju keerukust ja võib mõnel juhul olla problemaatiline. Üks sellistest Dockeri kasutamise juhtudest testis on kirjeldatud ühes meie varasemas artikkel.

Kokkuvõte

Ma tean, et ma ei kirjeldanud kõiki vahendeid, mida võiks kasutada tööriistade versioonide haldamiseks. Neid on palju rohkem, näiteks jEnv mis võiks asendada SDKMANi,

või NVM mida me saame kasutada npm või RVM Ruby jaoks. Keskendusin tööriistadele, mida ma "lahinguväljal katsetasin" ja mida võin soovitada kõigile.

Seotud artiklid

Tarkvaraarendus

9 viga, mida vältida Java programmeerimisel

Milliseid vigu tuleks Java keeles programmeerimisel vältida? Järgnevas teoses vastame sellele küsimusele.

The Codest
Rafal Sawicki Java arendaja
Enterprise & Scaleups lahendused

Kuidas saab Java teie ettevõtet toetada?

Enne kui me alustame, tahaksin teile meelde tuletada üht olulist asja. Java ei ole ainult programmeerimiskeel.

Bartlomiej Kuczynski
Tarkvaraarendus

Testikonteinerid - kuidas muuta testid lihtsamaks?

Kas otsite võimalust teha teste lihtsamalt? Meil on teid! Vaadake järgmist artiklit ja õppige, kuidas seda teha.

Bartlomiej Kuczynski
Tarkvaraarendus

Javascript tööriistad tegevuses

Avastage mõningaid vahendeid JavaScript, et tõsta oma programmeerimismängu taset. Lisateave ESLint, Prettier ja Husky kohta!

The Codest
Reda Salmi React Arendaja
Tarkvaraarendus

Asünkroonne ja ühetäheline JavaScript?

JavaScript on ühetäheline keel ja samal ajal ka mitteblokeeriv, asünkroonne ja samaaegne. Selles artiklis selgitatakse teile, kuidas see toimub.

Lukasz Kolko

Tellige meie teadmistebaas ja jääge kursis IT-sektori eksperditeadmistega.

    Meie kohta

    The Codest - rahvusvaheline tarkvaraarendusettevõte, mille tehnoloogiakeskused asuvad Poolas.

    Ühendkuningriik - peakorter

    • Büroo 303B, 182-184 High Street North E6 2JA
      London, Inglismaa

    Poola - kohalikud tehnoloogiakeskused

    • Fabryczna büroopark, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Varssavi, Poola

      The Codest

    • Kodu
    • Meie kohta
    • Teenused
    • Case Studies
    • Tea kuidas
    • Karjäärivõimalused
    • Sõnastik

      Teenused

    • See nõuandev
    • Tarkvaraarendus
    • Backend arendus
    • Frontend arendus
    • Staff Augmentation
    • Backend arendajad
    • Pilveinsenerid
    • Andmeinsenerid
    • Muud
    • QA insenerid

      Ressursid

    • Faktid ja müüdid koostööst välise tarkvaraarenduspartneriga
    • USAst Euroopasse: Miks otsustavad Ameerika idufirmad Euroopasse ümber asuda?
    • Tech Offshore arenduskeskuste võrdlus: Euroopa (Poola), ASEAN (Filipiinid), Euraasia (Türgi).
    • Millised on CTO ja CIOde peamised väljakutsed?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2025 by The Codest. Kõik õigused kaitstud.

    etEstonian
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch elGreek etEstonian