The Codest
  • O nás
  • Služby
    • Vývoj softwaru
      • Vývoj frontendů
      • Vývoj backendu
    • Staff Augmentation
      • Vývojáři frontendů
      • Vývojáři backendu
      • Datoví inženýři
      • Cloudoví inženýři
      • Inženýři QA
      • Další
    • To Advisory
      • Audit a poradenství
  • Odvětví
    • Fintech a bankovnictví
    • E-commerce
    • Adtech
    • Healthtech
    • Výroba
    • Logistika
    • Automobilový průmysl
    • IOT
  • Hodnota za
    • CEO
    • CTO
    • Manažer dodávek
  • Náš tým
  • Case Studies
  • Vědět jak
    • Blog
    • Setkání
    • Webové semináře
    • Zdroje
Kariéra Spojte se s námi
  • O nás
  • Služby
    • Vývoj softwaru
      • Vývoj frontendů
      • Vývoj backendu
    • Staff Augmentation
      • Vývojáři frontendů
      • Vývojáři backendu
      • Datoví inženýři
      • Cloudoví inženýři
      • Inženýři QA
      • Další
    • To Advisory
      • Audit a poradenství
  • Hodnota za
    • CEO
    • CTO
    • Manažer dodávek
  • Náš tým
  • Case Studies
  • Vědět jak
    • Blog
    • Setkání
    • Webové semináře
    • Zdroje
Kariéra Spojte se s námi
Šipka zpět ZPĚT
2022-12-01
Vývoj softwaru

Zvládnout více prostředí pro více projektů na jednom počítači?

Bartłomiej Kuczyński

Existuje zlatá střední cesta, jak zvládnout mnoho prostředí pro velké množství na jednom stroji? Náš expert na Javu Bartłomiej zná odpověď!

Podívejme se na typické pracovní prostředí ve firmě. softwarový dům. Máte několik zákazníků, kteří mají různá prostředí. Někteří preferují MySQL, jiní Postgres. Jedna verze vaší aplikace potřebuje Java 11 a další Java 17. Frontend potřebuje npm 12 nebo 16, protože používáte různé verze úhlové. Nakonec máte trojrozměrné pole, které obsahuje kombinace všech vašich DB, verzí backendu a frontendu. Zní to špatně, ale jednoho dne vám šéf řekne...

komiksy<em>se</em> šéfem

Kořeny prostředí multiverza

Výše popsaná situace není ničím neobvyklým. Migrace mezi verzemi jazyků nebo frameworků, aktualizace databází nebo jednoduše odlišné požadavky zákazníků mohou převrátit naruby všechny konfigurace. Měli bychom mít řešení, které pomůže nás řídit tyto změny, který odpovídá několika předpokladům a/nebo požadavkům a/nebo cílům:

  • snadné použití - jediný příkaz pro změnu konfigurace nebo verze,
  • bohatá knihovna - by měl podporovat více technologií a "věcí" (knihovny, frameworky, aplikace),
  • rozšiřitelný - měli byste nabídnout možnost přidat své zásuvné moduly.

V tomto článku se zaměřím na tři oblasti. První oblastí jsou nástroje pro Javu a JVM. Druhou jsou nástroje pro obecné použití. Třetí je způsob použití docker k dosažení našich cílů.

​

Jsem Java a pracuji na JVM

Když jste Vývojář v jazyce Java nebo obecněji pracujete s Technologie JVM, pak můžete použít SDKMAN!. Jedná se o velmi pěkný a snadno použitelný nástroj, který podporuje mnoho knihoven, frameworků a jazyků.

Proces instalace SDKMAN! Je to docela jednoduché. Musíte spustit:

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

a pak

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

Nyní můžete spravovat své Java, Scala a Maven verze.

Správa verzí - příklad

V tomto příkladu nainstalujeme a aktualizujeme verzi několika nástrojů. Jedná se pouze o malou podmnožinu dostupných nástrojů.

Instalace

Předpokládejme, že váš nový projekt používá Java 17. Nemáte žádné Java nainstalovaná verze. Chcete ji nainstalovat a navíc přidat nástroj Maven Daemon, aby se sestavování zrychlilo. Musíte tedy nainstalovat také nástroj Maven. K tomu je třeba provést tři jednoduché příkazy:

$ sdk install java 17-open

$ sdk install maven 3.8.4

$ sdk install mvnd 0.7.1

Na konci instalace každého nástroje budete dotázáni na jeho výchozí nastavení:

Chcete, aby byla Java 17-open nastavena jako výchozí? (Y/n):

To je důležité při instalaci nové verze knihovny nebo jazyka, protože SDKMAN! nastaví tuto výchozí verzi jako globální pro všechny terminály aktuálního uživatele.

Kontrola verzí a aktualizace

