Self-hosted Git

În cazul în care ai nevoie de un server privat pentru Git dar nu vrei să plătești un cont Github sau Bitbucket, ai de ales între:

  1. https://about.gitlab.com/

Pentru Windows:

  1. http://bonobogitserver.com/

Mai știți și altele?

2 Likes

Asta nu e self-hosted dar este private: Springloops
Practic este integrat in project managerul BamBam, care este o solutie overall foarte buna.
Mi se pare foarte buna ideea de project manager cu taskuri/workflow, time tracking, wiki si version control.

1 Like

Stiu ca folosesti asa ceva deci am intrebari:

  • ce uptime (al functionalitatii) ai avut pana acum?
  • cum rezolvi problema cu back-up - de exemplu ce sa intampla daca ti se corup datele instant care este cel mai apropiat snapshoot?
  • ai back-up full la server sau doar la nivel de FS?

Nu administrez eu serverul pe care este gitlab dar cunosc anumite detalii:

  • nu sunt foarte sigur că înțeleg întrebarea legată de uptime;
  • backup se face zilnic prin scriptul oferit de gitlab,
  • tot zilnic se face la nivel de FS (practic o arhivă)
  • și tot zilnic se face un snapsot (la fiecare opt ore rulează un backup)

În cei vreo doi ani de când folosim gitlab nu au fost pierderi de date (nici măcar când au renunțat la Gitolite) decât o singură dată când s-a renunțat la sqlite în favoarea mysql (moment în care s-au pierdut vreo cinci issues deschise, dar pentru că au fost probleme cu upgrade-ul s-au considerat victime colaterale)

Probleme întâmpinate

Sunt două probleme în momentul de față:

  1. fișierele urcate în comentarii, issues etc nu sunt vizibile (404, aparent sunt servite altfel, nu de rails). Având în vedere că toți folosim Jing/Screenpresso/Skitch nu e o problemă prea mare;
  • mesajele de commit de genul close #12 nu închid un issue, ci doar îl menționează în issue tracker (tind să cred că e tot o chestie de configurare)

De-a lungul timpului au fost mici probleme, așa cum am zis: ba cu migrarea de la un sistem DB la altul, ba cu versiunea de Ruby/RoR (dar din câte am înțeles s-a rezolvat cu RVM), dar nimic major, nimic ce ar fi provocat downtime (ajută foarte mult că toți suntem ±2h ora României iar update-urile se fac noaptea)

Am zis al functionalitatii pentru ca ieri seara bitbucket a avut un maintenance window in care nu puteam face git push / pull deci nu puteam face deploy.

Ce am inteles din ceea ce mi-ai descris este ca daca in mijlocul zilei serverul crapa practic toate commits / issues etc. vor fi pierdute in intervalul last_backup..server_burn_down. Nu stiu daca il folositi si pentru deploys insa. Oricum acel interval larg ma cam face sa evit o astfel de solutie, uneori pot da push la 20 de commits intr-un interval relativ scurt (5-6h)

Bineinteles ca exista copiile local and all insa ma pot gandi la n combinatii in care ceva sa se poate piarda.

Ah! De acest uptime e vorba :smile: De când îl folosim nu îmi aduc aminte să fi avut vreodată probleme să nu poată cineva face push/pullj.

Îți dai seama că backup este configurat de sysadmin în felul descris mai sus; evident că poți face backup la fiecare 30 minute :smile:


Îl folosim și pentru „deploy” (chiar dacă deploy este un termen mult forțat; în producție este un webhook ce face pull de pe master, în stage face pull de pe dev).

1 Like

Noi folosim gitlab selfhosted de ceva vreme. Cateva probleme:

  1. s-a facut un update major si baietilor care s-au ocupat le-a luat vreo saptamana sa rezolve tot (lucrand cu suportul alora de la gitlab)
  2. s-ar putea sa te trezesti cu un error de 500 daca nu ii convine ceva la branchul tau si vrei sa faci un merge request
  3. e al naibii de incet cateodata (adica 1 minute sa-ti listeze branchurile)

Avantaje:

  1. l-am folosit foarte bine pe partea de code review. daca faci merge request intre doua branch-uri, iti arata foarte misto diff-ul dintre ele
  2. l-am folosit foarte bine cu git flow
1 Like

Lucrez în echipe mici, maximum trei oameni/proiect. Nu folosim PR-uri pentru că avem fix două branch-uri: dev si master. Restul sunt branch-uri locale.

