GitLab 10.2.1 (diskuse)

[cronin]

Kto používate GitLab? Myslím kto reálne prevádzkujete GitLab server, nie kto používate git repozitár náhodou uložený v GitLab-e. Podeľte sa o skúsenosti, rozsah nasadenia, spôsob integrácie, veľkosť inštancií...

[Cabrón]

Můžu i v čase minulém? S verzí 10.1.x jsem s tím definitivně seknul.

Měl jsem GL od verze 7.x na dedikovaném VPS (2 GB RAM, 20 GB storage). Nízké desítky uživatelů (v teamu je cca 20 lidí, nárazově třeba ještě 10 externistů), repozitářů desítky, celkem třeba 5 GB dat. Issue tracking v JIRA, CI nepoužíváme.

Jak šel čas, GL bobtnal, s každým minor release nové závislosti (nodejs, golang, ruby najednou), s tím rostla paměťová náročnost a klesala rychlost (back- i front-endu). Nechtěli jsme kvůli toolu na správu projektu a obarvování diffů kupovat dražší hardware, takže to šlo z domu ve prospěch gogs, ve kterém jsme se museli do jisté míry uskromnit (nemá JIRA connector například), ale nároky jsou řádově nižší. Nestartuje to minuty, nezabírá to po spuštění 1500 MB paměti, a tak podobně.

[krisko]

u nas sme presli z gogs na gitea, ktory sa vyvija trosku dynamickejsie ako gogs.

[Cabrón]

Díky za tip, to mi potenciálně vytahuje pár trnů z paty (nebo odkud) :)

[cezz]

Ono od istej velkosti teamu to prestava byt az taky problem. Mame na tom stovky developerov, takze samozrejme to chce poriadne zelezo, ale ked si priratas, ze potrebujes nejaky vykon na CI funkcionalitu, tak ten podiel ktory na celkovych poziadavkach ma Gitlab zacina byt uz celkom unosny. Stale je pravda, ze 1.5GB RAM hned po starte je sialene vela, ale pre vacsi team to nie je zas taka polozka.

Pre mensie projekty a pre moju potrebu pouzivam kombinaciu Gogs+Drone. Po starte oba dokopy zaberaju tak 100MB RAM a je to funkcne celkom dobra nahrada Gitlabu aj s CI. Mne osobne chyba len nejaky built-in scheduler - da sa to riesit Rundeckom, ale ten si ukroji dost velu cast RAM..

[Kate]

U nás je to v podobném rozsahu, ale detaily implementace neznám, jsem pouhá uživatelka :) Nějakých pár GB pro Gitlab je ovšem nejspíš pro naše adminy naprosto zanedbatelná položka…

Ale je pravda že pokud to někdo potřebuje na hezké zobrazování gitu pro 30 vývojářů, je prostě Gitlab naprosto zbytečný overkill…

[andrej]

> Nějakých pár GB pro Gitlab je ovšem naprosto zanedbatelná položka...

kto mal na esx serveroch nejake windows 2016 virtualky toho par giga pre gitlab nechava v stave blazeneho uspokojenia zo skvelej pamatovej efektivity gitlabu.

[Kate]

No, ona i jedna z našich databází udělá nejspíš z Gitlabu bezvýznamného trpaslíčka :)

[ttt]

Já ho mám už tři roky na VPS nainstalovaný pro vlastní potřebu, instalace ze zdrojových kódů. Mám v něm asi 50 hobby projektů, většina z nich má jednoho vývojáře. Používám automatické buildy a deployment, dřív jsem se nedokopal k tomu spustit testy po každém commitu. U pár projektů si tam vedu seznam úkolů.

Nenažraný je, používá Ruby on Rails. Náročnost jde trochu srazit, ale je potřeba se šťourat v nastavení (shodit počet unicorn serverů / workerů).

[archen]

No ono, kdybyste zahodili JIRu a pouzivali pro issue tracking primo Gitlab, tak na ten hardware asi mate penize

[DIK]

Vy máte v teamu 20 lidí a nemáte prachy na upgrade hardware VPS v řádech pár stovek? Zvláštní... DIk

[Ja]

Používáme gitlab pár týdnů. Máme v něm automatický build a testy, promýšlíme workflow ticketů, Cr, předávání k ručním testům a trochu nám to drhne - byli jsme příliš navyklí na trac, ale snad se to zaběhne.

[Salamek]

