Op maandag 22 april bracht GitLab versie 11.10 uit. De focus van deze versie lag vooral op het verbeteren van het overzicht over de gehele DevOps-lifecycle: het bouwen en onderhouden van software-applicaties. Dat is belangrijk, omdat goed overzicht helpt om fouten en problemen te voorkomen. Mocht er onverhoopt toch een fout tussendoor zijn geglipt, dan is deze bovendien veel makkelijker op te sporen en op te lossen. Laten we eens kijken naar wat deze updates precies zijn.
Bekijk eenvoudig de status van je pipeline over verschillende projecten
Laten we beginnen met 1 van de belangrijkste functionaliteiten die in versie 11.10 is toegevoegd: de mogelijkheid om de gezondheid van je pipeline in te zien, ook over meerdere projecten. Een pipeline kun je zien als een set van tools om code te bouwen, testen en deployen. In sommige gevallen maken developers gebruik van pipelines over verschillende projecten. Bijvoorbeeld als er gebruikt gemaakt wordt van zogenaamde microservices. Dat is een verzameling van verschillende aparte services die losjes aan elkaar gekoppeld zijn en samen een applicatie vormen.
Het voordeel van deze manier van bouwen is dat grote, complexe applicaties sneller en beter gebouwd kunnen worden. Om goed inzicht te houden in de status van de applicatie als geheel, is het belangrijk dat de pipeline over deze verschillende projecten goed beoordeeld kan worden. En dat is met deze nieuwe functionaliteit een stuk makkelijker geworden.
Wijzigingen voorstellen voor meerdere coderegels
GitLab wil het voor ontwikkelaars een stuk makkelijker maken om op een efficiënte manier met elkaar samen te werken. Daar hoort onder andere bij dat je suggesties naar elkaar kunt doen om bepaalde stukken code aan te passen. Sinds GitLab’s 11.6 versie was het al mogelijk om een voorstel tot aanpassing van de code te doen voor één regel.
In deze versie heeft GitLab als mogelijkheid toegevoegd dat je wijzigingen kunt voorstellen voor meerdere regels code. Hoe het werkt? Je laat op een bepaald stuk code een opmerking achter met een voorstel. Een andere gebruiker – met de juiste rol – kan vervolgens met één druk op de knop het voorstel accepteren of afwijzen. Hoe simpel is dat!
Scoped labels
Labels helpen ontwikkelaars om bepaalde activiteiten die voor meerdere personen van belang zijn, zoals issues of merge requests, te categoriseren. Elk label heeft een kleur die je kunt aanpassen. Dit maakt het een stuk makkelijker om bepaalde issues of merge requests te vinden. In GitLab kon je tot nu toe project labels en group labels maken.
In GitLab Premium 11.10 is het nu ook mogelijk om zogenaamde scoped labels aan te maken. Een scoped label is een label dat gekenmerkt wordt door een ‘dubbele’ dubbele punt in de titel, bijvoorbeeld: Platform :: Android. De variabele vóór de dubbele punten wordt de key genoemd en de variabele erachter de value.
Scoped labels zijn zo opgezet dat een issue of merge request niet meerdere labels met dezelfde keys en verschillende values kan hebben. Dus stel: een developer heeft een issue met label ‘priority :: 3’. Als hij hier vervolgens een nieuw label uit dezelfde key aan toewijst, bijvoorbeeld ‘priority :: 2’, dan wordt ‘priority :: 3’ automatisch verwijderd van het issue. Op die manier voorkom je dat er een wildgroei aan labels ontstaat.
Grondiger opschonen van de Container Registry
De Docker Container Registry is een systeem dat geïntegreerd is in GitLab. Laten we beginnen met Docker: dat is een tool die is gebouwd om applicaties gemakkelijker te maken en te onderhouden. Dat doen ze door middel van containers. Met containers kan een ontwikkelaar een applicatie verpakken met alle onderdelen die van belang zijn – bibliotheken en andere afhankelijkheden bijvoorbeeld – om vervolgens alles in één pakket te verzenden. Op die manier weet de ontwikkelaar dat de app ook op andere Linux-machines werkt, ongeacht eventuele aangepaste instellingen op andere apparaten.
Met de zogenaamde images binnen Docker kan de ontwikkelaar de applicatie in een bepaalde container plaatsen en zo testen of deze goed werkt. In de Docker Container Registry ontstaan – na het doen van meerdere testen – meerdere opeenvolgende revisies van die testen. Normaal gesproken worden die verschillende revisies allemaal in het systeem bewaard, maar dat neemt veel opslagruimte in beslag. Door een bepaalde parameter te gebruiken, kunnen beheerders nu snel en gemakkelijk alle historische revisies verwijderen, om zo waardevolle opslagruimte vrij te maken.
Schaf extra CI-Runner minuten aan
Heeft jouw team een betaald GitLab account? Dan kun je nu extra CI Runner-minuten aankopen. GitLab Runner is het open source project waarmee ontwikkelaars hun code kunnen testen, om ze vervolgens terug te laten sturen naar GitLab. Zo’n test wordt ook wel een CI-Runner genoemd, omdat ze gecoördineerd worden door GitLab CI: het Continuous Integration systeem van GitLab waarmee pipelines gebouwd en getest kunnen worden.
Voorheen was het zo dat gebruikers een maximaal aantal gratis Runner-minuten hadden, afhankelijk van het soort account dat hun organisatie had afgesloten (Gold, Silver of Bronze). In GitLab 11.10 is het nu mogelijk om naast die gratis minuten extra Runner-minuten te kopen. Het voordeel hiervan is dat een pipeline – die set van tools om applicaties te bouwen en onderhouden – minder snel onderbroken wordt.
Templates voor verschillende fasen uit Auto DevOps
Auto DevOps is een functionaliteit in GitLab waarmee teams automatisch hun applicaties kunnen bouwen, testen, deployen en monitoren. Het voordeel hiervan is dat het hele proces van software ontwikkelen versneld en versimpeld wordt.
In GitLab 11.10 wordt elke activiteit binnen Auto DevOps beschikbaar gemaakt als een onafhankelijk template. Gebruikers kunnen er daardoor ook voor kiezen om alleen bepaalde fasen uit die Auto DevOps gebruiken, in combinatie met het DevOps-proces dat ze zelf hebben opgezet.
Beheer groepsleden op GitLab.com automatisch met SCIM
En tot slot: het is nu een stuk makkelijker om gebruikers te beheren op GitLab.com. Tot nu toe moesten groepsleden in GitLab.com namelijk nog handmatig toegevoegd en verwijderd worden. En dat kon beter, vond GitLab. Vooral voor bedrijven met grote hoeveelheden gebruikers is het handig als de groepsleden automatisch beheerd kunnen worden.
Daarom is het nu mogelijk om een bepaalde provider – een identiteitsplatform als Azure Active Directory bijvoorbeeld – te gebruiken als de ‘single source of truth’. Zo hoeven er niet steeds handmatig groepsleden toegevoegd en verwijderd worden als er iets verandert in de samenstelling van softwareteams.
Op naar 11.11…
GitLab laat ook in deze versie weer eens zien dat ze constant bezig zijn om het gemak voor de gebruiker te verbeteren. Hun focus lag de afgelopen maand op het verbeteren en bouwen van features die ervoor zorgen dat teams steeds meer overzicht krijgen over het werk dat ze doen. En daar worden wij blij van. Overzicht zorgt namelijk voor helderheid, en helderheid maakt de kans op fouten een stuk kleiner.
Al met al dus weer een mooie lijst van verbeteringen. Wij zijn benieuwd wat ze volgende maand voor ons in petto hebben!
