The Codest
  • Apie mus
  • Paslaugos
    • Programinės įrangos kūrimas
      • Priekinės dalies kūrimas
      • Galinės dalies kūrimas
    • Staff Augmentation
      • Priekinės dalies kūrėjai
      • Atgalinės versijos kūrėjai
      • Duomenų inžinieriai
      • Debesų inžinieriai
      • QA inžinieriai
      • Kita
    • Patariamoji tarnyba
      • Auditas ir konsultacijos
  • Pramonės šakos
    • Fintech ir bankininkystė
    • E-commerce
    • Adtech
    • Sveikatos technologijos
    • Gamyba
    • Logistika
    • Automobiliai
    • IOT
  • Vertė už
    • CEO
    • CTO
    • Pristatymo vadybininkas
  • Mūsų komanda
  • Case Studies
  • Sužinokite, kaip
    • Tinklaraštis
    • Susitikimai
    • Interneto seminarai
    • Ištekliai
Karjera Susisiekite su mumis
  • Apie mus
  • Paslaugos
    • Programinės įrangos kūrimas
      • Priekinės dalies kūrimas
      • Galinės dalies kūrimas
    • Staff Augmentation
      • Priekinės dalies kūrėjai
      • Atgalinės versijos kūrėjai
      • Duomenų inžinieriai
      • Debesų inžinieriai
      • QA inžinieriai
      • Kita
    • Patariamoji tarnyba
      • Auditas ir konsultacijos
  • Vertė už
    • CEO
    • CTO
    • Pristatymo vadybininkas
  • Mūsų komanda
  • Case Studies
  • Sužinokite, kaip
    • Tinklaraštis
    • Susitikimai
    • Interneto seminarai
    • Ištekliai
Karjera Susisiekite su mumis
Atgal rodyklė GRĮŽTI ATGAL
2022-12-01
Programinės įrangos kūrimas

Viename kompiuteryje tvarkyti kelias kelių projektų aplinkas?

Bartłomiej Kuczyński

Ar yra aukso viduriukas, leidžiantis vienu kompiuteriu tvarkyti daugybę aplinkų? Mūsų "Java" ekspertas Bartłomiej žino atsakymą!

Pažvelkime į tipišką darbo aplinką programinės įrangos namai. Turite kelis klientus, kurių aplinka skiriasi. Vieni renkasi "MySQL", kiti - "Postgres". Vienai jūsų programos versijai reikia Java 11, o kitas Java 17. Frontend'ui reikia npm 12 arba 16, nes naudojate skirtingas versijas kampinis. Galiausiai turite trimatį masyvą, kuriame yra visų jūsų DB, backend ir frontend versijų deriniai. Skamba blogai, bet vieną dieną jūsų viršininkas sako...

komiksai<em>su</em> bosu

Daugialypės aplinkos šaknys

Pirmiau aprašyta situacija nėra neįprasta. Perėjimas nuo vienos kalbos ar struktūros versijos prie kitos, duomenų bazių atnaujinimas ar tiesiog skirtingi klientų reikalavimai gali apversti aukštyn kojomis visas konfigūracijas. Turėtume turėti sprendimą, kuris padėtų mus valdyti šiuos pokyčius, kuris atitiktų kelias prielaidas ir (arba) reikalavimus ir (arba) tikslus:

  • lengva naudoti - viena komanda pakeisti konfigūraciją arba versiją,
  • turtinga biblioteka - turėtų palaikyti įvairias technologijas ir dalykus (bibliotekas, karkasus, programas),
  • išplečiamasis - turėtumėte pasiūlyti galimybę pridėti savo įskiepius.

Šiame straipsnyje daugiausia dėmesio skirsiu trims sritims. Pirmoji sritis - "Java" ir JVM įrankiai. Antroji - bendrosios paskirties įrankiai. Trečioji - kaip naudoti "docker" kad pasiektume savo tikslus.

​

Aš esu Java ir dirbu JVM

Kai esate "Java" programuotojas arba apskritai dirbate su JVM technologijos, tada galite naudoti SDKMAN!. Tai labai gražus ir paprastas naudoti įrankis, palaikantis daugybę bibliotekų, struktūrų ir kalbų.