Pouzivam uz par let, nedavno jsem presel ze SRC install na deb verzi gitlab-ce, vse ok... (jen migrace z MySQL na Postgres byla pain)
Cca 200 projektu, 4000 notes, 2000 issues...
Pouzivam CI na test a build deb a makepkg pro arch + napojena instalace mattermost
Vse provozuji za nginx

[archen]

V nasi firme jsem uvedl Gitlab do provozu primarne pro source code. Kazdopadne uz jsem "zahodil" Jenkins ve prospech Gitlab CI, primarne delame (mikro)servisni architektury a vse mi tam funguje. Hlavne pouzivam gitlab pro deployment do DEV/TEST/QA/PROD (QA a produkce ma svou branch), takze mizi pomalu nutnost jakychkoli manualnich deploymentu, commit do master automaticky deployuje do DEV a TEST, jakmile pustim manualne pres gui commity do QA nebo PROD vetve, tak se deployjuji i tyto prostredi automaticky. Bohuzel to nelze pouzit zatim na starsi projekty -> asi by bylo hodne prace a spis se nam to jevi jako zbytecne.

Oproti JIRA se mi libi, ze muzes menit issue type. Pry nejaka drazsi verze to umi taky, ale jinak musis proste nevalidni zavrit a otevrit novej.

No a nakonec ted diskutujeme, ze bychom namisto JIRA (tu uz mame a nebude se jednoduche se ji zbavit, slouzi pro IT issue) pouzili Gitlab pro rizeni IT projektu (vyvoj software).

Co se featur tyce, tak bych chtel dynamicky board, kde si muzes nastavit sam, ktere projekty, nebo skupiny se ti maji zobrazovat, uz existuje feature request ale bez planu. https://gitlab.com/gitlab-org/gitlab-ce/issues/21497

Taky se mi nelibi, ze jsou groupy nejsou genericke, abych si usetril praci, tak jsem vytvoril 3 skupiny ne pro projekty, ale jen pro lidi (internal, external_company_1, external_company_2), projekt samotny muzes sdilet se skupinou. Ale skupinu se skupinou ne, neni to genericky navrzeno.

Jinak se mi ale taky zda, ze je Gitlab takovy liny, mi to nekdy prijde, jak kdyz zere pamet, cpu, ale jen naoko, a doopravdy nic nedela

[cronin]

Ako je na tom zabudované CI v GitLab-e v porovnaní napr. s Jenkins-om?

[cezz]

Je to skor podobne niecomu ako Travis, Drone, Concourse a podobne. Podla mna omnoho lepsie ako Jenkins, ale zalezi co od toho ocakavas.

Vela ludi ma rado Jenkins, lebo tam mas milion pluginov na cokolvek, ja osobne to povazujem za najvacsiu nevyhodu Jenkinsu.

[xxx]

Migroval jsem z Jenkinse na Gitlab. Na Jenkinsi me stvalo, ze to vlastne bez pluginu nic neumi, a posbirat spravnou kombinaci pluguinu a nastaveni, bylo dost obtizne. Navic i kdyz uz to clovek dotah do konce, tak to cely pusobilo dost chatrnym dojmem.

Velky rozdil vidim v tom, jak bych to nazval, ze Gitlab je tak nejak "commit driven". Tedy, ze akci, ktera spousti build, je commit, a vsechny parametry co to ma udelat, musi byt v repozitari. Postupne se to sice oslabuje, jak se postupne rozsiruji moznosti triggrovani pipeline.

Jenkins je oproti tomu zalozen na dashbordu, kde se primarne ocekava, ze akce je spustena uzivatelem. (Samozrejmne vim, ze ji muzu poustet automaticky pri commitu).

Ten GitLabi pristup ma podle mne vyhodu, ze udrzuje navod jak projekt zbuildit vzdy aktualni, a kdyz prijde nekdo novy do tymu, tak mu staci rict, at se podiva do .gitlab-ci.yml.

Dale je vsechno pohromade, a neni treba se bat, co bude poptreba delat, kdyz se Jenkins rozsype.

Na druhou stranu, jsme treba byli zvykli, ze si manager na Jenkinsi pusti Job s parametry. To s GitLabem nepujde pokud se nezvetsi IQ managera, nebo pokud se mu nenaprogramuje dashboard.

[Dirka]

Uprimne, nechci ti brat iluze, ale vse co popisujes Jenkins umi, tzn mame komplet definici jobu v p4 a pokud se zmeni, tak se trigrem updatne pouze job, pokud se posle commit do kodu, pusti se kaskada (build, iso, install, testy) etc ... nicmene chapu, ze pokud nekdo nastavuje Jenkins rucne, tak to je na maslu :)