Čas od času je třeba aktualizovat indexy SDKMAN! Během toho se vám může zobrazit zpráva, že existují nové verze nástrojů, které používáte. Můžeme zkontrolovat, které verze jsou k dispozici, zadáním příkazu sdk ls. Pro sdk ls maven:

Dostupné verze Mavenu

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

    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



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

místní verze

aktuálně používaná

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

Jak vidíme výše, Maven má novější verzi než ta, kterou používáme. Totéž platí pro mvnd (0.8.2) a Java (19-open). Vše aktualizujme. K tomu stačí zavolat příkaz install, ale tentokrát nepoužijeme specifikátor verze:

$ sdk install maven

$ sdk install mvnd

$ sdk install java

Ale stalo se něco špatného. Maven a mvnd mají správné verze, ale Java má verzi 17.0.5-tem. To proto, že "nejnovější" verzi nástroje kontroluje jeho dodavatel, nikoli místní SDKMAN! kdo je tento dodavatel? Prodejce v SDKMAN! je někdo, kdo může zveřejnit verzi. Řekněme však, že nakonec nainstalujeme. 19-open, a my jsme ji nastavili jako výchozí, ale z nějakého důvodu potřebujeme použít 17-open.

Místní verze a správa verzí na terminálu

​
Můžeme nakonfigurovat výchozí verze nástroje, která je globální pro všechny projekty a terminály. Když však potřebujeme konkrétní verzi, máme dvě možnosti, jak to udělat. Prvním z nich je použití sdk use příkaz pokaždé, když chceme použít určitou verzi nástroje v aktuálním terminálu. Druhou možností je připravit seznam verzí v .sdkmanrc soubor, který je uložen spolu s projektem.

Zatímco první možnost je určena pro jedno použití, druhá je určena pro práci v týmech a sdílení konfigurací mezi jednotlivými uživateli. tým členové.

Výhody a nevýhody SDKMAN!

SDKMAN! se velmi snadno používá a má bohatou knihovnu podporovaných nástrojů, frameworků a jazyků. Funguje v systémech Linux, MacOS a Windows. Na druhou stranu je tento nástroj zaměřen na JVM a vyžaduje souhlas autora s tím, aby byl dodavatelem. Kromě toho je mechanikou .sdkmanrc je velmi špatná a mohla by výrazně zpomalit proces změny adresářů.

Rád bych používal mnoho dalších jazyků

Pokud potřebujete používat mnoho jazyků a nástrojů, měli byste se podívat na. asdf. Tento nástroj je zaměřen na "vysokoúrovňové" nástroje. Zatímco v SDKMAN! najdete mnoho nástrojů specifických pro Javu, jako je Bpipe nebo Znai, asdf nabízí mnohem více nástrojů, ale ne tak specifických. Některé z těchto nástrojů se samozřejmě překrývají, např. nástroje Java, Tomcat nebo mvnd jsou k dispozici v obou.

Když chcete použít asdf, musíte mít git a curl instalován. Poté stačí:

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

a přidejte tyto řádky do ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Nyní můžete instalovat zásuvné moduly a nástroje ve svých oblíbených verzích.

Správa založená na zásuvných modulech

Na rozdíl od SDKMAN!, asdf používá ke správě nástrojů zásuvné moduly. Před instalací nástroje je tedy nutné nainstalovat zásuvný modul. Vraťme se k našemu příkladovému projektu a zkusme nakonfigurovat prostředí pomocí nástroje asadfsdf.

Nejprve musíme nainstalovat zásuvné moduly:

asdf plugin přidat java

asdf plugin add maven

asdf plugin add mvnd

Pak můžeme nainstalovat naše nástroje:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

A opět, na rozdíl od SDKMAN!, asdf v našem prostředí nic nemění. Když se pokusíme použít javu, zobrazí se chybová zpráva, jako např.:

Pro příkaz Java není nastavena žádná verze

Zvažte přidání jedné z následujících verzí do konfiguračního souboru v ~/.tool-versions

java openjdk-17

Potřebujeme vytvořit soubor .tool-versions v domovském adresáři pro správu výchozích verzí.

Místní a globální verze

Aktualizace verzí softwaru pomocí asdf je velmi jednoduchý. Stačí nainstalovat novou verzi. Protože tento proces neovlivňuje prostředí, můžeme jej provést kdykoli a na jakémkoli místě souborového systému. Když chceme používat určitou verzi nějakého softwaru, musíme v adresáři projektu vytvořit soubor .tool-versions soubor, který by mohl být sdílen mezi členy týmu. Nezapomeňte, že musíte zaručit, že všichni členové týmu mají asdf a nainstalované zásuvné moduly. Seznam zásuvných modulů najdete zde.

Konflikty verzí