Diegimo procesas SDKMAN! Tai gana paprasta. Reikia paleisti:

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

ir tada

šaltinis "$HOME/.sdkman/bin/sdkman-init.sh"

Dabar galite valdyti savo Java, Scala ir Maven versijos.

Versijų valdymas - pavyzdys

Šiame pavyzdyje įdiegsime ir atnaujinsime kelių įrankių versijas. Tai tik nedidelis galimų įrankių poaibis.

Įrengimas

Tarkime, kad jūsų naujoji projektas naudoja Java 17. Jūs neturite jokių Java įdiegta versija. Norite ją įdiegti ir papildomai pridėti "Maven Daemon" įrankį, kad kūrimas būtų greitesnis. Taigi reikia įdiegti ir "Maven". Norėdami tai padaryti, turite įvykdyti tris paprastas komandas:

$ sdk įdiegti java 17-open

$ sdk įdiegti maven 3.8.4

$ sdk įdiegti mvnd 0.7.1

Kiekvieno įrankio diegimo pabaigoje jūsų bus paklausta, ar norite, kad jis būtų numatytasis:

Ar norite, kad "Java 17-open" būtų nustatyta kaip numatytoji? (Y/n):

Tai svarbu diegiant naują bibliotekos ar kalbos versiją, nes SDKMAN! nustatys šią numatytąją versiją kaip visuotinę visiems dabartinio naudotojo terminalams.

Versijų tikrinimas ir atnaujinimas

Retkarčiais SDKMAN! turi atnaujinti indeksus. Per tai galite gauti pranešimą, kad yra keletas naujų naudojamų įrankių versijų. Galime patikrinti, kokios versijos yra, įvesdami sdk ls. Dėl sdk ls maven:

Galimos "Maven" versijos

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

    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



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

vietinė versija

šiuo metu naudojama

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

Kaip matome pirmiau, "Maven" turi naujesnę versiją nei ta, kurią naudojame. Tas pats pasakytina ir apie mvnd (0.8.2) ir "Java" (19-open). Atnaujinkime viską. Tam tereikia iškviesti diegimo komandą, tačiau šį kartą nenaudosime versijos žymens:

$ sdk įdiegti maven

$ sdk įdiegti mvnd

$ sdk įdiegti java

Tačiau įvyko kažkas blogo. Maven ir mvnd turi teisingas versijas, bet Java turi versiją 17.0.5-tem. Taip yra todėl, kad "naujausią" įrankio versiją kontroliuoja jo pardavėjas, o ne vietinis SDKMAN! kas yra šis pardavėjas? Pardavėjas SDKMAN! yra asmuo, kuris gali paskelbti versiją. Tačiau tarkime, kad pagaliau įdiegėme 19 atvirų durųir nustatėme, kad jis yra numatytasis, tačiau dėl tam tikrų priežasčių mums reikia naudoti 17 atviras.

Vietinės versijos ir kiekvieno terminalo versijų valdymas

​
Galime sukonfigūruoti numatytasis įrankio versiją, kuri yra visuotinė visiems projektams ir terminalams. Tačiau kai mums reikia konkrečios versijos, turime du būdus, kaip tai padaryti. Pirmasis yra naudoti sdk naudoti komandą kiekvieną kartą, kai norime naudoti konkrečią įrankio versiją dabartiniame terminale. Antra, versijų sąrašą reikia parengti .sdkmanrc failą, kuris saugomas kartu su projektu.

Pirmoji parinktis skirta naudoti vieną kartą, o antroji skirta dirbti su komandomis ir dalytis konfigūracijomis tarp komanda nariai.

SDKMAN privalumai ir trūkumai!

"SDKMAN!" labai paprasta naudoti ir turi gausią palaikomų įrankių, struktūrų ir kalbų biblioteką. Ji veikia "Linux", "MacOS" ir "Windows". Kita vertus, šis įrankis orientuotas į JVM ir reikalauja autoriaus sutikimo būti tiekėju. Be to, mechanikos .sdkmanrc yra labai prastas ir gali labai sulėtinti katalogų keitimo procesą.

Norėčiau naudoti daug kitų kalbų

