Software-update: GitLab 8.15

GitLab kun je vergelijken met het bekendere GitHub, maar bevat een aantal subtiele verschillen. Het is een omgeving voor het beheren van Git-repositories on-premises en wordt uitgegeven onder de MIT Expat-licentie en ontwikkeld in Ruby on Rails. Het is beschikbaar in twee versies, namelijk de gratis te gebruiken Community Edition en een betaalde Enterprise Edition met meer functies die op grote bedrijven zijn gericht. De twee smaken worden op deze pagina uiteengezet. Het ontwikkelteam heeft GitLab 8.15 uitgebracht met de volgende aankondiging:

GitLab 8.15 Released with Auto Deploy and Web Terminal

With GitLab 8.15, we're introducing Auto Deploy (shown in the video at 1:42), which automates setting up deploys and review apps. For a Ruby on Rails project, this brings setup time to under a minute.

Plus, to make accessing your environments easier and faster, you can now access them directly through a terminal in GitLab (shown in the video at 5:18).

We want to give the power of containers, continuous integration and deployment, review apps and container schedulers to everyone. With GitLab 8.15, we take away all the hard work without hiding anything. In the demonstration we setup and deploy a Ruby application with review apps, multiple environments, chatops to a Kubernetes cluster in about 12 minutes. This typically takes days, if not weeks to setup and use without GitLab.

For many people, December is a month of celebration and gift giving. This month, GitLab was again so lucky to receive many great contributions.

The MVP of this month is Michael Munch for bringing beautifully-typeset math (LaTeX) to GitLab. Michael worked over a period of 6 months in merge requests with in total more than three hundred comments to bring this to GitLab.

We'd also like to thank Warren Postma for his contributions on the issue trackers, and the community forum and generally being a great advocate of the product and the company. And lastly, we want to thank Elan Ruusamäe and Dirk Hörner for their contributions in technical design and implementation that have given super powers to Git Hooks.

Versienummer	8.15
Releasestatus	Final
Besturingssystemen	Linux
Website	GitLab
Download	https://about.gitlab.com/downloads
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (20)

[vespino]

Kan iemand mij eens de voordelen van git uitleggen en de werkwijze bij webdevelopment? Ik werk alleen voor vele klanten en heb een eigen webserver.

[Werelds]

Tristan legt de voordelen van Gitlab en een specifieke flow uit, maar nu weet je nog steeds niet wat je aan Git an sich hebt, dus bij deze:

Als ik je reactie zo lees ga ik er van uit dat je gewoon alle bestanden op je PC hebt staan en deze via FTP upload?

Wat doe je nu als je PC bijvoorbeeld crasht? Of je hebt een grote aanpassing moeten maken die een week of twee gekost heeft en je wil terug naar de toestand voor die wijzigingen? Voor het eerste ben je aangewezen op je eigen backups of wat er toevallig op de FTP server staat, voor het tweede zul je ook een backup terug moeten zetten of alles handmatig moeten terug draaien.

Git (of SVN, CVS, Mercurial - elk VCS) helpt je in eerste instantie met het tweede geval. Er wordt een volledige geschiedenis bijgehouden (commits), waarbij jij zelf elke keer een omschrijving (commit message) moet toevoegen. Je kunt ook slechts de wijzigingen in 1 enkele commit terug draaien bijvoorbeeld, of terug springen naar een specifieke revisie. Elke commit bevat enkel en alleen de wijzigingen ten opzichte van de vorige; dus ook al heb je jaren aan wijzigingen in je repository zitten, het is niet zo dat het geheel dan gigantisch groot wordt.

Hier een voorbeeld van een project van mij:

• 0ffd1908 Updates CacheableInterfaceTests and correctly disables cache when collection cache is disabled
• bc4be820 Revamps the way query/resource cache works.
• e80146ad Query style amend
• b8d15aeb fixed broken conflict merge
• 7296efd6 added duplicate email to excluded exceptions
• e2e7ffa0 allow awards to be created

Die eerste acht tekens zijn de commit hash (deze is eigenlijk veel langer, maar het is gangbaar de eerste 8 te gebruiken), de rest is mijn commit message (of van m'n collega's - ik gebruik hoofdletters zoals het hoort ). Als ik nu bijvoorbeeld de veranderingen in 7296efd6 terug wil draaien is dat een fluitje van een cent. Hoef ik zelf geen regel code voor te wijzigen.