asdf podporuje nejen programovací jazyky, frameworky a nástroje jako vim nebo kubernetess. Podporuje také databáze. V takovém případě bychom mohli nainstalovat více verzí například Postgresu, ale běžet by mohla pouze jedna instance. To proto, že asdf provádí příkazy přímo v operačním systému bez jakékoliv oddělovací vrstvy. To vede k problémům typu "port je již používán" a konfliktům o zdroje.

Výhody a nevýhody

asdf je velmi dobrý nástroj, pokud chcete pracovat v polyglotním prostředí. Podporuje mnoho nástrojů, jazyků a frameworků. Architektura založená na zásuvných modulech umožňuje velmi snadné rozšíření. Některé nástroje, které má v knihovně, však vyžadují dodatečnou práci při instalaci, aby byly zajištěny všechny požadované závislosti. asdf nefunguje v systému Windows, a to ani v WSL.

V neposlední řadě - Docker

Když jsem výše hovořil o konfliktu v přístavu, mnozí z vás znají řešení.

Docker by nám v některých případech mohl pomoci. Zmiňuji se o tom z povinnosti, protože tento nástroj je tak rozsáhlý a komplexní, že jej nelze probrat v jednom článku.

Společně s Dockerem bychom měli použít docker-compose nástroj, který nám dává možnost koordinovat prostředí s více kontejnery.

Výhody a nevýhody nástroje Docker

Docker nám pomáhá spravovat nástroje, které potřebují určité specifické prostředky, jako jsou porty nebo soubory. Odděluje instance v kontejnerech a dává nám nad nimi plnou kontrolu. Nicméně Docker je nástroj, který do našeho pracovního prostředí vnáší mnoho složitostí a v některých případech může být problematický. Jeden z takových případů použití nástroje Docker v testu je popsán v jednom z našich předchozích článků. článek.

Shrnutí

Vím, že jsem nepopsal všechny nástroje, které lze použít pro správu verzí nástrojů. Je jich mnohem více, např. jEnv který by mohl nahradit SDKMAN,

nebo NVM který můžeme použít ke správě npm nebo RVM pro Ruby. Zaměřil jsem se na nástroje, které jsem "vyzkoušel na bojišti" a mohu je doporučit každému.

Související články

Vývoj softwaru

9 chyb, kterých se vyvarujte při programování v jazyce Java

Jakých chyb byste se měli vyvarovat při programování v jazyce Java? V následujícím díle na tuto otázku odpovíme.

The Codest
Rafal Sawicki Vývojář v jazyce Java
Podniková a škálovací řešení

Jak může Java podpořit vaše podnikání?

Než začneme, rád bych vám připomněl jednu důležitou věc. Java není jen programovací jazyk.

Bartlomiej Kuczynski
Vývoj softwaru

Testovací kontejnery - jak si usnadnit testování?

Hledáte způsob, jak jednodušeji provádět testy? Máme pro vás řešení! Podívejte se do následujícího článku a zjistěte, jak to provést.

Bartlomiej Kuczynski
Vývoj softwaru

Nástroje Javascript v akci

Objevte některé nástroje pro načítání JavaScript, které vám pomohou zlepšit vaši programovací hru. Zjistěte více o ESLint, Prettier a Husky!

The Codest
Reda Salmi React Vývojář
Vývoj softwaru

Asynchronní a jednovláknový JavaScript?

JavaScript je jednovláknový jazyk a zároveň neblokující, asynchronní a souběžný. Tento článek vám vysvětlí, jak se to děje.

Lukasz Kolko

Přihlaste se k odběru naší znalostní databáze a získejte aktuální informace o odborných znalostech z oblasti IT.

    O nás

    The Codest - Mezinárodní společnost zabývající se vývojem softwaru s technologickými centry v Polsku.

    Spojené království - ústředí

    • Kancelář 303B, 182-184 High Street North E6 2JA
      Londýn, Anglie

    Polsko - Místní technologická centra

    • Kancelářský park Fabryczna, Aleja
      Pokoju 18, 31-564 Krakov
    • Brain Embassy, Konstruktorska
      11, 02-673 Varšava, Polsko

      The Codest

    • Home
    • O nás
    • Služby
    • Case Studies
    • Vědět jak
    • Kariéra
    • Slovník

      Služby

    • To Advisory
    • Vývoj softwaru
    • Vývoj backendu
    • Vývoj frontendů
    • Staff Augmentation
    • Vývojáři backendu
    • Cloudoví inženýři
    • Datoví inženýři
    • Další
    • Inženýři QA

      Zdroje

    • Fakta a mýty o spolupráci s externím partnerem pro vývoj softwaru
    • Z USA do Evropy: Proč se americké startupy rozhodly přesídlit do Evropy?
    • Srovnání technických vývojových center v zahraničí: Tech Offshore Evropa (Polsko), ASEAN (Filipíny), Eurasie (Turecko)
    • Jaké jsou hlavní výzvy CTO a CIO?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2026 by The Codest. Všechna práva vyhrazena.

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