Jei reikia naudoti daug kalbų ir įrankių, turėtumėte peržiūrėti asdf. Ši priemonė skirta aukšto lygio įrankiams. SDKMAN! rasite daug konkrečių Java įrankių, pavyzdžiui, Bpipe arba Znai, o asdf siūlo daug daugiau įrankių, tačiau ne tokių specifinių. Žinoma, kai kurie iš šių įrankių persidengia, pavyzdžiui, Java, Tomcat arba mvnd galima rasti abiejose programose.

Kai norite naudoti asdf, turite turėti git ir garbanoti įrengtas. Po to tereikia:

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

ir pridėkite šias eilutes ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Dabar galite įdiegti mėgstamų versijų įskiepius ir įrankius.

Įskiepiais pagrįstas valdymas

Skirtingai nei SDKMAN!, asdf įrankių valdymui naudoja įskiepius. Taigi, prieš diegdami įrankį, turite įdiegti įskiepį. Grįžkime prie mūsų pavyzdinio projekto ir pabandykime sukonfigūruoti aplinką naudodami asadfsdf.

Pirmiausia turime įdiegti įskiepius:

asdf įskiepis pridėti java

asdf įskiepis add maven

asdf įskiepis pridėti mvnd

Tada galime įdiegti įrankius:

asdf įdiegti java openjdk-17

asdf įdiegti maven 3.8.4

asdf install mvnd 0.7.1

Ir dar kartą, kitaip nei SDKMAN!, asdf nieko nekeičia mūsų aplinkoje. Kai bandome naudoti java, gauname tokį klaidos pranešimą:

Komandai "Java" nenustatyta jokia versija

Apsvarstykite galimybę į konfigūracijos failą ~/.tool-versions įtraukti vieną iš toliau nurodytų versijų

java openjdk-17

Mums reikia sukurti failą .tool-versions namų kataloge, kad galėtumėte valdyti numatytąsias versijas.

Vietinės ir pasaulinės versijos

Programinės įrangos versijų atnaujinimas naudojant asdf yra gana paprasta. Tiesiog įdiegiame naują versiją. Kadangi šis procesas neturi įtakos aplinkai, galime tai padaryti bet kuriuo metu ir bet kurioje failų sistemos vietoje. Kai norime naudoti tam tikrą programinės įrangos versiją, projekto kataloge turime sukurti .tool-versions failą, kuriuo galėtų dalytis komandos nariai. Nepamirškite, kad turite užtikrinti, jog visi komandos nariai turi asdf ir įskiepiai įdiegti. Įskiepių sąrašą galite rasti čia.

Versijų konfliktai

asdf palaiko ne tik programavimo kalbas, karkasus ir įrankius, tokius kaip vim ar kubernetess. Ji palaiko ir duomenų bazes. Tokiu atveju galėtume įdiegti kelias, pavyzdžiui, "Postgres" versijas, bet veiktų tik viena jų instancija. Taip yra todėl, kad asdf vykdo komandas tiesiogiai operacinėje sistemoje be jokio atskyrimo sluoksnio. Dėl to kyla tokių problemų kaip "jau naudojamas prievadas" ir konfliktai dėl išteklių.

Privalumai ir trūkumai

asdf yra labai geras įrankis, jei norite dirbti poliglotų aplinkoje. Ji palaiko daugybę įrankių, kalbų ir karkasų. Įskiepiais pagrįsta architektūra leidžia labai lengvai tai išplėsti. Tačiau su kai kuriais jo bibliotekoje esančiais įrankiais reikia papildomai padirbėti diegiant, kad būtų pateiktos visos reikalingos priklausomybės. asdf neveikia "Windows" sistemoje, net ir WSL.

Paskutinis, bet ne mažiau svarbus dalykas - "Docker

Kai pirmiau kalbėjau apie uosto konfliktą, daugelis iš jūsų žino sprendimą.

"Docker" kai kuriais atvejais galėtų mums padėti. Paminėjau tai iš pareigos, nes šis įrankis yra toks didelis ir sudėtingas, kad negalime jo aptarti viename straipsnyje.

Kartu su "Docker" turėtume naudoti docker-compose įrankis, suteikiantis galimybę koordinuoti kelių konteinerių aplinką.

"Docker" privalumai ir trūkumai