En daarmee kom ik ook op het andere puntje uit. Door Gitlab, GitHub of één van de vele anderen te gebruiken (BitBucket is er nog zo 1 bijvoorbeeld) ga je werken met een extra server die als enige doel heeft deze geschiedenis bij te houden. Git kun je ook gebruiken zonder server, maar dat doet vrijwel niemand. Nieuwe PC? Gewoon repository "clonen".

Daarnaast kun je zo ook heel eenvoudig met meerdere personen aan één project werken.

En wil je helemaal lekker werken? Gebruik dat repository ook in read-only modus om de site online te zetten; dus in plaats van via FTP te uploaden, "pull" je de updates naar de server toe (vereist wel SSH toegang). Doordat elke commit slechts de wijzigingen bevat, betekent dat dus dat waar jij hele bestanden zou moeten uploaden, de server nu slechts een paar KB binnen haalt voor die wijzigingen. Stuk sneller. En terugdraaien gaat dus net zo makkelijk.

[vespino]

Ik werk altijd direct op de server van mijn klant, via de FTP client van mijn editor. In de meeste gevallen zijn het nieuwe projecten of uitbreidingen op bestaande projecten waarbij de huidige site dus niet in gedrang komt en er dus los van de bestaande website getest wordt. Er is nooit sprake van een testomgeving.

Wat ik niet begrijp aan GIT is waar wordt getest? Nu pas ik een bestand aan of maak ik een nieuw bestand en deze wijzigingen staan meteen op de server van de klant. Ik begrijp dat GIT geen server is, maar "slechts" de opslag van de (historie van de) bestanden. Ik zie het voordeel van het terug kunnen rollen naar een vorige versie en werken aan bestanden met meerdere tegelijk (al is dat in mijn geval dus nooit) maar als ik bij iedere wijziging die ik doe (en dat kunnen er flink wat zijn als de site nog in test is) ook in de command line een commit moet doen om het op de server te krijgen om het te kunnen testen, dat zie ik als dubbel werk.

[Werelds]

Ah, ik zie dat je nog wel het één en ander kunt verbeteren aan je workflow.

Ik zal eerst even op het laatste inhaken: de noodzaak om de command line gebruiken; of het gebrek daar aan. Je gebruikt een editor die FTP ondersteuning heeft, de kans is groot dat deze dus ook verschillende VCS systemen ondersteunt. Ik gebruik zelf bijvoorbeeld voor vrijwel alles de JetBrains IDE's (PhpStorm, RubyMine, PyCharm). Als ik een wijziging klaar heb druk ik op CMD+K (Mac) of CTRL+K (Win), vul m'n commit message in en klaar. Vervolgens druk ik nog eens op m'n hotkey om naar de server te pushen (ik heb die op CMD+U staan, maar volgens mij heb ik dat ooit eens gewijzigd).


Nu, het testen. Jij test momenteel eigenlijk niet, je gooit het meteen live en hoopt maar dat er niets kapot gaat. Zo te horen heb je niet te maken met ingewikkelde projecten, waarschijnlijk zelfs gewoon platte HTML/CSS/JS? Dan kan er uiteraard niet zo heel veel mis gaan, maar ik denk dat je alsnog wel baat hebt bij enkele wijzigingen in je proces.

Wat je in grotere projecten zult doen is gewoon zelf lokaal een webserver draaien. Dat kan direct op je machine, via Vagrant (VM) of via Docker. Als het alleen om simpele platte sites gaat, kan ik van harte https://caddyserver.com aanraden - de configuratie van deze is super eenvoudig en de binary is piepklein.

Waarom? Omdat met een groter project een webserver niet genoeg is. Ik heb bijvoorbeeld voor vrijwel alles dat ik doe een webserver (Nginx) nodig, maar ook een interpreter (meestal PHP), een database (MySQL) en een hoop andere services (Redis, Memcached, Mailcatcher en nog wel een paar). Er komt zo veel bij kijken dat jouw werkwijze gewoon absoluut geen optie is. Dat is veel te gevaarlijk met sites die een paar miljoen hits per dag trekken.