[xxx]

To chapu. Muzu mit Makefile a z Jenkinse volat akorat make all. Muzu jit dokonce tak daleko, ze v Jenkinsi neni jedinej plugin a vsechno delam v shellovem skriptu vcetne checkoutu z Gitu. Jo, pokud ti bezi build na Linuxu, tak si to jeste dokazu predstavit. Nam musi bezet bohuzel build na Windows.

[Dirka]

To si uplne nerozumime, bavim se o komplet definici Jenkins jobu vcetne kdy co a jak, jen to mame ulozeny v p4 a udelali sme si malej skript kolem, toto vse jede nad 5k+ projektama (linux, ant, vs2017, cordova, robot framework, squish a urcite sem na neco zapomnel).

Jediny co tim chcu rict, ze existuji ruzny pristupy a nemam rad nazory system abc je blbej proze def, snad se chapeme.

[xxx]

Tak to ja si s dovolenim ponecham nazor, ze Jenkins je blbej, a napsal jsem i proc. Na druhou stranu neni natolik blbej, ze pokud ti vsechno funguje, aby z nej bylo potreba migrovat.

[Dirka]

Uprimne reakce, kde rikas ze potrebujete Win, ja ti odpovim, ze neni problem (ano mame 2k8 - 2k17 VS buildy) a ponechani nazoru ti neberu. Spis bych ale cekal u abc, ze se vic rozepises o tech konkretnich (technickych) problemech, obecna omacka nikomu nic nerekne. Muze to nekomu dat neco do budoucna.

[cezz]

Ono ide aj o to, ze v pripade Jenkinsu musis trosku vybocit z vyslapanej cesty aby si dosiahol konfiguraciu o akej pises. Ides tak trochu proti systemu. Kdezto pri Gitlab-CI by si naopak musel ist proti systemu aby si taku konfiguraciu nedosiahol.

Predpokladam ze pouzivate declarative-style Jenkinsfile, ktory uz sa ako tak blizi yml konfiguracii v inych systemoch co sa citatelnosti tyka. Mne osobne sa to stale zda take dost neprehladne a zbytocne komplikovane oproti napriklad .drone.yml, ale to je vec nazoru.

Stale to musis cele znasilnit nejakym pluginom aby si mal build spusteny v Docker kontajneri, inak si zas len odkazany na to, ze ti niekto nerozbije build environment a zas je to stav ktory udrzujes niekde mimo Gitu. (alebo p4) Ked to porovnas s Gitlabom ktory ti v podstate automaticky nastavi Kubernetes (zvlast ak Gitlab samotny je Kubernetes aplikacia) a cele to funguje s kontajnermi tak nejak samo od seba..

Takze suhlasim, Jenkins sa da pouzivat aj vo forme aku opisujes, ale nie je to zadarmo a vyzaduje to istu davku sebakontroly. Zvlast ak je dovod pouzivania Jenkinsu ten, ze to "developeri uz poznaju", co zvycajne znamena, ze novi zamestnanci su zvyknuti nainstalovat milion pluginov a vsetko si naklikat. (pretoze tak to vacsina developerov pozna)

[Dirka]

Pokusim se o tom, jak pouzivame Jenkins napsat blog, az bude cas, chapu, ze gitlab-ci je zrejme primejsi cesta, pokud clovek chce jen build, ale chybi me tam integrace na ruzny test tooly a podobne, takze to nevidim jako ultimatni reseni = chcu videt vysledky gui testu, treba je i rovnou zalogovat nebo pri pristim buildu zavrit a dokud to muj nastroj nema, tak je problem.

Pokud toto gitlab-ci umi, budu rad za priklady pouziti s Robot frameworkem a Squishem.

[cezz]

Rad si ten blog precitam. Nase aplikacie obecne povedane nemaju GUI, takze testy s vystupom len do build logu nie su problem. Viem, ze je par timov, ktore si Jenkins zivia prave koli itegracii ako spominas ty, ale u nas je to relativne minimum aplikacii.

Nechap ma zle, netvrdim, ze Jenkins je vyslovene zly. Ma svoje uplatnenie, o tom nepochybujem. Ale co mam moznost pozorovat, tak na Gitlabe sa bez velkej namahy uzivia desiatky-stovky projektov a nie je to zasadny problem adminovat, kdezto tych par projektov co si zivia Jenkins ma podchvilou nejake problemy. (ale, pravda, niekedy si clovek nepomoze)