"Docker" padeda valdyti įrankius, kuriems reikalingi tam tikri konkretūs ištekliai, pavyzdžiui, prievadai arba failai. Jis atskiria egzempliorius į konteinerius ir suteikia mums visišką jų kontrolę. Nepaisant to, "Docker" yra priemonė, kuri į mūsų darbo aplinką įneša daug sudėtingumo ir kai kuriais atvejais gali kelti problemų. Vienas iš tokių "Docker" naudojimo bandymuose atvejų aprašytas viename iš mūsų ankstesnių straipsnis.

Apibendrinimas

Žinau, kad neaprašiau visų įrankių, kuriuos galima naudoti įrankių versijoms valdyti. Jų yra daug daugiau, pvz. jEnv kuri galėtų pakeisti SDKMAN,

arba NVM kurį galime naudoti npm arba RVM svetainėje Ruby. Daugiausia dėmesio skyriau įrankiams, kuriuos "išbandžiau mūšio lauke" ir galiu rekomenduoti visiems.

Susiję straipsniai

Programinės įrangos kūrimas

9 klaidos, kurių reikia vengti programuojant "Java" kalba

Kokių klaidų reikėtų vengti programuojant "Java" kalba? Šiame straipsnyje atsakysime į šį klausimą.

The Codest
Rafal Sawicki "Java" programuotojas
Įmonių ir didinimo sprendimai

Kaip "Java" gali padėti jūsų verslui?

Sužinokite, kaip "Java" ir "Java" virtualioji mašina (JVM) padeda kurti stabilią, keičiamo mastelio verslo programinę įrangą ir kada verta rinktis "Java".

Bartlomiejus Kučinskis
Programinės įrangos kūrimas

Testų konteineriai - kaip palengvinti testus?

Ieškote būdo, kaip paprasčiau atlikti testus? Mes jums padėsime! Peržiūrėkite šį straipsnį ir sužinokite, kaip tai padaryti.

Bartlomiejus Kučinskis
Programinės įrangos kūrimas

Veiksmingi Javascript įrankiai

Atraskite keletą JavaScript paieškos įrankių, kurie padės patobulinti jūsų programavimo žaidimą. Sužinokite daugiau apie ESLint, Prettier ir Husky!

The Codest
Reda Salmi React kūrėjas

Prenumeruokite mūsų žinių bazę ir būkite nuolat informuoti apie IT sektoriaus patirtį.

    Apie mus

    The Codest - tarptautinė programinės įrangos kūrimo bendrovė, turinti technologijų centrus Lenkijoje.

    Jungtinė Karalystė - būstinė

    • 303B biuras, 182-184 High Street North E6 2JA
      Londonas, Anglija

    Lenkija - vietiniai technologijų centrai

    • Fabryczna biurų parkas, Aleja
      Pokoju 18, 31-564 Krokuva
    • Brain Embassy, Konstruktorska
      11, 02-673 Varšuva, Lenkija

      The Codest

    • Pagrindinis
    • Apie mus
    • Paslaugos
    • Case Studies
    • Sužinokite, kaip
    • Karjera
    • Žodynas

      Paslaugos

    • Patariamoji tarnyba
    • Programinės įrangos kūrimas
    • Galinės dalies kūrimas
    • Priekinės dalies kūrimas
    • Staff Augmentation
    • Atgalinės versijos kūrėjai
    • Debesų inžinieriai
    • Duomenų inžinieriai
    • Kita
    • QA inžinieriai

      Ištekliai

    • Faktai ir mitai apie bendradarbiavimą su išoriniu programinės įrangos kūrimo partneriu
    • Iš JAV į Europą: Kodėl Amerikos startuoliai nusprendžia persikelti į Europą?
    • Technikos plėtros centrų užsienyje palyginimas: Tech Offshore Europa (Lenkija), ASEAN (Filipinai), Eurazija (Turkija)
    • Kokie yra svarbiausi CTO ir CIO iššūkiai?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Autorinės teisės © 2026 The Codest. Visos teisės saugomos.

    lt_LTLithuanian
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian es_ESSpanish nl_NLDutch etEstonian elGreek pt_PTPortuguese cs_CZCzech lvLatvian lt_LTLithuanian