Daarnaast heb je in een beetje werkomgeving wél een test omgeving voorhanden. Met eender welk project ik de afgelopen 5 jaar heb gedaan heb ik naast mijn lokale omgeving ook altijd minimaal een dev omgeving gehad waarnaar toe automatisch gepusht werd vanuit het VCS (dat is overigens waar deze versie van Gitlab dus mee begint, met dat te vereenvoudigen). Dus mijn commit + push naar de VCS server doet automatisch een deployment naar die omgeving. Daarnaast vaak ook nog een zogenaamde "staging" environment die bedoeld is voor pre-productie. Waar dev gewoon kapot mag gaan en rolling updates krijgt, is staging de laatste stap voordat iets live gaat - dev draait dan ook met aangepaste instellingen waar mails bijvoorbeeld niet echt verzonden worden, terwijl staging een 1:1 kopie van de live site is. Dit is waar branches in Git om de hoek komen kijken. Mijn commits maak ik altijd op "develop" (eigenlijk niet waar want ik gebruik altijd feature branches, maar dat gaat voor jou nu te ver denk ik ), waarna deze ook naar "dev" gepusht worden. Als ik een aantal commits klaar heb, "merge" ik die naar de "master" branch, die dan automatisch op "staging" terecht komen. Als daar alles goed gaat klik ik op een knopje om "master" ook naar de productie site te deployen.

Ik begrijp dat dit allemaal ingewikkeld en als veel meer werk dan nodig klinkt, maar als je grotere sites aan gaat pakken zul je heel snel willen dat je dit hebt. Ik bouw inmiddels een jaar of 15 sites en ben ooit zoals jij begonnen, maar ik zal nooit meer zonder VCS werken. Laat staan zonder minimaal een lokale of dev omgeving waar ik alles kan controleren.

Download eens een site van de FTP naar je PC. Vervolgens download je Caddy (https://caddyserver.com - standaard download zal wel genoeg zijn), zet dat bestand in de directory waar je je site hebt gezet. Maak nu een bestand aan dat Caddyfile heet (geen extensie) met de volgende inhoud:

localhost:8080

Typ nu ./caddy (Mac) of gewoon caddy (Win) in een Terminal/Commandprompt in die directory en ga naar http://localhost:8080 in je browser. Pas een bestand aan en refresh in de browser en voilá - je kunt lokaal testen voordat je potentieel de site kapot maakt met een typfout!


Edit: ik zie op je site dat je ook met Wordpress werkt, voor Wordpress sites zul je bijvoorbeeld Docker moeten gebruiken maar dat is wellicht iets te veel voor dit comment

Ik raad je aan om eens wat te neuzen op forums; inclusief GoT. Ik ben zelf niet actief in de dev sectie van GoT (zou ik wel eens moeten worden eigenlijk), maar wij hebben hier een degelijke dev community. Je mag me ook een DM sturen als je meer vragen hebt.

[Reactie gewijzigd door Werelds op 25 juli 2024 13:36]

[BugBoy]

Nog nooit zoveel amateurisme in 1 post gelezen. Ik mag hopen dat je niet professioneel opereert, want deze werkwijze past bij een hobbyist die zijn eigen website beheert (en zelfs dan zou ik het nog niet zo doen).

"Ik werk altijd direct op de server van mijn klant" en "waarbij de huidige site dus niet in gedrang komt" in dezelfde paragraaf.

Als je ontwikkelt op live systemen, dan is git niet de eerste verbetering die je in je ontwikkelstrategie zou moeten doorvoeren. Ontwikkelen doe je op je lokale omgeving. Pas als het daar allemaal goed werkt dan push je het naar productie. Pas als je dit gaat doen, dan zal git ook beter gaan passen.

GIT is ook niet bedoelt als tools om websites te deployen. Git is een source-code management (SCM) tool. Dat je dat kunt misbruiken om websites te deployen wil nog niet zeggen dat je het daarvoor moet gebruiken. De meeste websites gaan toch door een vorm van buildproces (bijv. minification) en de output daarvan is hetgeen je deployt.

[Reactie gewijzigd door BugBoy op 25 juli 2024 13:36]

[johnkeates]

SCM staat voor Software Configuration Management he ;-) Niet voor Source Code Management. Git is een gedistribueerde software configuration management en version control system. SCM/VCS dus.

[xoniq]

Ik schets even een voorbeeld:

Ik begin met een nieuw project; ik zet de basis neer, en gooit dit in de master van een Git repository. De master tak (de Repository is een boom, ik heb 1 leidende tak, dat is de master tak) bevat altijd de laatste stabiele versie.

Daarnaast maak ik een 'develop' tak. Hier doe ik al mijn wijzigingen op. In de eerste keer dat je wat in Git zit, zorg je dat je de master en develop gelijk hebt (je hebt 1 versie namelijk; de basis).

Ik ga zaken ontwikkelen en ik zorg dat ik regelmatig 'commit' op de develop tak, ik laat de master even met rust, daar commit ik pas heen als ik een stabiele versie heb die gereed is voor publicatie.

Ik blijf ontwikkelen, en committen op de develop tak, en ineens gebeurt het, ik verwijder het verkeerde bestand, of ik verwijder een verkeerde stuk code; maar druk per ongeluk de editor weg waardoor de historie van de editor weg is; en nu? The power of Git/subversion.
Nu kan ik gewoon uit git een vorige versie van het bestand pakken, of het hele geheel terug zetten naar een vorige situatie. Bestand is hersteld, of ik heb puur een stuk code hersteld, en ik ga weer verder; ik commit het weer.

Nu heb ik een stabiele versie gemaakt, dit is klaar voor productie, ik gooi het naar de master tak; en vanuit de master tak maak ik een nieuwe tak, genaamd 1.0.0. Dit is de daadwerkelijke versie die ik ga 'deployen' bij de klant.

Nu kan ik gewoon bij de klant het project neerzetten door te klonen (je hebt je eigen webserver, dus dat is ideaal). Nu heb je versie 1.0.0 bij de klant staan.

Ik ga verder ontwikkelen, weer een nieuwe feature klaar op de develop tak. Uitvoerig getest; dit is klaar. Weer terug duwen naar de master tak (remember, hier komen alleen commits die stabiel zijn), vanaf die commit maak ik weer een tak 1.0.2. (Bijvoorbeeld).

Bij de klant kan ik nu op de webserver command line iets doen als 'git checkout origin/1.0.2'. En hoppa, versie 1.0.2 draait bij de klant, zonder ook maar een code of file aan te raken.

En nu; de klant wil dat ik ga experimenteren met een redesign van de layout.
Vanaf de develop tak maak ik een nieuwe tak genaamd 'redesign'.

Ik ga opnieuw designen; puur en enkel designen. Maar wacht, de klant meld een ernstige bug die ik helemaal heb gemist.
Ik zorg dat de laatste design wijzigingen zijn opgeslagen in Git, en ik doe een checkout van develop. En nu is mijn ontwikkel omgeving weer helemaal zoals het was in de develop tak. De redesign is nu weg (maar staat wel in git).

Ik ga de bug fixen, testen, nog meer testen, ik commit veel tussendoor, en schop 'm weer naar de master. Vanuit de master komt daar versie 1.0.3 (minor bug fix).

Op de live omgeving doen we weer een checkout naar origin/1.0.3. En de bug fix is live.

Terug naar de redesign; op de ontwikkel omgeving doe ik nu weer een checkout van 'redesign' en warempel, ik kan direct verder met de redesign, zonder met bestanden te kloten, de situatie is weer zoals het was toen ik met de redesign begon.

Ontwerp is klaar, kan live. Ontwerp ga ik migreren met de develop tak; en het geheel gecombineerd nogmaals testen vanaf de develop tak, daarna doorzetten naar de master, en daar vandaan naar 1.1.0. Deze checkout ik weer op de live, en de klant heeft de redesign nu ook.

Dit is een basis scenario; ik kan gewoon alle voorgaan de commits benaderen.

In bovenstaande situatie is het ideaal als je lokaal werkt op je laptop, en de commits dus heel simpel met 1 commando kan deployen op de live omgeving.

Ook is het handig om dan lokaal tools te gebruiken als 'Sourcetree'. Is volledig gratis, en is naar mijn idee heer en meeste in visueel Git management. Daar kan je ook tussen je verschillende takken dubbelklikken om ze direct te activeren op je lokale omgeving. Als de klant een bug meld op versie 1.0.2, dubbel klik jij in die app op 1.0.2 en jij zit direct in die omgeving die de klant ook ziet.

