Komentáře k článku

Jak vypadá naše vývojové prostředí

Někdy před rokem jsme se rozhodli – snad finálně! – vyřešit problém, že i když používáme multiplatformní technologie jako je Node.JS, tak ve výsledku má každý vývojář mírně odlišný systém, což způsobuje, že kód, který je funkční na jednom počítači, není funkční na jiném. Cestou se na naše řešení nabalila i jiná pozitiva, a o tom všem si v článku povíme.

Zpět na článek

18 komentářů k článku Jak vypadá naše vývojové prostředí:

  1. karel

    produkce
    Docker na vyvoj moc pekna vec.
    Ceho ja se dost obavam je ze se zacne cim dal tim vic docker pouzivat i na produkcni servery pokud to bude jen pro localhost nebo vlan tak s primhourenim oka ok, ale porty ven auu. Narazim na to jak nekteri radi ne-aktualizuji se slovy, kdyz to bezi tak na to nesahej.

    1. Snow

      Re: produkce
      No i v tom je výhoda kontejnerů…
      Zauktualizuju kontejner, zjistím že je vše OK, případně vyřeším problémy a nasadím. Mám totiž jistotu že když mě aplikace běžela jinde, poběží stejně i na konkrétním serveru, protože kontejner :-)

      Když kontejner nemám, raděj to nechám vbežet když to běží i třeba neaktuální.

      To samé jak se pak krásně mění železo, vezmu kontejner a pustím ho kdekoliv a kdekoliv poběží stejně…
      Neříkám že má smysl na každej prd používat kontejnery, ale na některé věci to smysl má a na produkční určitě.

  2. David K.

    Windows
    Zajímavý článek. Co používáte na sdílení souborů mezi Windows a VM běžící na Vagrantu? Zkoušel jsem shared folders, ale tam je problém se symlinky. Tak jsem nakonec skončil s tím, že jsem nainstaloval Sambu a připojil jsem si jí do Windows jako sdílený diskový oddíl. Ale občas je to poněkud pomalejší, například phpStormu docela trvá, než detekuje změny v souborech.

    1. Michal P.

      Re: Windows
      Sdílení souborů mezi Windows a VM ve virtualboxu (Vagrantu) je obecný problém. Všem, kteří běží pod Linuxem, Mac OS doporučujeme aktivovat sdílení přes NFS. Vývojáři na Windows však většinou používají klasické shared folders. S trochou snahy se dá NFS rozchodit také pod windows s pluginem vagrant-winnfsd, ten má však svoje mouchy a při testech se choval nestabilně. Symlinky jsou také jedním z problémů, ale to se dá vyřešit poměrně jednoduchou úpravou Vagrantfilu a instalací vagrant pluginu vagrant-vbguest např.:

      vagrant plugin install vagrant-vbguest

      vb.customize [„setextradata“, :id, „VBoxInternal2/SharedFoldersEnableSymlinksCreate/vagrant“, „1“]

  3. Jakub M.

    Údržba na vývojářských stanicích
    Jak řešíte to, aby všichni mohli v klidu vyvíjet a nemuseli bojovat s nastavením tohoto vývojového prostřední? Podle článku to zní, že celý proces není zdaleka bezproblémový a pokud se něco pokazí třeba na virtualizaci, tak je například takový UI vývojář v pasti.

    Zatím se mi nejvíce osvědčilo maximální část centralizovat – mimo jiné pro nás důležitá výhoda je, že k tomu, aby viděl stejnou chybu jako kolega, stačí většinou jen aktualizovat repozitáře.

    Pokud bych tedy chtěl spustit něco pro každého vývojáře zvlášť, tak bych zkusil dát všechny instance vaším způsobem na jeden server. Zkoušeli jste něco takového?

    1. Lukáš HavrlantAutor příspěvku

      Re: Údržba na vývojářských stanicích
      S nastavením vývojového prostředí bojuje náš admin, my ostatní ho jen používáme. Pro vývojáře to v praxi znamená každé ráno zaktualizovat prostředí, čímž získáme aktualizované definice Docker kontejnerů nebo aktualizované Mongo dumpy. Pokud se něco pokazí, obvykle stačí jen restartovat všechny Docker kontejnery nebo restartovat celé prostředí a zase to začne fungovat.

      Tomu poslední odstavci moc nerozumím, tak nemůžu odpovědět :-).

      1. Jan K.

        Re: Údržba na vývojářských stanicích
        Jak u vás vzniká nová microapps? Zvládne to i běžný programátor nebo to je magie pro guru? V hledáčku jsme nedávno měli i podobný systém, ale při testování se nám to prostě nelíbo, je to příliš neflexibilní, problémy mají zásadně win/osx vývojáři, kteří si s tím moc neporadí, linuxákům je vesměs vše jedno a vyřeší si to sami.

        Co nám vadilo:

        • dlouhá aktualizace, každé ráno by měl každý vývřojář stahovat stovky mb až několik gb dat, v momentě když jsme začali řešit lokální reverzní proxy s přednačítáním, byla to stopka
        • udělat si vlastní mikroslužbu nebo vyzkoušet novou databázi bylo příliš komplikované
        • pokud se vyskytl netriviální problém, získat stav (image) z vývojářova stroje bylo prostě časově náročné
        • přílišna náročnost velkou část služeb a databází spustit na vývojářově stroji (stovky mikroslužeb) a s tím i komplikované zjisťování závislostí
        • vývojáři neřešili performance a často navrhli nevhodné modely nebo jejich řešení nebylo škálovatelné, opravy a kontroly zabraly dost času
        • načítání frontendů bylo příliš rychlé a pozornost se tolik nevěnovala UX při horší latency
        • pro tým testerů bylo velice komplikované a časově náročné vše stahovat k sobě, distribuce testovacích databází v tomhle pokulhávala a špatně se nám to udržovalo zároveň s vývojem kódu

        Tím narážím i na poslední otázku předřečníka, ptal se, jestli máte vývojový společný dev server, kde by tyhle containery běžely a vývojáři je mohli používat.

        Narazili jste už na nějaký z těhle problémů a případně počítáte s nimi nebo to už máte nějak vyřešené?

        1. Ondřej

          Re: Údržba na vývojářských stanicích

          • Novou aplikaci zakládá obvykle náš guru, ale zvládl by to i obyčejný programátor, kdyby bylo potřeba (já to zvládl, když jsem tam integroval statistiky). Nové aplikace nezakládáme zase tak často, takže to není problém.
          • Ranní aktualizace trvá asi patnáct, dvacet minut. Stáhnou se aktuální verzi Dockerfilů, databázových dumpů, zbuildí se znova kontejnery a následně se pullnout projekty. Zatím to není problém a dá se to stihnout během ranní kávy nebo ranní porady, takže to moc nezdržuje. Asi nemáme řešení pro případ, kdy by to lezlo do stovek kontejnerů.
          • Pokud se vyskytne netriviální problém, zavolá se guru, který ho chudák musí vyřešit. Většinou ale stačí restart některé ze služeb.
          • S náročností velký problém nemáme, i když jsme třeba už párkrát museli upravovat watche, aby nesledovaly úplně všechno. Ale máme desítky služeb, ne stovky.
          • Performance cíleně také neřešíme, ale produkt už je reálně nasazený a zatím o stížnosti na performance nevím. Je možné, že jsme to navrhli blbě, ale to ukáže až čas.
          • V produkci neběžíme na Dockeru, tam je to releasnuté bez něj. Není tedy problém releasnout to na ještě jeden server pro testovací účely. Vývoj ale probíhá výhradně v Dockeru&Vagrantu. Tedy ne že by to byl nějaký příkaz přes který nejede vlak, ale zkrátka to funguje a je to nejpohodlnější.
            1. Jan K.

              Re: Údržba na vývojářských stanicích
              Díky za odpověď :). Ano, jen nás ve firmě přes sto programátorů a mnoho týmů, aplikace nám běží napříč všemi kontinenty, technologií používáme několik desítek, proto jsme narazily na již zmíněné problémy.

              Přeji tedy hodně úspěchů s vaší architekturou a doufám, že za rok se podělíte s novými zkušenostmi.

              1. Lukáš HavrlantAutor příspěvku

                Re: Údržba na vývojářských stanicích
                Díky :).

                Klidně podělím, bude-li se o co podělit. My už totiž daný projekt spíše doděláváme, takže nepředpokládám, že bychom ještě vytvářely hromady nových kontejnerů. Nejspíš už se toho na současném stavu moc nezmění.

  4. Kapral

    Stáhli jste si zdrojáky webového UI, rozjeli jste ho, ale nefungovalo vám, protože jste si zapomněli ručně stáhnout jednu chybějící knihovnu.
    Po stažení se sice UI rozběhlo, ale moc toho nefungovalo, protože jste zapomněli spustit backendový server.
    Spustili jste backend, ale nefungovaly statistiky, protože jste u sebe měli starou verzi backendu.
    Napsali jste nějaký kód, vyzkoušeli jste ho, otestovali, commitli&pushli a po chvíli vám přišel email z Jenkinsu, že neprošly unit testy, protože máte lokálně jinou verzi testovacího frameworku, než je na Jenskinsu.

    Všechny tyhle body na mě působí spíš tak, že vývojář je prase a závislosti nebo tasky pro npm/composer/bower/gulp/grunt/… nenadefinoval správně. Pokud potřebuju knihovnu ve verzi 16.5.2, tak snad příslušnýmu package manageru tohle sdělím. Pokud je v projektu prostor proto, aby do něj vývojář stáhnul jinou verzi libky, tak je to fail.

    Osobně vidím sílu kontejnerů spíš v tom, že na různých prostředích se app může chovat jinak a pokud má každý vývojář jiný OS, používá jiný webserver apod. tak dochází k problémům. Zde je to opravdu užitečné.

    Ještě bych rád upozornil na to, že vagranty a dockery nejsou zrovna 2x bezpečné.

    1. Lukáš HavrlantAutor příspěvku

      Re:
      Něco jsme předtím měli blbě, to je jasné — i proto jsme do toho Docker&Vagrantu šli. Nicméně jedna z chyb byla třeba ta, že někdo měl nainstalovanou jinou verzi boweru, takže i když jsme v definici bower balíčků měli vše správně, tak to někomu nefungovalo. Docker&Vagrant kombinace nás zkrátka odstiňuje od téměř všech podobných problémů.

    2. Zdeněk Tisoň

      Re:
      S tím UI máš pravdu, ale naše prostředí se skládá z mnoha oddělených mikro služeb, které spolu komunikují pomocí různých kanálů (kafka, zeromq, http) a tady už ti moc správně napsaný soubor pro package manager nepomůže.

    3. wsh

      Re: bezpečnost

      Ještě bych rád upozornil na to, že vagranty a dockery nejsou zrovna 2x bezpečné.

      Můžeš to nějak víc rozvést? V použití docker kontejnerů vidím v produkci vidím určité výzvy (třeba aktualizaci bundlovaných programů a knihoven), ale paušálnímu prohlášení, že nejsou zrovna bezpečné úplně nerozumím.

      1. Jan K.

        Re: bezpečnost
        nejspíš není myšlena bezpečnost samotných technologií, ale stav, kdy používáš veřejné neověřené containery, které mohou kdykoliv aktualizací způsobit průnik zákeřného kódu nebo shodit celou produkci.

        V produkci prostě nesmí být nic, co nemáš sám pod kontrolou a co nevytváří tvoji admini. Docker/Vagrant není technologie primárně pro bezpečnost, ale šiřitelnost a přenositelnost.

        1. wsh

          Re: bezpečnost
          To se ale příliš neliší od stavu, kdy se aplikace instaluje pomocí composer, npm, bower apod. z desítek až stovek externích repositářů, které také nemáš pod kontrolou. Pokud to firemní procesy dovolí, bude se to dít s dockerem i bez něj. Naopak pokud admini udržují ověřené image, mohou pak díky dockeru stejné používat vývojáři na svých stanicích.

          1. Jan K.

            Re: bezpečnost
            ano, s tím plně souhlasím. Docker to riziko nepřináší, ono v té firmě už musí být zakořeněné.

            S dockerem je ale ještě jiná věc, na kterou narážíš v poslední větě, často ho používají pouze programátoři, kteří si tohle nedokážou zkontrolovat. Pokud je tým adminů, kteří udržují kontainery, je to v pořádku, pokud ale o kontainery se starají programátoři, je zadaěláno na průser.

            Kontrolou ideálně musí projít vše, ale php programátor bez komplikací zkontroluje/projde composer balíček, naopak už těžko docker obraz, pokud zároveň není admin.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=15144