De belangrijkste thema’s van de release op 22 februari zijn SAST voor JavaScript, een geüpdatete Pages-functie en gemakkelijker fouten bijhouden. Laten we beginnen met het eerste punt.
SAST ondersteunt nu ook JavaScript
SAST staat voor Static Application Security Testing. Dit is een functie in GitLab die helpt om mogelijke kwetsbaarheden op het gebied van veiligheid te ontdekken. Dit gebeurt door de broncode al vroeg in het proces te scannen: op het moment iemand een nieuwe verandering doorvoert. Op die manier worden mogelijke problemen in de code opgespoord voordat ze verder worden verwerkt.
In de 11.8 versie van GitLab is – naast de bestaande node.js ondersteuning – ook ondersteuning voor JavaScript aan deze SAST-functie toegevoegd. Dat betekent dat nu ook elk JavaScript file gescand kan worden op potentiële beveiligingskwetsbaarheden.
Gemakkelijker fouten bijhouden met Sentry
Een tweede belangrijke update in de laatste release heeft te maken met het bijhouden van fouten die gemaakt worden door je applicatie. Het bijhouden van fouten is belangrijk, omdat het de gebruikservaring helpt verbeteren: het zorgt ervoor dat je fouten eerder opspoort dan de gebruikers zelf én je kunt sneller oplossingen aandragen wanneer fouten boven tafel komen.
De 11.8 versie van GitLab maakt het makkelijker en efficiënter om fouten te monitoren, door de integratie met Sentry. Sentry is een populaire open source error tracking software. Sentry zelf heeft onlangs haar eigen integratie met Gitlab verbeterd, waardoor het onder andere al mogelijk was om verdachte comments op te sporen. Met de integratie vanuit GitLab richting Sentry en andersom wordt het voor programmeurs een stuk makkelijker om fouten aan te pakken binnen de huidige workflow in GitLab.
Pages-functie geüpdatet
De derde belangrijke update heeft te maken met de Pages-functie. Dit is een functionaliteit waarmee je statische websites direct vanuit een repository in GitLab kunt publiceren. Hierin zijn twee dingen geüpdatet.
Ten eerste zijn de meest populaire Pages templates direct gebundeld in GitLab. Dat houdt in dat het nu een stuk makkelijker is om nieuwe sites te maken. De ontwikkelaar kan nu rechtstreeks van het projectscherm een nieuwe site maken, in plaats van dat hij eerst een sample repository moet forken om een nieuwe Page te maken.
Ten tweede is er nu ook ondersteuning voor de Pages-functionaliteit in subgroepen. Dat betekent concreet dat het nu ook mogelijk is om Pages-sites binnen subgroepen te maken. Het voordeel hiervan is dat je nu binnen projecten pagina’s met documentatie of andere sites kunt maken als onderdeel van de applicatie die gebouwd wordt. Ook als dat project onderdeel van een subgroep is.
Overige updates
Tot zover de drie belangrijkste updates van de meest recente GitLab release op 22 februari. Maar dat was niet het enige. Laten we nu verder gaan naar de andere wijzigingen die het werken met GitLab een stuk makkelijker moeten maken.
Approval Rules toegevoegd
Voor het bouwen van slimme software is het reviewen van code essentieel. Helaas is het niet altijd duidelijk wie degene is die de veranderingen in een nieuwe release zou moeten reviewen. Vaak is het handig om een aantal reviewers in te schakelen die verschillende achtergronden hebben, zoals mensen van de Engineering -, UX – en Productafdeling.
In de nieuwe versie heeft GitLab daarom zogenaamde Approval Rules toegevoegd. Dit maakt het makkelijker om duidelijker te communiceren wie mee zou moeten doen aan een code review. De regel laat namelijk zien wie de personen zijn die in aanmerking komen voor een code review en hoeveel reviewers er in totaal nodig zijn.
In een vorige versie voegde GitLab al de functie Code Owners toe. Dit geeft aan welke teamleden verantwoordelijk zijn voor welk deel van de code in het project. Code Owners zijn ook weer meegenomen in deze approval rules, zodat het een stuk makkelijker is om de juiste mensen te vinden.
Verbeterde ‘tussen-projecten’ triggers
Een pipeline kun je zien als een groep activiteiten die in fasen wordt uitgevoerd. Zodra een activiteit is afgerond gaat de pipeline door naar de volgende fase.
Een eerdere update van GitLab had er al voor gezorgd dat het mogelijk is om zogenaamde pipelines aan te maken die bestaan uit meerdere projecten. Dat is handig, omdat je zo projecten die afhankelijk van elkaar zijn, kunt linken. Er wordt een opvolgende pipeline getriggerd door middel van een GitLab API call.
In deze 11.8-versie is betere ondersteuning voor die triggers toegevoegd. Je kunt nu, door gebruik te maken van het trigger keyword, automatisch een opvolgende pijplijn triggeren als de bestaande pipeline afgerond is. Dat is fijn, want dat scheelt veel handmatig werk.
Verbeterde squash commit berichten
Tot slot: voor ontwikkelaars is het belangrijk dat er een Git-geschiedenis wordt gecreëerd die duidelijk en overzichtelijk is, zodat andere ontwikkelaars die in de toekomst kunnen bekijken. Aan de andere kant, als er veel kleine wijzigingen gedaan worden, is het maken van een geschiedenis daarvoor nogal bewerkelijk.
Commit squashing zorgde er al voor dat al deze kleine wijzigingen in één kleine verandering gebundeld worden, maar zorgde er tegelijkertijd ook voor dat alle commit berichten weggevaagd werden.
Dat was niet ideaal, vandaar dat GitLab er in deze versie voor koos om het squash commit bericht het standaardbericht te maken, maar ook de mogelijkheid geeft om deze te overschrijven met je eigen commit bericht.
Op naar 11.9!
Dit waren de belangrijke wijzigingen in GitLab versie 11.8. Binnenkort – eind maart – wordt versie 11.9 alweer uitgebracht. Ook dan duiken we weer de release notes in.