Met 1 klik spring je terug naar de laatste ontwikkel omgeving die al voor loopt, en fix je de bug, of activeer je de redesign tak, en switch je heen en weer tussen de normale ontwikkeld tak en de redesign tak om het e.e.a te controleren.

Bovenstaand is ideaal. Nu voelt het misschien overdreven, zo was het bij mij wel, maar zodra je de 'flow' te pakken hebt, wil je niet meer anders. Mijn VPS heeft überhaupt geen FTP. Maar alles via command line, met 1 commando.

Zodra ik iets in de database moert wijzigen in mijn commit, zorg ik voor een update script die mee gaat in het project, die ik command line kan uitvoeren om database wijzigingen door te voeren direct na de checkout.

Zover een simpele scenario. Daarnaast het voordeel, vrijwel elke editor heeft Git geïntegreerd.

Amen.

[RoestVrijStaal]

als 'Sourcetree'. Is volledig gratis,

Fout, tegenwoordig heb je weer een account ervoor nodig.
Ja, ja, gratis registreren blablabla. De datalekken van tegenwoordig wijst uit dat hoe minder accounts en logins je hebt, hoe beter.

Tegenwoordig doe ik handelingen via de command line en soms gebruik ik gitk voor het inzien van wijzigingen. Werkt goed genoeg

[MonotoneJeroen]

Ik ben persoonlijk overgestapt van Sourcetree naar GitExtensions,

[RoestVrijStaal]

Die had ik gisteren nog in een test omgeving gedraaid.

De Nederlandse vertaling is lachwekkend, maar de detectie van de al geïnstalleerde applicaties is best chique. Het brengt me wel in overweging om het te gebruiken.

[MonotoneJeroen]

Ik gebruik persoonlijk bijna alle applicaties in het Engels, dit is om er voor te zorgen als ik naar iets zoek dat ik een grotere kans heb om ook iets hulpzaams te vinden Maar als er een vertalingsfout is dan is het mogelijk om een issue aan te maken.

Het mogelijk maken en detectie van al geïnstalleerde applicaties is zeker iets wat een pluspunt is voor GitExtensions. Het is ook mogelijk om plugins te maken en er zijn al een hele reeks er standaard bij.

[Tristan]

Kan iemand mij eens de voordelen van git uitleggen en de werkwijze bij webdevelopment? Ik werk alleen voor vele klanten en heb een eigen webserver.

Lees dit maar eens https://about.gitlab.com/2014/09/29/gitlab-flow/

[Verwijderd]

Leuk, ik stap net over van SVn naar Git en zocht deze feature, nu maar installeren en hopen dat ik er mee overweg kan

_{Dit kan ook alleen maar gebeuren tijdens kerst}

[xoniq]

Git is vele malen beter dan SVN. Gitlab werkt ook heel fijn.

[johnkeates]

Niet Git perse, maar zo'n bettje alle gedistribueerde VCS'en. Bazaar en Mercurial zijn ook best prima. Het probleem met Subversion maar ook CVS, Teamdinges van MS enz. zit hem in het client-server model waarbij je constant afhankelijk van een server en andere teamleden bent wat het werken eigenlijk nogal onhandig maakt.

[Verwijderd]

Niet per definitie beter maar het gaat wel de goede kant op, ik had wat extra tools nodig welke niet in Subversion Edge beschikbaar zijn.

[MonotoneJeroen]

Ze brengen ook GitLab Pages van Enterprise Edition naar Community Edition, dit hebben ze vandaag bekend gemaakt: https://about.gitlab.com/...ges-to-community-edition/

GitLab Pages is een plek waar mensen en groepen statische websites kunnen hosten, net zoals GitHub Pages.

[xoniq]

Hadden ze gister al bekend gemaakt via de mail. Wel een leuke feature om terug te zien in de CE versie. Vind het een nuttige feature.

[MonotoneJeroen]

Ik vind het persoonlijk ook een leuke feature, maakt het wat handiger om bepaalde projecten te hosten, omdat je niet alles met GitLab Markdown kan doen. En het zorgt er voor dat de URL wat netter er uit ziet.

[xoniq]

En daarnaast kan je een stukje voorbeeld code plaatsen met een praktijk voorbeeld. Ook handig binnen het bedrijf om wat voorbeeld configuraties te tonen met de bijbehorende configuratie object.