Op 22 juli 2019 werd GitLab versie 12.1 gereleased. In dit artikel kijken we, zoals je van ons gewend bent, naar de laatste ontwikkelingen. Deze release staat in het teken van een aantal nieuwe functionaliteiten zoals Parallel Merge Trains en Merge Requests voor Confidential Issues. We kijken wat dat precies is en wat je ermee kunt.
Parallel lopende Merge Trains voor verbeterde Continuous Delivery
In GitLab werk met je zogenaamde branches. Al die branches vertegenwoordigen een onderdeel in het softwareontwikkelproces. In het kader van Continuous Delivery is het belangrijk dat teams dit proces zo soepel mogelijk doorlopen. Eén van de indicatoren daarvan is dat de master branch groen is. Zo niet, dan loopt er iets niet helemaal lekker. Het resultaat: de productie stopt en de nieuwe code wordt niet live gezet. En dat zorgt weer voor een lagere gebruikerstevredenheid.
We houden de branches dus het liefst groen, om continu goede code te kunnen releasen en het softwareproduct daarmee te verbeteren. De enige manier om ervoor te zorgen dat de master branch groen blijft zodra nieuwe code wordt toegevoegd, is door altijd de laatste versie van die master branch te gebruiken.
Voor teams die vaak mergen, kan dit lastig of zelfs zo goed als onmogelijk zijn. Een pipeline heeft namelijk tijd nodig om nieuwe code te verwerken, maar in diezelfde tijdspanne kunnen er alweer nieuwe veranderingen ingevoerd zijn. En dan ontstaan er conflicten. De enige manier om zo’n conflict te voorkomen, is door gewenste veranderingen in een wachtrij te plaatsen en ze 1 voor 1 door te voeren.
Om dat proces gemakkelijker te maken, bedacht GitLab Merge Trains. Met behulp van de Pipelines for Merged Results, zorgen Merge Trains ervoor dat merges in de goede volgorde in de wachtrij geplaatst worden. Op die manier worden merges in de juiste volgorde verwerkt, zelfs als ze vaak en snel achter elkaar toegevoegd worden.
Gevoelige informatie privé verwerken
In de cloud werken is een mooie manier om met mensen over de hele wereld aan nieuwe ideeën te werken. Open source-softwareprojecten bijvoorbeeld, waarvan de broncode door iedereen te bekijken en bewerken is. Zoals we eerder ook bespraken, is GitLab een grote voorstander van zulke open source-projecten: hun visie is dat openheid en transparantie ontzettend veel voordelen met zich meebrengt.
Maar GitLab is zich er ook van bewust dat sommige informatie van publieke projecten beter niet wereldwijd gedeeld kan worden. Het bedrijf geeft als voorbeeld dat softwareteams bekende beveiligingslekken liever privé houden terwijl ze nog aan de oplossing ervan werken. Op die manier lopen ze een minder groot risico dat de lekken doorbroken worden. GitLab zorgde er eerder al voor dat je issues in openbare projecten vertrouwelijk kon maken met Confidential Issues, maar het was nog niet mogelijk om ook vertrouwelijke merge requests toe te voegen. Daarvoor moest je de merge requests eerst apart verwerken in een besloten repository.
Dat was wat bewerkelijk, vandaar dat GitLab Merge Requests for Confidential Issues toevoegt in deze versie. Het enige dat een gebruiker hoeft te doen, is op Create Confidential Merge Request klikken bij een Confidential Issue. Dit zorgt ervoor dat je een privé fork aanmaakt, waarbinnen je een nieuwe branch en merge request kunt aanmaken. Op die manier blijft alles onder de radar, totdat de tijd rijp is om de code te onthullen en te mergen met de openbare code.
Krijg automatische HTTPS-certificaten voor GitLab Pages die Let’s Encrypt gebruiken
GitLab Pages is een functionaliteit waarmee je eenvoudig webcontent kunt publiceren: van landingspagina’s tot documentatie en rapportages. Vandaag de dag is het natuurlijk cruciaal om je bezoekers een veilige surfervaring te bieden met HTTPS. Alleen: het inkopen van deze certificaten, ervoor zorgen dat je webpagina zo’n certificaat heeft én deze op tijd weer vernieuwen, kan een tijdrovend klusje zijn. En dat wordt nog uitdagender op het moment dat je veel verschillende domeinen moet onderhouden.
De GitLab-community vertelde GitLab dat het automatiseren van dit proces voor GitLab Pages heel waardevol zou zijn. Vandaar dat GitLab deze feature heeft gebouwd en heeft toegevoegd in deze versie. Vanaf nu is het dus een stuk makkelijker om beveiligd webverkeer richting je GitLab Pages te ontvangen voor al je verschillende (sub)domeinen. Het enige dat je daarvoor hoeft te doen, is een schakelaar aanzetten in je Pages-instellingen.
Git object deduplication
Het forken van workflows maakt het een stuk gemakkelijker om aan projecten mee te werken. Op die manier kun je namelijk eerst in een kopie van het project werken, zonder dat je meteen aanpassingen doet in het hoofdproject. Het nadeel hiervan is alleen dat er soms veel opslagruimte gebruikt wordt. Om die reden heeft Gitlab de functionaliteit Git object deduplication gebouwd: deze vermindert de benodigde opslagruimte door middel van een object pool.
Groepen als code-eigenaren toewijzen
Voor ontwikkelaars is het niet altijd duidelijk wie hun changes moet beoordelen. Het was al mogelijk om individuele beoordelaars aan changes toe te wijzen door middel van hun gebruikersnaam of e-mailadres.
In sommige gevallen is het echter fijner om de code aan een groep toe te kunnen wijzen, bijvoorbeeld als teams of rollen veranderen. Op die manier voorkom je dat het proces stokt als een beoordeling uitblijft omdat iemand van rol is veranderd. In versie 12.1 kan de beoordeling daarom door elke persoon in een toegewezen groep opgepakt worden.
En nog veel meer…
Dit waren wat ons betreft de vijf belangrijkste nieuwe functionaliteiten in GitLab 12.1. Maar zoals we van GitLab gewend zijn, hebben ze de afgelopen tijd aan nog veel meer moois gewerkt. Check daarvoor de complete Engelstalige releaseupdate.