Știu că la un moment dat am încercat PR-ul și mi-a trântit un 500 de toată frumusețea dar GL era într-un stadiu incipient și nu mai știu dacă a avut legătură cu instanța de care ziceam mai sus (și pe care o folosim de câțiva ani), prin urmare nu am considerat asta o problemă (am presupus că s-a rezolvat între timp).

pai, s-a rezolvat. doar 2 din 368 de merge requests au dat aia. problema era ca ajungea cumva ca branch-ul pe care incercam sa il merge-uiesc sa fie detached la ei, deci nu era stricat feature-ul de merge in sine

1 Like

Întreb aici, deși probabil ar fi o discuție separată: de ce Self-Hosted și nu Bitbucket, unde poți să ai număr nelimitat de private repos și pentru o echipă <=5 oameni e gratis?

Pentru că (dar nu limitat la):

  • politicile de securitate îți impun astfel de soluții (codul sursă nu trebuie să iasă din companie, firewal restrictiv). Ăsta e motivul pentru care atât Atlassian cât și Github oferă ceva similar.
  • Ești ceva mai ferit de flood-uri sau downtimes planificate în momentele convenabile pentru BB/GH (cum a pățit @dakull zilele trecute)
  • Un VPS capabil să ruleze o instanță Gitlab costă $20. La mai mult de zece utilizatori devine mai ieftin decât BB/GH.

Într-o vreme Bitbucket avea limită de opt utilizatori în total. Aveam patru proiecte, fiecare cu câte doi utilizatori. La proiectul numărul cinci am primit o notificare ce mă invita fie să scap de utilizatori fie să fac upgrade.

1 Like

@iamntz disclaimer: folosesc Bitbucket doar pt. proiecte personale. Github a cazut de vreo doua intr-o perioada relativ mare de timp (3-4ani) si mi-a blocat flow-ul insa in final cred ca solutia este undeva la mijloc: un mirror pe infrastructura proprie nu strica JTBS [0]

[0] Just to be sure :smile:

Pentru cei ce contribuie in comunitatea OpenSource se mai pot folosi si:

Scratch repository-urile de pe KDE mi se par cele mai fiabile, dar avantajul lui git.debian.org este ca poti trackui buguri de pe bts cu putin setup.

1 Like

Kallithea: https://kallithea-scm.org/repos/kallithea/

Suport pentru Git/Mercurial, se poate instala intern pe Windows/Linux, nu are limita de useri, etc.

1 Like

Eu folosesc de 3 ani RhodeCode. Initial era un proiect 100% Open Source (FOSS) dar la versiunea 2.0 au trecut la varianta comerciala (SaaS si self-hosted). Il folosesc ca motor de cautare prin cod/proiecte (sta foarte bine la partea de indexare), pentru vizualizare changeset-urilor + comparati si code review. M-am impacat foarte bine cu el, pre 2.0 mai apareau probleme cand faceam upgrade, dar nimic prea greu de reparat, de la 2.0 e mult mai usor sa faci upgrade.
Ar fi de mentioant ca, spre deosebire de GitLab nu are suport pentru issue-uri, dar pe mine nu deranjeaza. Pentru asta folosesc YouTrack. Si fiindca tot am pomenit de Youtrack de la Jetbrains, astept sa se lanseze Upsource (care nu e tocmai un git server, dar hei :smile:) .

Kallithea builds on work that RhodeCode GmbH released under GPLv3.

1 Like

Cei de la GitGo m-au urmarit azi pe twitter, si m-am inregistrat pe siteul lor si arata chiar bine. Aruncati o privire, nu e self-hosted dar arata bine, poti face deploy direct pe digitalocean.

Am găsit Meat! Platformă free self-hosted git, arată super.

Meat!™ is a free self-hosted Git collaboration platform with all the tools you need to develop web projects better.

Momentan downloadul se face pe bază de invitație, deși nu specifică dacă este versiune beta.
Vă anunț când primesc invitație.

Update: Am primit invitatia, Meat este beta, pentru download vine ca o imagine pentru virtualbox (fisier .ova de 2gb), cere minim 6 gb ram ca sa ruleze, asa ca am ales versiunea hosted.
Este interesant, Material Design peste tot, ca functionalitate este la fel ca celelalte.

1 Like

:frowning:

În ce limbaj e scris? Cum să ceară 6gb?!?

Și eu mă uit ca mâța în calendar. Cerințe de sistem / Instalare / FAQ
Later edit: Am vorbit puțin cu ei prin email și platforma se pare că este scrisă în java, de aceea cere minim 6GB ram. Le-am recomandat să rescrie totul acum până nu e prea târziu :slight_smile: .

1 Like