Over CI/CD met Rik de Groot en Gerard van Engelen

Welkom bij de nieuwe aflevering van de CodeKlets podcast. De hosts van vandaag zijn Saber en ik. Zo Saber, dat is al weer lang geleden dat we zo met z'n tweeën zitten. Ja, dat kun je wel zeggen. De laatste keer was hij hier ook, we zaten echt met z'n zessen, maar dat was de aflevering voor Verlienen die jij weer had opgenomen. Ja, klopt. Maar dat was ook alweer een tijd geleden, zeg maar, dat was ook wel gezellig. Maar ja, we moeten wel vaker opnemen. Ja, dat is het idee, anders zien we elkaar niet zo vaak en ja, dan hebben we niks te delen met de wereld en dat willen we natuurlijk wel. Ja, het was ook heel erg gezellig zo met z'n zesjes. Oké, maar goed, wat zag ik nou, ben jij flink aan het editen geweest de laatste tijd? Ja. Dat moest wel even beter. Ja, want ik had die belofte volgens mij er eens een keer gedaan dat ik de eerste aflevering nog een keer zou gaan editen om de geluidskwaliteit weer wat op te schroeven. Want dat had ik volgens mij redelijk verpest de eerste keer. Maar ja, goed, het enige nadeel, daar zit nog wel een raar ratelingetje in die aflevering. Dat heb ik er niet allemaal uit geknipt, want dat was echt monnike werk. Maar hij is een stuk beter te beluisteren, dus dat lijkt me heel handig. Wat is de eerste aflevering? Dat is eigenlijk de kennismaking en het is een beetje jammer dat mensen afhaken als ze die aflevering horen. Dus ik hoop dat dat bevalt. Ja, ik zou zeggen, ga het luisteren, onze allereerste aflevering. Ja, die is dus een heel mooie, veel mooier qua geluid. Nou, dankjewel dat je dat nog hebt kunnen, daar heb je veel tijd in gestoken. Ja, jongen, zes jaar ongeveer. Maar we bestaan wel drie jaar. Nee, nee, het op zich, het editen was ja, redelijk snel. Omdat dat nu gewoon door ervaring, want nu knip je gewoon veel sneller dan dat je in begin deed. En geluidskwaliteit heb je gewoon online tool die ik gebruik, want dat is gewoon luiheid. En daar gooi ik alles in en dan normaliseert hij het en dan. Wat ook tof is trouwens, er zit overal AI in en je kunt een transcription, ik hoor de laatste iemand in Nederland zeggen, ik vind het heel raar klinken, transcriberen volgens mij. Transcriberen, ja. Klinkt niet. Maar goed, dus en dan komt er gewoon echt een goede tekst uit, gewoon Nederlands. Dus dat viel me echt heel erg mee. Maar ja, heb je weleens zoiets in Teams ook geprobeerd en dan van van en dan probeert hij volgens mij van Engels, Nederlands proberen te vertalen. Nou, echt, je ligt helemaal in de deuk wat hij ervan maakt. Maar dit gaat op zich goed, dat model, want blijkbaar zijn Engels is natuurlijk ja, waarschijnlijk de taal waar het meeste van te vinden is. Maar waar het model het beste van is, dat geloof ik ook wel. Maar Nederlands doet het echt wel goed, dus dat hadden we toevallig in de vorige aflevering over dat bepaalde Afrikaanse talen, die hebben dus gewoon, dan werkt het dus gewoon niet bij omdat er gewoon te weinig materiaal is om op te trainen. Dus dat is een beetje jammer, maar we hebben blijkbaar een beetje gelukt met de Nederlandse taal. Maar goed. Heel goed man. Nou, ja, hartstikke mooi. Nou, ja, deze aflevering is ook weer wederom bijzonder. We hebben twee hele interessante gasten uitgenodigd om eens te praten over continuous integration en continuous delivery. Onze gasten van vandaag zijn Gerard van Engelen en Rick de Groot. Nou, leek het ons wel even leuk om jullie even zelf jezelf even te laten voorstellen. Dus ik begin even hier links van mij dan. Rick, zou je misschien jezelf aan de luidsrads kunnen voorstellen? Dat lukt me wel, denk ik. Ja, ik hoop het. Ik ben Rick, dus ik ben net veertig geworden, dus ik zit midden in mijn midlifecrisis op het moment. Dus... Kunnen we het ook even over hebben, hoor? Nou, dan zitten we nog wel even, denk ik. We moeten het een beetje binnen de tijd houden, toch? Anders op podcast, denk ik. Ja, ja. Ik heb natuurkunde gestudeerd, ik heb heel veel gestudeerd, maar uiteindelijk natuurkunde gestudeerd. En sinds ik afgestudeerd ben, werk ik in de software. Eerst als tester, later als developer. Ja, dat is nu ongeveer 15 jaar. Ik weet niet meer precies, maar... En ik woon in Maartstijk, in de buurt van Utrecht. Ik heb twee kinderen. Een jonge en een meisje. Die ik ook een klein beetje probeer warm te maken voor software development. Maar veel verder dan gamen, komt tot op het moment nog niet. Hoe oud zijn ze nu? 10 en 9. Dus de oudste is net 10 geworden. Naar 10 is ook wel een half jaar. Die jongste wordt bijna acht uigen. Dat gaat ook snel. Ja, leuk. Dus ik heb dat, het de kinderen leren programmeren ooit nog als excuus gebruikt Ik heb zo'n hele oude IBM gekocht. Cool. Met het excuus ja, dan kan ik de kinderen leren programmeren. Volgens mij had je toch ook een keer een hele oude monitor. Zag ik een keer op LinkedIn of Twitter? Ja, maar dat is niet alleen een monitor. Dat is een IBM XT. Dat ding is uit 83. Ik ben ook uit 83, maar dat ding is uit 83. Dat is ook mooi, want dan kun je niet horen op de podcast. Maar dat ding is loodsvaar. Er zit zo'n harde schijf in. Dat is volgens mij 64 MB of zo. Dan zit er 600 KB intern geheugen. Oh ja, dat denk ik. En als je hem aanzet, gaat er ook zo'n tellertje oplopen. Oh heerlijk. Nou, mooi man. En wat doe je nu? Ik werk nu bij Financial Lease. Dat is een bedrijf dat bemiddels tussen zetse... voornamelijk zetse payers, maar zelfstandigen die op zoek zijn naar een auto. En autobedrijven die auto's aanbieden. Het is tweedehands. En dan de banken die het financiële product Financial Lease aanbieden. Wat voor ondernemers heel aantrekkelijk is. En als ik het aan mensen probeer uit te leggen die niet precies weten wat het is, dan zeg ik altijd dat het een soort hypotheker is, maar dan voor zetse payers en auto's. Ik hoop niet dat mijn baas heel boos wordt. Nu zit het... Cancel, cancel ik. Maar dan is het wel redelijk, geeft het wel een beeld van wat het is. Ja, dus wij hebben in principe zelf geen voorraad en wij financieren niet. Maar we ontlasten, of ontsorgen eigenlijk de mensen bij, net als dat de hypotheker doet bij het aanschaffen van een huis. Tenminste, dat hoop ik voor je als je zegt. Ja, dat is wel het idee toch? En wat voor coole dingen mag jij daar doen? Ja, ik werk daar als technical lead. Ik ben daar ruim een jaar geleden binnengekomen. Toen was de IT-afdeling binnen het bedrijf vrij klein. Dus we hebben voornamelijk voor onze lease-adviseurs die werken in Salesforce. Dus dat is wel een Salesforce-team. En als ik altijd probeer te omschrijven aan de mensen die op kandidaten die op gesprek komen, van oké, wat doe je dan? Ja, alles software wat geen Salesforce is, dan komt het eigenlijk op neer. En dat zijn voornamelijk integraties, services die wij gebruiken om dat proces van onze lease-adviseurs te vergemakkelijken en de autobedrijven voor het aanbieden van hun voorraad op onze website. Oké, cool. Dus technical lead. Ja, dus een beetje van alles nog wat. Ja, dus wat meer richting minder zelf aan de knoppen zitten. Het is niet dat ik helemaal niks meer doe, maar ik heb overal wel een mening over. Zo ken je mij denk ik ook wel kiezen. Ja, zeker. Het is wel leuk om even te vertellen, Rick en ik, we hebben samen bij Mendix gewerkt. Daar hebben we samen ook echt veel nagedacht over hoe we de CI-CD pipelines van Mendix beter konden maken. Dus dat was ook een van de redenen waarom we je natuurlijk hebben uitgenodigd. Nou goed, gaan we door naar onze volgende gast. Gerard van Engelen. Ja, nou ja, mijn naam heb je al gehoord natuurlijk, maar ik zal mezelf nog een keer voorstellen. Gerard van Engelen is altijd zo vreemd nadat iemand je voorstelt. Maar ik ben 34 en ik heb ook twee kinderen. Een dochter van anderhalf Lotta en een zoon voor vier, Siebe. En Siebe gaat deze week voor het eerst naar school, dus dat is allemaal heel spannend natuurlijk. Ja, in ieder geval voor mij is het spannend, misschien voor de luisteraars niet. Maar goed, je bent toch ouder. Nou ja, net als Rick ben ik eigenlijk begonnen als tester. Ik heb dan alleen bedrijfseconomie gestudeerd, maar nadat ik klaar was met studeren, dacht ik, alles wat ik nu doe, dat wordt ook door computers gedaan. Dus ik stapte snel aan boord van de IT-terrein. En ja, eigenlijk de jaren door is het een beetje, hoe zeg je dat? Meer gaarig in testautomatisering, toch weer meer CICD, ook wat developmentwerk erbij. En dan, ja, op dit moment werk ik als platformengineer bij KB gedeticheerd. En daar werken we nu aan een platform waar een systeem op draait die eigenlijk alle boeken en wetenschappelijk artikelen die uit zijn gebracht en uit worden gebracht, digitaal opslaat. Dat is een van de kerntaken van de KB, is het opslaan van de Nederlandse taal. Dus je kan je voorstellen dat daar petabytes aan data doorheen gaat. En daar ben ik nu CICD pipelines voor aanbouwen voor de applicaties die dat faciliteren. Oké, cool. Nou ja, dat is ook een mooie reden om jou hier in de podcast te hebben. Ja, zeker. Ja, cool. Andere vragen die wil ik altijd stellen, is hoe jullie zijn begonnen ooit met programmeren. Heb je, wat is je eerste herinnering eraan? Hoe ben je er ingerold? Want de ene die begint toen ik een amper kon lopen. Nou, dat is overdreven. En de andere is echt op veel later leeftijd begonnen. Dus dat vind ik altijd wel leuk om te horen. Ja, shoot maar. Ik weet niet wie wil beginnen erover. Ik wil best beginnen. Er wordt wel misschien een beetje opa verteld, want mijn eerste programmeer ervaring was in Flash toen nog van Macromedia. Ik weet niet of dat later volgens mij bestaat. Het is al al jaren niet meer. Maar het is overgenomen door Adobe, volgens mij. Ja, volgens mij op een gegeven moment wel. Ja, maar toen. Maar het is nu nu al. Ik weet niet hoelang, volgens mij uitgefaceerd uit de gecanceld uit de computer wereld. Ja, ja. Was toen ik op de middelbare school zat. Ik denk dat ik een jaar of 13, 14 was. Dus dat zal het zijn geweest. Eind jaren 90, half jaren 90. En toen heb ik samen met een vriend. In Flash kon je dan filmpjes maken, animaties, hoe je het wil noemen. Het zag er niet uit, maar dat was wel het eer. En dan, ja, tegenwoordig volgens mij in in paint kun je het beter doen. Maar toen toen was dat helemaal de bom. Daar is het toen een beetje begonnen. En toen tijdens mijn middelbare schooltijd, maar eigenlijk vooral tijdens mijn studietijd. Veel met met pp gewerkt. Weet niet. Nog uit de tijd dat dat pp. Het was een pp3 of zo, pp4. Nog geen klas gekende denk ik. Nee, volgens mij niet. Volgens mij was het gewoon een meer soort aan elkaar geknopt functies. Ja, het was echt scripting vooral, volgens mij. Ja, scripting, ja. Dus die tijd. En vanuit daar. Ja, door door gegaan. Dat was het begin. Maar mijn eerste herinnering is wel dat ik samen met die vriend toen dat filmpje gemaakt heb. Ja, precies. En ongetwijfeld zal er tussen wat HTML en CSS hebben gezeten. Wat een beetje het gezonde groeipad is. Ja, ja, ja. Wat iedereen wel denk ik inmiddels wel ervaart. Om makkelijk met HTML, ten eerste om te pogumeren. Ja, vrijwel iedereen heeft dat toegang tot een browser. Dus ja, dat is het natuurlijk wel. Ja, het was ook nog uit de tijd dat er geen dev tools in de browser zaten. Dat je bijna letterlijk met notepad gewoon. Dan had je dan wel notepad plus plus. Maar het heette toen volgens mij nog anders. Dat was eigenlijk gewoon notepad met syntax highlighting. Dat was het. Ja, precies. Bizar is dat vergelijkbaar nu. Ja, ja, nee. Die tijden zijn sowieso gelukkig veranderd. Meestal zeer gelukkig, want soms zit ik ook te vloeken op met tools. Maar dat is even een ander onderwerp. En jij Gerard? Ja, ik ben ik wel wat later op latere leeftijd begonnen met programmeren. Mijn eerste ervaring was Selenium C Sharp. Oh ja, de test tool. Ja, de test tool. Ik denk dat ik 6, 7 maanden als tester werkte. En ja, dan zeggen ze op een gegeven moment. Ja, je moet wel met test automatisering gaan doen. Video tutorial. En ja, daar is het eigenlijk begonnen. Zo'n 6 jaar geleden of zo. Oké. En heb je ook weleens een programmeertaal echt van scratch geleerd? Of ben je gewoon echt in de flow gegaan van de tutorials, wat je net zegt? Ja, ik denk niet echt van scratch. Ja, ik doe nu typescript en .net. En alle twee denk ik wel dat ik, ja, heb ik meer gedaan van nou, ik volg een tutorial. En dan ga je gewoon in een opdracht, ga je wat doen. Vaak is het dat je als tester kom je in een opdracht terecht en dan zeggen ze ja, we willen een test automatisering framework en we willen dit. En dan is dat weer een andere taal dan de opdracht daarvoor. Dus dan moet je weer beginnen. En dan, als ik nu vanuit mijn developer rol een opdracht zou aannemen, dan zou het denk ik wel typescript zijn. Ja, ja. Nee, want ja, kijk, ook in onze podcast hebben we het vaak over van ja, ook voor de youngsters out there, weet je wel, die onze podcast luisteren omdat ze gewoon echt kennis op willen doen van hoe de, ja, noem het maar even, de mannen of vrouwen die in de midlife crisis veertig jaar komen, hoe ze hun programmeerervaring hebben opgedaan. Ja. Dus vandaar dat ik even die vraag stel. Dus ik denk dat Saber en jij ook wel denken, je hebt ook een IT opleiding gedaan, toch? Ja. Ja, ik ook. Ja, weet je, daar leer je echt gewoon van scratch van, ja, joh, wat is, hoe ga je om met geheugen? Wat is rap? Tegenwoordig doen ze dat denk ik niet meer, vermoed ik. Alles is dan in de cloud. We hebben toevallig in de vorige podcast, maar dat is. Oh, oh ja. Ja, nee, dat is, het is lastig omdat ik weet niet of op HBO's dat dus misschien niet meer gegeven wordt. Ja. Op universiteiten weet ik zeker dat ze dat doen, omdat ze dan met compilers bezig zijn en parsers en ja. Maar dat, ja, dat hadden we toen die discussie, of Tins en Fellini legden het ook uit van ja, eigenlijk is een universiteit een wetenschappelijk instituut. Dus je leidt mensen op om wetenschappelijk onderzoek te doen. Dat is normaal gesproken zo. En dan is het heel logisch. Dus dat als je daar komt, dat je dan wel de diepte in gaat. Dat je weet wat doet de CPU en zo. Dat is wel een soort van kennis die je nodig hebt. Terwijl op HBO is het vooral toepassen van. En is het nog nodig dat je machine taal, zeg maar, nog moet leren? Dat is assembly. Ik weet niet of dat nu nog gebeurt. Dat weet ik niet eens. En dat zal misschien niet zo zijn. Dus dat je niet meer zo diep hoeft te gaan. Nee, maar dan. Kijk, wat ik nog van mijn opleidingen kan redden, is dat je dan veel leerde over, weet je, hoe je architectuur bijvoorbeeld in software zou kunnen opzetten. Hoe je moet modelleren. Van datgene wat de requirement is tot aan, dat werkelijk de implementatie. En dan echt met UML aan de gang. En weet je, ook al die dingen eromheen. Ook met databases omgaan. En waarom dat dan zo belangrijk is en zo. Maar goed, kijk, ik merk, er zijn gewoon verschillende invalstromen. We zitten hier met mensen die dus geen IT-opleiding hebben gedaan. En die dan blijkbaar met tutorials ook heel ver komen. Ik nog steeds hoor. Ik heb ook altijd met tutorials. AWS ontlangs ook gedaan. Maar er is sowieso heel veel instroom. Er zijn altijd waves, dat noemen we maar. Dan is er denk ik heel veel vragen naar ontwikkelaars. En dan zie je dat er heel veel instroom is. Dus dat hebben we eigenlijk altijd gehad. En ik denk dat de laatste acht jaar dat er heel veel vragen naar ontwikkelaars is ontstaan. Waardoor er nog meer mensen bij kwamen. En dan zie je dan krijg je die dingen als bootcamps en alle andere manieren om mensen op te leiden, zeg maar. De beschikbaarheid voor goede content is natuurlijk ook wel verschrikkelijk omhoog gegaan. Als ik kijk naar hoe ik vijf jaar geleden aan mijn informatie moest komen en hoe dat nu is. Misschien word je ook wel beter in het zoeken van informatie. Ja, dat denk ik wel, ja. Maar ja, weet je, als je nu neem je abonnementje op CodeCloud of Cloud Guru. En ja, ik denk dat iedereen die een klein beetje IT-achtergrond heeft, die kan binnen twee, drie maanden wel met elk platform uit de vliegtuig. Ja, ja, ik denk dat het waar is. Ja, dat is niet heel gek, zeg maar. En ook met de constant chat-GPT. Nee, ik moet even deze test automatiseren. Doe het eventjes voor me. Weet je wel, dit is de context. Ja, ik ben nog steeds skeptisch, zeg maar. Ik geloof echt wel dat het helpt als tool. Ja, ik ben nog skeptisch. Ik weet niet waarom. Ik heb niet een angst, want ik zie het gewoon als een hulpmiddel, zeg maar, alsof iemand naast je zit. En dat, ja, zo'n GitHub co-pilot heet, letter co-pilot, is degene die naast je zit om je te helpen. Dus dat is ook de positionering, zeg maar, voorlopig, hoe ik het zie. Ja, met de constant rekenmachine zijn ook niet alle wiskundigen uitgestorven. Nee, nee, nee, daarom. Dus ik zie het ook niet als een, precies, ik zie het niet als een bedreiging. Ik zie het, het is een middel waardoor je productiever kunt zijn. Maar ja, er zijn nog misschien wel wat kanttekeningen. Dus dat bedoel ik niet mee dat het niet toepassbaar is, maar van waar komt al die, waar haal je die code vandaan? En ja, wat zijn de legal aspecten die dan daarbij komen kijken? En privacy, zeg maar, dat is ook nog wel een ding. Ja, en dan heb je nog niet eens over intellectueel eigendom. Ja, ja, vooral dat, ja. Nou, toevallig ook bij mijn huidige opdrachtgever, daar hebben we ook een onderzoekje gedaan. Weet je wel, met security samen van, oh, iemand zei ook van, we moeten chattypity gaan gebruiken, man, dat is hartstikke makkelijk. En dan deed hij van alles, maar toen kwamen we toch wel achter van, ja, je bent toch wel intellectuele eigendommen aan het delen over het model van de opdrachtgever. En dat is niet zo handig. Dus daar moet je wel... Ook onbedoeld kan het bij een ander teweegkomen. Ja, ja. Ja, ja, dus dat en, nou ja, die kunnen we niet al te lang over chattypity doorgaan. Maar bij mijn huidige opdrachtgever waren ze bezig om te kijken of het nuttig was, of het, ja, om even te testen van, ja, je gaat de developers helpen. En daar is van hogerhand gezegd, ja, heel leuk, maar dit feestje, dit stopt nu. Oké, ja. Want reasons, zeg maar. Ja, Amerika en weet ik veel te al, maar goed. Nou goed, het onderwerp van vandaag is CI CD. Dus laten we daar maar even terug op keren. En misschien wel ietsje breder, de DevOps culture. Maar weet je, laten we eerst gewoon even beginnen met CI. En dan is het misschien ook wel handig als we, ook voor de luisteraars die dat nog nooit eerder hebben meegemaakt. Ik kan me niet voorstellen trouwens, maar goed. Stel je voor dat er iemand daar zit die denkt, wat is CI? Laten we eens even hebben over wat dat betekent. Misschien wil iemand het... Ja, zou ik iemand het in zijn woorden willen uitleggen, wat CI is? Kunnen we het daar sowieso over hebben, want volgens mij iedereen ziet er wel een beetje anders. Ja, ik vind het wel sowieso goed dat we het even opsplitsen, CI en CD, want dat natuurlijk twee verschillende principen zijn. Continuous integration, als je het vertaalt naar continu integreren. Dat is denk ik ook wel wat de lading dekt. Het gaat om het continu integreren van code. En dan denk ik dat je praat over dingen zoals branching, zoals merge requests, repair reviews, en dan dingen zoals SonarCube. Dus eigenlijk alles wat je gebruikt vanaf het moment dat je als developer code begint te schrijven op je lokale machine, tot aan het moment dat het in een repository staat. En met RuPaul Story, als je in de Java wereld leeft, dan zou er bijvoorbeeld ook een artifactory kunnen zijn. In mijn ogen, of bijvoorbeeld zelfs een docker image. Dat is wel een randgevalletje misschien, maar dat zou ik ook nog wel als continuous integration beschrijven. Dus eigenlijk alles wat je doet om code op een juiste manier te integreren en te bouwen. Nou, ik denk ook iets wat we uit onze eigen onderzoek ook gedaan hebben. We hebben nog even de CI volgens Martin Fowler nog eens even bijgezocht. En iets wat mij wel achterblijft daar is dat het vooral bedoeld is om integratie arrows zo snel mogelijk te ontdekken. Dus stel dat ik aan een stukje code werk die op mijn machine niet werkt en ik ben er gewoon weken mee bezig. En jij bent toevallig ook net even in die stuk code ook iets aan het veranderen. Ja, dan wil je eigenlijk zo snel mogelijk dat het gaat clashen. Dus dat we erachter komen, oh ja, jij bent er ook mee bezig. Dus daar ga ik er last van krijgen. En andersom natuurlijk. Dus dat is denk ik ook wel een van de redenen waarom je CI zou willen. En het geautomatiseerd. Want het eerste wat bij mij altijd bleef kleven is dat het moet geautomatiseerd zijn. Want natuurlijk weer met de hand beelden, merging. Nou goed, dat doe je dan mee redelijk met de hand. Maar geautomatiseerd beelden is wel, volgens mij, redelijk essentieel. Want het zou bijna niemand doen als je het niet geautomatiseerd doet. In je test draaien. Het is een leuke, ik vind het echt een super tof onderwerp trouwens. Want ik was bij de Continuous Integration and Testing Conferentie. Kitcon heet dat. Of Kitcon, zo spreek ik het uit. En daar had iemand het over van dat je eigenlijk helemaal geen beeldmachine nodig hebt. Want in feite zou je gewoon op je eigen machine gewoon constant een kitpool kunnen doen. Kitpool, kitpool. En dan opnieuw alles runnen. En dan lokaal alles. En daar ontstond de discussie van ja, dat is helemaal niet waar. Want je wilt toch ook een machine helemaal onafhankelijk die niks doet en geen context heeft. Bijna niet dan. De boel om te laten bouwen. Dus daar ging de discussie over. Maar goed, misschien moeten we niet zo diep gaan hier. Nou ja, nee, dat is op zich interessant natuurlijk. Waarschijnlijk op dat soort conferenzen krijg je soms heel veel filosofisch in de scherm. Dat is op zich niet heel, heel gek. Misschien is het iemand, dat doe ik ook graag, om te challenger, zeg maar. Even de randen opzoeken om dan uiteindelijk wat meer in beweging te krijgen. Dus op die manier snap ik dat op zich wel. Ik zou het gek vinden, zeg maar, dat je dat alleen... Je moet toch iets maken, compileren of samenstellen. Dat maakt me niet uit hoe dan. Om tot iets werkends te hebben. Want het moet werkende software zijn die je ergens kan draaien. En dat is wel meer dan alleen maar een meurtje. Het enige wat je zou kunnen zeggen is dat je lokaal Docker images zou bouwen. En dan die ergens heen. Het hoeft niet... Daar ben ik het mee. Dat is geen theorie, dat kan. Het hoeft niet op een beeldmachine te draaien. Want je zou ook kunnen zeggen... We hebben in principe dat een van de ontwikkelaars maakt die image en die pusht die image. En dat is de output van het automatiseerde proces. Ja, dat zou ook kunnen, maar gebeurt alleen niet zo heel veel. Meestal is het gewoon een centrale... Dan moet je ook zorgen dat maar één developer het doet. Want anders krijg je concurrency problemen. Als twee... Dan kan je nog zo tegelijk pullen, pullen, pullen. En dan als je alle twee tegelijk in de push... Ja, wat is dan de juiste? Dat is precies die discussie. Maar kun je het überhaupt ooit precies tegelijkertijd doen? Nou ja, met automatisering kan je natuurlijk... In GitLab heb je merge trains. Dan zorg je in ieder geval dat het achter elkaar gebeurt. Dan ben je in ieder geval die concurrency kwijt. Ja, of het zou kunnen, dat weet ik niet. Maar goed, het is een interessante... Ik vind het leuk om wat te prikkelen daarmee. Die zin... Ja, het was ook wel een wat oudere man die... Die is waarschijnlijk een oudere... Weet je, in de tijd waar het toen nog niet zo hip was. Het allang deed natuurlijk. Dus dan wilde ze een punt maken. Maar goed, ik vind het wel een mooie theorie... Als het gaat over integratie er zo snel mogelijk... Probeer te vinden. Ja. Ja, dat is wel leuk. Trouwens, Gerrit, je zei het net ook al mooi. Ja, heel vaak zeg je CICD, hè? CICD. Waarom denk je... Of misschien kan ik een vraag geven aan Rick stellen. Waarom denk je dat je CICD uit elkaar zou moeten trekken? Ik denk dat het verschillende dingen zijn. Ja, uiteindelijk is het een uit elkaar trekken. Ja, bij mij betreft niet uit elkaar te trekken. Sterker nog, het wordt vaak in één zin of in één adem genoemd. Ik denk alleen wat we net... We hebben het net over. Ik denk trouwens dat even terugkomen op continuous integration. Continuous integration is natuurlijk alleen van belang... ...dat je een distributed systeem hebt. Want als je in je eentje aan iets werkt, dan is saven in je text editor... ...in principe al continuous integration. Ja, daar ging de definitie. Wordt dan best wel interessant. Ja, er staat daar heel expliciet ook... ...automated build, including test. Dus dan zeg je eigenlijk al van... Als je in een Git repo hebt en je bouwt je software... ...maar je hebt geen test, dan doe je geen continuous integration. Dat vind ik een beetje kort door de bocht. Je kunt natuurlijk ook zeggen... ...het bouwen van je code is een test. Als het bouwt, dan is het... ...in de filosofische discussies terecht te komen. Je zou kunnen zeggen dat niet elk onderdeel per se nodig is voor continuous integration. Je kan het doen zonder status-iconen-analyse. Je kan het doen zonder unit-test. Het is maar hierom dat in de definitie heel specifiek... ...including test staat. Ja, in principe is... Ik zou wel wat vinden zeggen over de kwaliteit van je integratieproces... ...als je zegt we doen alleen maar builden en doen. Dat is een mening. Maar doe je dan continuous integration of niet? Dat is de vraag. Oké, als je... Anyway, filosofisch misschien voor de bol. Ja, precies. Volgens Fowler inderdaad. Er staat wel dat het geferifieerd moet worden. Maar ja, het verschil wat mij betreft... ...zo ver die bouwt, draait nog niet. Nou, draait nog niet. Dus ja, continuous delivery. Of als je het hebt over delivery, dan heb je het wat mij betreft ook over... ...dat het draait. Dus dat het werkt, dat het draait of dat het beschikbaar is. Laat ik het zo zeggen, dat het beschikbaar is. Want een artifact kan ook gedeployed worden naar een package-repository... ...en dan is het in principe ook gedeliverd. Of een docker image naar dockerhub is het... Kan je zien... Of nou, dat is misschien voor de ene in het proces is dat al de delivery. Terwijl dat voor de andere het begin van de integration is. Dat is ook weer misschien een interessante discussie. Ja, ik zou zeggen dat het een soort... ...zo'n grijs gebied is van integration en delivery. Dat is misschien de slash. Inderdaad. Dat is misschien wel een interessante... ...poppake inderdaad van oké, de delivery van de één. Want ja, als jij een library hebt die jij shipt naar NPM... ...dat is in jouw proces... ...het eind stadium of dan komt het onderhoud. Maar dan heb je net gedeliverd. Maar dan begint voor de mensen die dependen op jou... ...daar begint hun ontwikkelproces. Ja, die CD, dat is een beetje een collega van mij die noemt. En dat vind ik op zich wel... ...die zegt altijd CD, continuous delivery, continuous deployment, zeg maar. Dus die zegt dat altijd in de inzuchten achter elkaar. Dus die deployment is wel belangrijk. Want dan zet je het dus in productie, zeg maar. De deployment is onderdeel van delivery, toch? Ja, delivery aan zich is gewoon hier heb je de spullen. Ja, CD-tje, alsjeblieft. En deployment, zeg maar, het echt in productie brengen. En daar zijn nuance verschillen, zeg maar. Op een gegeven moment is dat waarschijnlijk losgelaten. Oké, continuous delivery is gewoon bijde. Maar er is een moment geweest dat zei, oké, delivery. Oké, hier heb je het en lever het uit. Het staat ergens en daar kun je het ophalen. En dan deployment. Dan zeg je, oké, ik deploy naar één server of 20.000 servers. Dus dat is weer een ander soort van vakgebied. Ja, de delivery en de deployment is altijd een beetje dubbelsinnig. Elke keer zoek het op en dan vergeet ik weer wat precies de volgorde is. Maar volgens mij is deployment dat je een geautomatiseerd proces hebt waarmee je het op omgevingen kan deployen. Maar dat bijvoorbeeld de delivery naar production eigenlijk nog een handmatige stap kan zijn. En delivery is dat je eigenlijk continu naar productie aan het gaan bent. Dus een merge leidt altijd tot een deployment of een delivery op productie als er geen testen vallen. Dus daar zit het nuance verschil en dat hoor je niet altijd. De meeste mensen hebben het over hetzelfde als ze het over cd hebben. Maar goed, dat is ook weer het nuance verschil. En het is per bedrijf, bij het één bedrijf is het net iets anders dan bij het ander bedrijf. Ja, dat zijn er soms smaken, architectonische keuzes of skillset, tools. En ook wat uiteindelijk je eindgebruikers willen. Want toevallig vandaag had ik het met een collega over. Wij bouwen een verzekeringsplatform, laten we even plat slaan. En die verzekeraars zitten echt niet te wachten op elke dag een nieuwe release. Die worden misschien wel helemaal gek. Gisteren deed hij het nog en vandaag doet hij weer wat anders. Dat is misschien ook zonder release, maar het gebeurt soms. Ja, inderdaad, ook dat klopt. Maar daar kwamen we wel achter denk ik. We zijn nog niet helemaal over uit of überhaupt continuous delivery gaat werken daar. Ik zei misschien niet voor alles, maar voor sommige dingen wel. Want stel dat je cosmetische dingetjes zoals bijvoorbeeld alle tekstvelden... ...moeten naar rechts uitgelijnd worden. Weet ik veel, zoiets stoms. Dan wil je toch wel volgens mij zo snel mogelijk... Maar als je inderdaad een verzekeringswet of een verzekeringsregel... ...weet ik veel hoe je het noemt, business rules, zou je dat veranderen? Misschien wel even handig om... Ja, laatste keer dat bij verzekeraar werkte was het ook vier releases per jaar. Maar ook een, noem het maar even, een webplatform? Ja, ja, ja. Toevallig werkt mijn vrouw nog steeds daar. Het is wel regelmatiger, maar nog steeds niet dagelijks of meerdere keer in de sprint of per sprint. Dus het is minder vaak dan dat continuous deployment zou insinueren. Maar nog steeds wel, het moet geautomatiseerd zijn en de delivery. Je doet er wel aan, alleen de frequentie is lager. Alleen wat ik denk, en dat durf ik niet te zeggen, want ik ken niet alle verzekeraars. Het is niet alleen maar dat stukje software, maar er komt nog een hele straat achter, zeg maar. En dan moeten ze bijvoorbeeld testen, regressietesten. Er moeten alle data sets beschikbaar zijn. Treinen van gebruikers. Ja, dat ook. Ik heb zelf ook bij een medisch reguleerd of een gereguleerd software als Medical Device gewerkt. En je kunt dat niet zomaar doen, want er zit ook gewoon heel veel, regelgeving achter die dingen van jouw eis. Natuurlijk, als je het heel graag wil, is er vast wel een manier dat je het op de ene of andere manier voor elkaar krijgt. Maar ja, je moet gewoon dat altijd auditable terug kunnen leiden. En verzekeraars vallen, neem ik aan, ook onder bepaalde wet en regelgeving. Ja, waar gewoon naar gehandels. Ja, precies. Dat klopt, want er moeten bepaalde procedures moeten in place zijn, waardoor het gewoon betekent. Weet ik veel. Er moeten, weet ik, vier ogenprincipes. Er moeten meerdere mensen moeten op een oké hebben gedrukt voordat jij gedeployed hebt. Of de code moet gereviewd zijn door meerdere. Dus het is allemaal processen, zeg maar. Ja, dat is de laatste tien jaar of zo. Ja, er glippen wel eens heel rare stuk code, zeg maar. Er komen er in productie, waardoor een bedrijf gewoon heel liable wordt. En dan snap ik wel dat je niet iedere dag of ieder uur, zeg maar, kunt deployen. Maar andere bedrijven die bijvoorbeeld heel erg commercieel marketing gedreven, ja, dan zie je dat die gewoon liefst iedere tien minuten nieuwe versie online hebben. Toch zie ik ook vaak dat die niet in staat zijn om het te doen. Ik heb hiervoor bij een heel groot... Nou, ik heb bij Carnex gewerkt die auto's verkoopt. Ze bestaan toch niet meer. Daarom ja. En daar was de software vaak heel snel klaar. En dan was het wachten op een bank die toestemming wilde geven voor het financiële product dat we gebruikten of content. Of dan had je te maken met dat het in het Engels was aangeleverd en dat het in acht talen moest uitgerold worden. Dus dat je op de vertalers wachtte. Er zijn zoveel dingen die bijdragen aan het wel of niet continu naar productie kunnen brengen. Als ik naar de definitie kijk, wij impliceren hier allemaal dat het geautomatiseerd. Maar in de definitie volgens Fowler wordt nergens geautomatiseerd genoemd. Nee, dat hoeft ook niet. Als je een aap de hele tijd op een knopje laat drukken of sterk nog als je in een courrier de hele tijd een pakketje met een USB-stick naar het datacenter laat brengen, zou je dat kunnen verkopen als continuous delivery? Ik weet niet of dat in deze, misschien hebben we dat eraf geluid. Het is wel zo, volgens mij dacht ik dat in die definitie ook ergens nog staat dat je op een knop drukt en dan gaat er een proces lopen. Maar het zou niet geautomatiseerd hoeven te gaan. Die continuous integration, als je die naar boven checkt, ja, die noemt explicit automatisering. Maar goed, ja. Ik dacht ook net toen we hadden van oké, wat is CI, CD? Wat is nou het verschil? Ik denk dat als ik de discussie ook een beetje analyseer, dat we eigenlijk wel mee overeen zijn dat continuous delivery in ieder geval minimaal één stap na continuous integration is. Continuous integration komt eerder. Hoeveel eerder dan, dat is denk ik discutabel. Ik denk ook dat CI langer gedaan wordt dan CD. Ik weet eigenlijk niet beter, ik ben dotnet developer, dat in het begin beeld je nog op je eigen machine. Soms levert je je desktop software uit, dan kan je op CD's uitgeleverd worden. Dus dat was al heel anders, die delivery dan was. Maar met web applicaties was het al vrij snel dat we naar geautomatiseerde beelds gingen, om die reproduceerbaarheid erin te krijgen. Anders kreeg je gewoon dat als Jantje beelde, dan kreeg je iets anders dan Pietje. En centrale beeldomgevingen om te zorgen. Toen met dotnet en Microsoft had je heel veel afhankelen op een Windows machine. Als je maar één ding verkeerd had geïnstalleerd, dan werkte het helemaal niet meer. Dus het was heel erg om die foutgevoeligheid eruit te krijgen. Dus dat CI deden we al redelijk snel, dat is best wel lang al in place. En dat CD, dat je echt naar productie gaat met de web applicatie en geautomatiseerd, dat was wat later. Dat was best luxe, omdat er vooral, dat is misschien een beetje meer die DevOps manier, dat waren best wel schuttetjes. Dus het was echt van oké, wij zijn het software development team, dan komt de CD'tje bij wijze van spreken, komt eruit en ik ga naar een beheerder, zeg maar, en die installeert het dan op een server met een dikke handleiding. Dat is de web applicatie, de SQL database moest bij een DBA, die moest daar nog iets doen. En als dat allemaal ergens in een teststraat, de OTAP, gedeploitert in één fase, dan had je dat overwonden, dan mocht je naar de volgende, dan had je naar acceptatie, dan had je daar weer allerlei dingen en data. Dus dat was best wel heftig, zeg maar, om een release te doen. Dus het was ook best wel logisch dat in die tijd, dat je niet echt, als iemand toen zei van ja, we gaan iedere dag releaseen, dat kon gewoon niet. Dat was echt fysiek gewoon onmogelijk om dat voor elkaar te krijgen. Ja, precies, want dat zijn natuurlijk twee silo's, Stintjes, de developmentgroep die dan... Ja, inderdaad, wat je zegt, ik heb mijn NPM package opgeleverd. Toetledokie, het werkt toch met mij? Sterker nog, er zijn natuurlijk heel veel repos op GitHub die NPM packages of modules leveren. Dus ja, als je zegt van het moet een draaiend stuk software, dan is eigenlijk alles wat partiële software is, per definitie zou dan niet continuous delivery zijn. Precies, meens. En dan stel dat die beheerafdeling die NPM packages bij elkaar harkt en dan een product van maakt, dat uiteindelijk releasable is. Ja, die werelden zijn zo verschillend, waardoor die ruizen in de lijn gewoon alleen maar groter worden. En vandaar dat nu, als we het hebben over DevOps, dat is misschien een mooi bruggetje. Ja, DevOps probeert dus die twee werelden bij elkaar te voelen en samen te mengen. In ieder geval dat de twee afdelingen wel in dezelfde boot zitten om die release goed te krijgen. Of de opleving naar de klant dat de klant ook echt letterlijk de waarde heeft van wat het zou moeten zijn. Ik ben wel blij dat we deze definitie van DevOps zou hanteren. Als je in de markt kijkt, zie je natuurlijk dat er veel om DevOps engineers wordt gevraagd en dat zijn dan vaak meer platform engineers. Of cloud engineers, maar als je dat uitzet, dan moet je meteen de hoofdprijs betalen. Klopt, ja. Ik denk dat deze definitie van DevOps waar je praat over dat je had in de klassieke wereld ops en development. Die voeg je dan samen om die schutting er tussen weg te zagen. Dan heb je denk ik de juiste definitie van DevOps te pakken. Ik denk dat elke developer tegenwoordig ook al op zijn eigen machine redelijk wat operations doet omdat je kan tegenwoordig alles wel prima op je eigen computer draaien. Dus je moet ook wel een beetje snappen tot op zekere hoogte of in zekere mate moet je in ieder geval begrijpen hoe het werkt of je komt er vaak snel genoeg achter hoe het werkt want je moet gaan debuggen. Tenminste, ik weet niet hoe bij jullie het zit, maar bij mij werkt alles in één keer. Ja hoor. Nee, maar ik denk dat die lijn is ook gewoon veel meer vervaagd ten opzichte van vroeger. En het is ook operations, ik wil geen DevOps'er tekort doen want goede DevOps zijn zeer waardevol. Maar die cloud platforms die proberen het natuurlijk ook wel allemaal zo makkelijk mogelijk voor je te maken. Dus je hoeft tegenwoordig geen rocket engineer meer te zijn om iets draaiend te kunnen krijgen in de cloud. Om een productie omgeving in te richten is iets anders. Maar om iets draaiend te krijgen in de cloud en voor je te laten werken, dat, behalve dan de permissies bij AWS, maar daar moet je wel rocket engineer voor zijn. Inmiddels wel ja. Maar Google is het niet veel anders hoor. Nee, maar ik bedoel... Ik begrijp het wel ja. Het is... Zo, dat was Siri de eerste keer. Die weet het ook niet. Maar die opsrol, de beheerder noemt, ja in Nederland wordt het meestal de beheerder genoemd, die is ook echt wel veranderd. Vooral door de cloud. Want voorheen was het echt de man die gewoon de data... Het is ergens bij een verzekeraar van een bank, die liep het serverhok in. En ja, die wist hoe die service werkt. En die moest patchen, zorgen dat het spul in de lucht bleef. En die zorgde ook echt gewoon dat die software fysiek geïnstalleerd werd op die machine. Dan moest die gewoon echt heen gaan, zeg maar. Ja, of nou goed, ze laten hem natuurlijk ook remote inloggen. Maar hij haalt toegang fysiek tot die machine. Dus dat was echt wel zijn of haar verantwoordelijkheid. En die was, volgens mij was die volgens mij een belangrijke taak was vooral zorgen dat die server bleef draaien, dat het stabiel was, dat er toen in mindere mate, maar dat niet om de havenklap gehakt werd en zo. Dus dat was de verantwoordelijkheid. En dat is voor denk ik misschien wel 90 of 95 procent uithanden genomen door de cloud. En dan zie je... Dat is ook heel goedkoop geworden, vroeger. Nee, dat geloof ik niet. Nee, cloud is echt niet goedkoop. Nou, daar laat ik dan... De instap is... Vroeger had je een enorme hoge instapdrempel. Wat service aanschappen, waar je was zo twee, drie ton verder. En dus je moest ook wel echt heel goed nadenken voordat je voordat je zoiets aan ging schoffen. Terwijl tegenwoordig je kunt, gewoon pay as you go kun je het proberen. En als het niet werkt dan discard je het weer. Of een 80 euro instap op Kubernetes. Ja. Ik bedoel, je kunt al die cloud platformen... Ik bedoel, je moet je credit cardnummer doorgeven, maar je kunt in principe in free tier kun je prima experimenteren en kijken van oké, hoeveel... Vroeger was, denk ik ook... Ik ben geen operations engineer, maar vroeger was het heel hard nadenken vooraf van oké, wij willen dit gaan draaien. Wat moet dit, wat moet ik aan servercapaciteit hebben? En nu denk je van, als het te weinig is, dan schakel ik wat bij. Ja, klopt. Tenminste, zo doe ik het. Misschien wederom doe ik nu mensen tekort, maar... Je hoeft minder ver vooruit te kijken. Ja, precies. Het is reactief geworden. En niet meer dat je echt van tevoren moet... Want ook zo'n investering van drie ton, dat was niet voor twee maanden De meeste bedrijven schrijven die dingen in drie, vier jaar af. Nee, precies, daar ben ik mee. Het was best een risico. Er werd geprovisioned, dus vooraf bekeken, wat verwachten wij aan load en hoe zit onze applicatie. En dan kocht je daar je hardware op in en je softwarelicensies. En dan ging je. Dus dat was best wel een deel. Dus stel dat als een opdrachtgever naar ons toe kwam, zat dat ook allemaal in offerte. Dat was best wel een ding dat je ook helemaal moest meenemen. En er hoorde bij die investering. Terwijl nu is dat risico, zeg maar, is kleiner. Je kunt ook stel dat je daarna vier weken of vijf weken achter komt. Dit wordt helemaal niks. Dan heb je heel weinig risico gelopen, want je hebt die servers. Je hebt een paar tientjes kwijt en dat is het. Terwijl als je dat vroeger had gedaan, dan had je dus even een enorme investering gedaan. En dan had je wel wat zachtereinigheid. Daarom had je onder al die bureaus, zeker van die testers, stonden al die desktopcomputers. Met zo'n briefje. Niet uitzetten. Klopt. Je kon ze ook huren en zo. Dat soort modellen. Tijdens ontwikkeling gebeurde dat wel. Het is niet meteen dat je in het ontwikkeld traject meteen al de duurste serveren had staan. Maar dat was wel... Het was significant duurder dan de computers waar je developers op aan het werk waren. Ja, ja, ja. Meestal wel, dat klopt. Als je 100 developers hebt in één server, dan worden al die MacBooks bij elkaar misschien wel... Maar waarom reageerde ik op dat duurde? Nu is het een beweging, daar hoef ik niet lang bij stilstaan. Dat er nu wordt gekeken, heb je wel zoveel cloud nodig? Misschien kun je gewoon een server, en als je de juiste skills in huis hebt, gewoon zelf servers kopen en draaien. Dan kan het en vaak is het goedkoper. Die afweging wordt nu vaker gemaakt. Dat vind ik gezond. Ik zeg niet dat het altijd de beste manier is. Want je moet ook zorgen dat je je security op orde hebt. Er komt er heel veel bij kijken. Want inmiddels is er zoveel... Bij AWS, Azure en Google Cloud zoveel kennis opgebouwd in het efficiënt draaien van het spul. Daar kun je niet altijd tegenop boksen. Ja, maar ook de onderhoud. Het feit dat je gewoon minimaal onderhoud hebt. En als je allemaal service zelf hebt. Ze moeten toch onderhoud worden gepraatst de hele tijd. Dus je moet het in de gaten houden. Dat kost ook geld. Ik weet nog wel... Dan kan je vast nog wel herinneren dat we toen bij Mendix werkte. Toen heb ik inderdaad echt zo'n business case moeten maken van waar we naar de klaut moesten. Hoeveel geld er er niet in omging. Om die service allemaal zelf te onderhouden. Patches inderdaad wat je zei. Beveiligingszaken oplossen. En wat het uiteindelijk ook voor effect gaf als het fout ging. Dus dat we echt letterlijk niet meer konden bouwen. Dat hadden we gedaan. En toen hadden we gewoon een vrij simpele opteelsom gemaakt. En toen kwam het uiteindelijk toch in de klaut wel goedkoper uit. Maar dat is hoeveel jaar geleden? Ik denk bijna 6, 10. Tussen de 5 en 10 jaar geleden. Ja klopt. Ik denk wel dat dat makkelijker is geworden inmiddels. Dat je een flink datacenter hebt. Met automatisering, al dat patching en die meuk, kan je ook wel makkelijker regelen. Cloud versus staal. Ik denk dat dat een afweging is die je per bedrijf moet maken. Een apart IP voor je ILO. En dan kan je daar inloggen. Maar goed, weet je, inderdaad het is gewoon heel afhankelijk van de risicogevoeligheid. Maar goed, ik neem aan dat bedrijven als AWS en Microsoft... Die hebben vast wel wet en regelgeving voor. Die je daarbij kunnen helpen, toch? Om bepaalde zaken gewoon veilig te stellen. Of misschien niet. Of ben ik daar echt te veel in getrouwd? Kijk, Nederland is op zich nog best wel mega. Duitsland is daar heel veel strikter in. Dus die hebben echt zoiets van oké, die data gaat echt, echt buiten. Dat mag niet, want allerlei regels en wetten. Dan zijn wij wat makkelijker meegaan erin. Dus Microsoft kwam hier in Nederland qua cloud. Microsoft dus, vooral omdat ze daar meer ervaring hebben. Die kwamen, meer dingen kwamen ze weg. In Duitsland was dat echt niet zo. Duitsland heeft volgens mij, voor Azure, hebben ze... Volgens mij heeft T-Mobile een van de datacenters, of toen in het begin die datacenter van Microsoft inbeheer. Omdat dat moest gewoon een Duits bedrijf zijn. Omdat met die, weet je, die Patriot Act, mag Amerika altijd gewoon jouw datacenter binnenkomen lopen. Als zij denken, daar zit gewoon data, we willen erbij, dan is het heel leuk, maar dan komen we gewoon binnen. En dat vond Duitsland niet zo. Maar goed, dat is even een heel andere discussie. Maar in cloud, dat kun je gewoon niet meer wegdenken. Dat is er gewoon. Dus als we de vraag, kun je CICD doen zonder cloud? Ja, dat kan. We kunnen echt wel een zet Raspberry Pi's kopen, een eigen build-servertje bouwen, toch? Ja, eens, maar het is tegelijkertijd... Dus dat is alleen maar bijvoorbeeld het hosten, of je build-server host in de cloud. Dat kun je doen. En waar draai je je software? Dat draai je liefst ook in de cloud. Dat kun je ook allemaal zelf doen. En je ziet wel dat er nu een product ontstaan die bijna niet evenaar zijn als je die zelf gaat draaien. Dus dat wordt steeds lastiger. In de overheid wereld wel dat cloud vaak niet wint van staal. Als je kijkt naar aanbestedingen en dat soort dingen, tijd dat je klaar bent met aanbestedingen, ze hebben het geïmplementeerd, dan kan je weer opnieuw beginnen met aanbesteden. Dan hebben we het nog niet over de data die wordt opgeslagen door onze overheden. Wil je dat bij de Google's van de wereld terechtkomt? Nee, nee, nee, precies, die snap ik. Daar zie je wel vaak, ik zit nu bij de Koninklijke Bibliotheek, dat is gewoon semi-overheidsinstelling, alles op staal. Ook GitLab draait op staal. Er zijn nu wat applicaties die gericht zijn op de, ik doe even tussen aan aanstekers zien, de consument. En die gaan ze dan in Azure onderbrengen. Maar dat zijn geen bedrijfscritische applicaties. Maar wat is de definitie van cloud? Als je servers ergens op een andere geografische locatie staat en je connect via het internet, hebben we het dan niet al over cloud? Er zijn wel veel definities. We zeggen vaak on-premise. Die dude van Oracle vindt dat hij het uitgevonden heeft, maar zei dat als het niet draait op jouw machine, als de machine niet voor jou is, dan is het de cloud. Dus het draait ergens op, want we draaien de servers ook in server, hoe heet dat, ergens anders, co-location. Data centers precies. Maar dat noemen we geen cloud, want die servers waren gewoon ons eigen dom. En zodra het niet ons eigen dom was, werd het cloud. En ook de flexibiliteit, dat je zei, geef mij 10 van die, dat was dan heel makkelijk. Dus dat was een beetje de definitie van cloud. En waardoor je dan, als je het in een data center hebt staan, en het zijn jouw servers, en niemand anders kan erbij fysiek, dan is het gewoon jouw staal. En dat is denk ik wel een belangrijk verschil, zeker voor de overheid ten opzichte van cloud. Nou, is het zeker zo dat ook Microsoft, en de Googles, en de Amazons, ook alles aan doen om ook voor de overheid toch nog offerings te hebben, en garanties probeert te bieden, zodat die data niet ergens anders terecht komt. Dat zijn zoveel lobbies, want ze weten gewoon, dat is gewoon heel veel business te halen. En er zijn allemaal richtlijnen, certificaten voor, dus dat speelt wel. Ik ben er helemaal niet up-to-date mee, maar dat spel speelt heel lang. Dat is met financiële instellingen in Nederland ook. Ik heb nog in het begin meegemaakt, ik weet niet, een van de banken die zeiden, ja, heel leuk, maar dit gaat gewoon de cloud niet in, punt. Want de Nederlandse bank, die vindt het gewoon niet goed. Als zij het niet goed vinden, mogen wij het gewoon niet. Dat heeft heel veel lobbywerk van de drie grote, zeg maar, Amazon, Google en Microsoft en IBM trouwens ook, om te zorgen dat het toch mocht, zeg maar. Nu zie je wel dat financiële instellingen gewoon in de cloud staan. Dus dat is ook al een stap, zeg maar, die ik toen in eerste instantie dacht, ja, dit gaat echt nooit gebeuren, want wie garandeert ons nu dat die data niet ergens anders terecht komt? En als we het dan hebben over intellectueel eigendop, dat is toch vaak code die we schrijven, die we dan in Git opslagen. Doen we dat ook in de cloud? Want eigenlijk waar ik op doel is de vraag, als je CI zou willen gaan toepassen in een Greenfield project, welke tool zou je dan willen gebruiken? Is dat iets wat je lokaal, weet je wel, on-premise is, zou willen proberen of zou je direct naar de verschillende bedrijven die dit allemaal omarmen? Heb je nu over repository management? Ja, repository management, echt alles wat er nodig is om CI goed te doen, met pull requests en zaken zoals dat. En kijk, je kan, GitHub weet ik overigens niet hoor, maar GitLab kun je on-premise draaien, maar dan draai je natuurlijk nog steeds, eigenlijk GitLab, dus behalve dat je dan zelf alles moet beheren en misschien zeker weet dat jouw repository, Git repos, in ieder geval niet bereikbaar zijn voor anderen, maak je uiteindelijk nog steeds gebruik van dezelfde tool. Kijk, als je het echt gaat hebben van, moet je die tools gebruiken of niet, dan is mijn persoonlijke mening, misschien ook omdat ik er niks van af weet, maar je maakt het jezelf wel heel lastig als je het niet doet, dus het kan waarschijnlijk, want vroeger kon het ook, maar dan kom je op een gegeven moment ook in discussie, moet je Git gebruiken of niet. Version control, dat is dan de volgende stap en uiteindelijk zit je op een bierfilter je programma te schrijven, het is wel veilig, maar wat kost het en wat zijn de risico's? Ja, want ik merk wel dat op de gegevens waar ik zit, dat wordt toch vaak on-premise geïnstalleerd, dus dat soort Git repo-achtige tools, zoals Bitbucket, GitLab, die worden toch wel lokaal geïnstalleerd, bij Rijkswaterstaat heb ik een tijdje geweten, daar hetzelfde verhaal, alles lokaal en bare metal inderdaad. Ik ben wel benieuwd hoe dat dan, want uiteindelijk zijn die, als we toch naar AI hebben, die co-pilot bijvoorbeeld, die werkt natuurlijk uiteindelijk op basis van, in deze context, wat is over het algemeen, wat de mensen, als developer, als volgende woord, wat is het vervolgen in je syntax, dat vult die aan. Dat doet die natuurlijk op basis, waarschijnlijk van alle repos, maar neemt die daar dan ook de private repos in mee. En als jij het on-premise installeert, dan zou je heel efficiënt een soort van eigen context kunnen creëren op jouw basis, van jouw repos, want de kans is veel groter dat je iets daaruit wil. Maar ja, mag GitHub dat dan gebruiken om een co-pilot te trainen? Of mogen ze het, of doen ze het, of doen ze het niet? Ik denk dat dat een interessante discussie is ook gaan worden, want het is natuurlijk allemaal hartstikke handig dat die tooling er is, maar die tooling moet ook ergens leren. Ja, die co-pilot, die offering, daar is wel... Je hebt een enterprise-versie waarbij ze wel zeggen, oké, jouw private repositories verlaat niet jouw private omgeving. Dus het is niet zo dat dan de algemene GitHub co-pilot, zeg maar, de suggestie die die geeft, dat die gebaseerd is op de code... Zij gebruiken niet jouw data om een co-pilot te trainen? Juist, alleen jouw eigen instantie, zeg maar. Maar kan je wel een lokale co-pilot trainen met jou? Nou ja, die repos... Mijn ervaring is dat als je in face code co-pilot gebruikt, dat die beter wordt naarmate je hem gebruikt. Dus als je bijvoorbeeld refactoring aan het doen bent, dat als je bijvoorbeeld in de volgende... Ik was laatst iets met metadata aan het toevoegen in verschillende files. En dat vanaf de derde file kreeg ik gewoon foutloos een hele brok code voor. Ja, de meest relevante context is de repos zelf natuurlijk. En misschien wel de file waarin je aan het werk bent zelf. Dat zit al een tijdje voordat codecs, is dat volgens mij van OpenAI. Dus die co-pilot is volgens mij nog steeds... Nou goed, een versie van codecs is hier op gebaseerd. Dus dat is allemaal dat feestje. Maar daarvoor had Microsoft al technologie, zeg maar, in Visual Studio, de normale Visual Studio. En Visual Studio Code zal dat misschien ook gebruiken. Om op basis van jouw code suggesties te doen van, met code completion was in eerste instantie het makkelijkste. Oké, deze functie wil je waarschijnlijk nu gaan gebruiken. En dit soort dingen ook. En daar is ook discussie over privacy. Want dat spul werd geanalyseerd niet op jouw machine, maar ergens in de cloud. En dan was het van, ja, waar gaat het heen, zeg maar. Dus daar is weer privacy een dingetje. Kun je gewoon uitzetten, zeg maar. Dat zit wel op de hout in. Maar goed, dus dat... Ja, dat is zeker een interessante discussie. Ik denk dat die tools helpen je heel erg. Alleen, ja, dat zit wel in een keerzaam. Maar die discussie is niet alleen binnen... Dat is het fijne hier aan. Niet alleen maar binnen software development is die discussie aan de hand. Want dat is juist bij creatieve, single songwriters, textwriters voor films en zo. En allerlei dat soort processen. Daar is ook heel veel discussie over, ja, licensing en rechten, zeg maar, copyrights. Dus dat geldt voor ons ook en met privacy. Dus het is interessant waar het heen gaat. Het zijn hele mooie tools. Maar waar het ons naar heen leidt, dat wordt nog wel een spannende. Wat wel of wat nog interessanter is hier, misschien wel... Nu wil ik ook weer niet mensen tekort doen, maar... Bij artiesten die zijn zich vaak bewust van hun IP. Maar met een developer die is zich natuurlijk vaak niet bewust van het IP van het bedrijf. Maar misschien nog wel meer dan dat de CEO van het bedrijf zich bewust is van dat dat soort tooling misschien hun IP op straat legt. Ik denk dat er weinig CEO's zijn die bij de developers langs gaan en eens even gaan kijken welke tooling ze gebruiken. Sterker nog, als ze het zouden doen, denk ik dat al die developers misnijdig worden dat ze zich bemoeien met wat zij aan tooling gebruiken. En het is ook de vraag, en dat weten we denk ik ook niet allemaal zo, maar hoeveel van jouw IP, in welke vorm, komt die ergens anders? Hoe bruikbaar is het? Hoe bruikbaar is het, zeg maar. Misschien zal er soms een stuk code voorstellen waar je denkt, oh wacht even, dit is gewoon letterlijk 1 op 1 wat ik bij iemand anders had kunnen zien. Dat zou kunnen. Maar ik vraag me dat ook af, want we doen er heel moeilijk over. Maar ik weet niet of dat in de context dat je dan überhaupt weet, van ik heb hier heel erg belangrijke algoritmen waar de concurrent iets mee... Aan de andere kant was dat natuurlijk al met al die licensing van, ik ben er niet helemaal in thuis, maar wat voor licentie je gebruikt. En als je die dependencies hebt die in bepaalde open source licentie hebben, wat eigenlijk jou dan verplicht om open source of jou verplicht. Maar waarvan ze eigenlijk zeggen, oké, als je dit gebruikt, ik weet nu niet precies welke licentie het is, maar als je dit gebruikt, dan schik je je naar dat jou code open source is. En dus ongetwijfeld heel veel niet open source projecten zijn die dat soort dependencies wel gebruiken. Ja, oh zo, dat klopt. Ook dat er zijn ook tools voor om die licentiescans te doen, zeg maar. Dus dat je dan bijvoorbeeld in npmreposters en in .net ook dat die scant welke licenties en of zijn die wel compatible, want dan kun je regels voor opstellen. Ik weet dat bij Manix deden wij dat ook al. Ja, met SNIC. Ja precies, ja ja. En zo zijn er meer van die tools die checken gewoon voor oké, nee wacht even dit kan niet, want dit is MIT, wij mogen niet met MIT licensing werken of met BSD, whatever. Dus dat is wel, een aantal bedrijven die weten dat zij liable zijn, die doen dat bewust, die weten gewoon ja, dat moeten we doen. Maar ik weet zeker dat er heel veel bedrijven echt totaal geen benulden van hebben en niet eens weten wat voor risico's er lopen. Dus met Facebook en React is dat even gebeurd. Ik weet niet of het licentiemodel van React in een jaar of drie of vier wilden ze gaan veranderen. En daar stond in, zeg maar, als een product baseert op React en wat concurreert met een product van Facebook, dan kan Facebook dat product claimen, zeg maar. Dat was echt een hele rare constructie. Zat die ervan, oké dit is gewoon, dan ben je gewoon klaar. Dan stoppen we nu met z'n allen met React, want we weten niet wat Facebook morgen doet. Want stel dat ik nu in een dashboard van een auto React zou gebruiken en weet ik wat voor logica erbij, dan kunnen jullie, zeg maar, iets claimen omdat jullie morgen auto's gaan bouwen. Ja, dat gaan we even niet meer doen. Dus dat hebben ze heel snel, dat licentiemodel hebben ze te snel teruggedraaid. Maar dat was wel echt, ja, wel een beetje een shock, zeg maar. Ja, oké, mooi man. Ja, ik zie het ook nog wel even leuk om bij stil te staan. Stel dat je CI zou willen introduceren bij een team. Of bij je, ja, in ieder geval bij een team. Welke tool zou jij aanraden? Welke toolset zou je aanraden? Want je hebt, we hebben een paar al genoemd, GitLab. Je hebt GitHub. Je hebt, mis ik nog één. Je hebt Azure DevOps. Van Atlassian. Goede oude Jenkins heb je ook nog. Atlassian, ja. Hoe heet dat nou? GoCD heb je ook volgens mij. Ja, ze hebben ook best wel heel veel van die online CI. Circle CI. Circle CI. Hoe is het, ik weet niet of het staat. Oh ja, Travis, wow. Ja. Maar ja, wat is tegenwoordig een beetje hip om te gebruiken? Wat gebruikt jouw bedrijf bijvoorbeeld nu? Ik weet niet wat hip is om te gebruiken. Mijn mening is bij elke tooling gebruik wat makkelijk voor je werkt. En als dat hetgeen is waar je bekend mee bent, doe dat vooral. Ga geen, of het is zonde om heel veel tijd te investeren in iets wat nu hip is. En wat misschien morgen ook nog wel hip is. Maar je kan beter die tijd gebruiken om je code te verbeteren. Ja. Nee. En dus zou ik ook zeggen van gebruik wat makkelijk is. Wij gebruiken zelf GitHub. Hiervoor GitLab. En dus ook GitHub. Wij gebruiken GitHub Actions. Hoeft overigens ook niet. Wat we net zeggen, er zijn online tools die andere online tools die je ook prima integreren. Ja, nogmaals. Ik zou niet zeggen van dit moet je wel gebruiken. Dit moet je niet gebruiken. Wat werkt, wat is makkelijk. Ook belangrijk denk ik hoe makkelijk is om het te leren. We hadden het net al over dat tegenwoordig veel mensen zelf leren programmeren. Dat is ook omdat er veel documentatie is. En die programmeertalen ook allemaal een stuk begrijpelijker worden. Vroeger met als je zelf leren programmeren in C. Nou, dan moest je wel vrij veel geduld hebben. En dat is nu gewoon heel anders. Ook door die tooling die we hebben. Dat draagt er ook aan bij. Ja, want iets wat ik ook weleens in onze podcast over gehad heb. Is of je nou wel of niet van die Jammerfails moet gebruiken. Of dat je het uit moet programmeren. Hier zie jij de pipeline. Hoe bedoel je eigenlijk programmeren in Jammerfails? Ja, dus kijk, Jammerfails zijn over het algemeen heel erg statisch. Dat kan één richting op gaan. En soms wil je ook wel eens logica gaan introduceren. Van if je of misschien ook wel. Nee, voorloopjes hoeft dat niet. En dan is het misschien handig om een programmeertaal te hebben. Of iets van een scripttaaltje die ervoor zorgt dat de boel dynamischer wordt in je pipeline. Ja, veel pipelines die ondersteunen dat toch al. Tenminste, wij gebruiken GitHub Actions. Ja, het ziet eruit als een Jammerfail. Het heeft een Jammer extensie. Maar er zit wel conditionele syntax in. Dus ze hebben eigenlijk gewoon de Jammer syntax. Ze hebben waarschijnlijk zelf een parser er die gebaseerd is op Jammer. Maar die doet meer. En ik kan me niet voorstellen dat GitLab, CI dat niet op een dergelijke manier. Github, Camp Bash, Python. Ja, dat is ook nog. Je kan gewoon codeblocks invoegen. Ik weet dat bij Jenkins vroeger kon dat al. Ik denk wat een goede vooruitgang is. En daar heb ik het over dus een hele tijd geleden. Dat zag je vaak dat die pipelines eigenlijk gedetached waren van de codebase. En tegenwoordig is het onderdeel van de code. Waardoor het mee evolueert met de code. De tijd dat er wijzigingen waren en dat vervolgens je hele testpipeline omviel. En dat je er langer bezig was. Dat niemand wist waarom. Dat de onderhoud aan de testpipeline meer werk was dan de test zelf. Dat is eigenlijk niet meer. Oftewel niet meer. Maar het zijn telkens kleine stapjes die tegelijkertijd in dezelfde codebase gebeuren. Ik denk wel dat het niet echt een goed antwoord is op wat nu de juiste tool is. Kijk, als je bijvoorbeeld keihard op die Azure stack en je zit al in de cloud. En je hebt Azure DevOps in de cloud. Dan zou ik zelf niet zo goed snappen waarom je dan een andere pipeline zou pakken dan die van Azure. Wij zitten nu op GitLab bij KB. Of Koninklijke Bibliotheek. Omdat ze dat on-premise hebben draaien. En daar doen we alles in jeml. Ik doe de website van mijn werkgever. En dat doe ik dan. Ik heb de repository in GitLab. Maar de deployments heb ik in Netlify. Omdat ik gewoon niet, hoe noemen we dat, bothered wil zijn met het deployment. En je krijgt automatisch preview omgevingen op MergeRequest. Super simpel. Tegenwoordig heb je StridePace. Sorry, even toch een tussendoor vraag. Dus je hebt wel in je repo van je website een Yammerfile die dan iets anders gebruikt? Voor de Open People website. Dus die website van mijn werkgever. Daar hebben we gewoon een GitLab repository. En eigenlijk het enige wat we doen is commit naar een preview branch. En op basis van die preview branch maakt Netlify automatisch een preview omgeving. De Canary deployments van GitLab. Dit is specifiek, Netlify is echt een cloud platform voor front-end websites. Die eigenlijk de hele meuk van deployments en integraties voor je weg neemt. En voor 15 euro 5 websites, bedoel, waar praat je dan over? Dus dan heb je geen, om even een concreet vraag te stellen. Dus dan heb je geen CI pipeline bestandje? Nee. Want je werkt dus met die branches? Ja, en je kan wel nog bijvoorbeeld even kiezen om zelf een pipeline te maken. Waarbij je nog wat unit tests doet. Of bijvoorbeeld een change log ergens naartoe published. Maar het hoeft niet. En ik denk dat als je bijvoorbeeld een team hebt. Waarbij de verwassenheid op het gebied van vooral CID, maar CICD dan wat lager is. En ook misschien de bereidwilligheid om zo'n tool te adopteren en lager is. Dan denk ik dat een tool als Netlify of StridePace uitermate geschikt is. Om ervoor te zorgen dat je als team niet zorgen hoeft te maken over dat operations gedeelte. StridePace, daar kan je zelfs manage Kubernetes clusters in één keer alles deployment bij krijgen. Ja, precies. Maar ja, een beetje om weer terug te komen wat ik zei. Ik denk niet dat er één passend antwoord is voor alle bedrijven. Nee, dat weet ik zeker. Behalve dan dat er dus, er is geen passend antwoord. Nee, precies. Dus context afhankelen. Nee, maar goed die Jamal. Kijk, dat is, er is ook sommige mensen die vinden dat helemaal niks. Maar goed, alleen werkt het erbij. En het is denk ik niet voor niks dat het best wel populair is, zeg maar, om in Jamal de beeldpipeline uit te drukken. Want het is eigenlijk declaratief, zeg maar, om uit te leggen van, oké, wat moet je nu gaan doen? En ja, er zullen, ja, blijkbaar in GitHub Actions heb je dan parcels die dan wat logica eruit kunnen halen. En er zijn andere manieren, zeg maar, van beeld dat je eigenlijk gewoon, ja, gewoon code hebt waar je mee beeld. En die, waar allerlei concepten in zitten, zoals, ja, weet ik veel, dingen uit kit halen. Een versie ergens op plaatsen, beelden en, weet ik veel wel, allerlei fancy dingen die daar dan weer in zitten. En dat daar misschien meer flexibiliteit in zit. Ja, dat zal in bepaalde use cases heel erg goed aansluiten. En bij anderen weer niet. Dus ja, het is wel weer, it depends, zoals altijd. Nou, het was net Levi, hè? Net Levi, ja. En dat klinkt inderdaad als een CD-achtige tool dan, waarschijnlijk, of niet? Het is niet zozeer, zie jij dan? Ja, nou ja, kijk, als je, waar zij sterker zijn, is bijvoorbeeld dingen zoals Vue en Nuxt of Next en React en Angular. En dan pomp je z'n applicatie erin en dan doen zij de beeld. Nou ja, dat is dan, ja, NPM-beeld en dan, dat is niet echt heel moeilijk. En wat dan gebeeld wordt, dat stoppen zij op een, in een container of op een server, ik weet niet precies wat ze doen. Ja, dat klinkt als een CD dan. Kijk, onze aflevering gaat over CI-CD, dus datgene wat jij dus nu beschrijft, dat klinkt meer in de CD-hoek. Ja, ja, ja, ja, ja, maar tegelijkertijd, precies wat jij ook zegt, die NPM-run of zo, NPM-beeld. Ja, die beeld ook gewoon. Ja, ja. Ze zitten toch wel weer samen. Ja, dat ligt er aan de node. Het is een node-yes-applicatie. Er zit gewoon een script in, dat zegt wat we moeten gaan bouwen. Dus dan zit het, en dan kun je ook lokaal draaien. Dus dat is dan iets anders, zeg maar. Ja, ja, ja, ja. Oke, duidelijk. Dus er is ook weer zo'n beetje een great graffiti. Weer een great graffiti. Ik denk wel dat het NCI-NCD is, maar ik denk dat als je CI echt goed wilt doen, dan denk ik wel dat je eigenlijk iets met testen moet doen en dat doen zij niet. Nee. Dus ik heb bijvoorbeeld in onze repo heb ik wel wat unit tests staan, die draaien zij niet voor je. Zij doen niet, oh effe eerst testen, oh dat werkt niet, ik ga het niet deployen. Nee zij builden, pompen het naar een omgeving toe. Dus tijdens de build doen ze niet de unit test. Easy deployment. Ja deployment as a service. Oké, ja mooi. Ik denk dat we ook wel redelijk, laten we even naar de tijd kijken. Ja we zitten op een uur en een kwartier, al heel veel interessante dingen, wat mij opviel dat we op een gegeven moment ook wel richting de AI-achtige dingen, weet je wel, dat is op zich niet erg. Dat kan je niet omheen hè? Nee dat kan je echt niet meer omheen in deze tijd. We hebben er volgens mij nog niet eens een aflevering AI gehad, dat is ook wel bijzonder. Oh niet meer? Ja ik denk dat we daar echt niet omheen kunnen, ik vind het echt iets, ik had toevallig vandaag met een collega van mij erover, het is heel lang zo geweest dat ik eigenlijk alles wel redelijk wilde weten, zeg maar hoe werkt het nou, nou dat is vooral met programmeertalen, met de cloud en ik wil graag weten wat zit er nou achter, dan hoef je niet een specialist of zo te worden, maar dan in ieder geval wel een beetje het gevoel van hoe werkt het. Bij AI heb ik dat echt, ja dat was bij machine learning eigenlijk ook al, maar bij generative AI heb ik dat helemaal losgelaten, ik weet echt niet, wat gebeurt hier nu? Ik las laatst dat ze zelfs niet eens weten wat er nou eigenlijk gebeurt, zeg maar, hoe komt chat GPT tot die tekst, dus wat er nou echt binnen, dus de routines die echt afvallen, ze hebben gewoon nu nog, dat kan eigenlijk niemand ook bij open AI kunnen, ze kunnen niet vertellen wat er gebeurt. Dat is ook bij Bart ook, dat ze zeggen, ja we leren hem elke keer dat hij dingen niet mag doen en dan kom je een week later terug en doet hij het alsnog. Ja precies, weet jij alsof je je kind aan het opvoeden bent. Ja, maar dat is eigenlijk wel, je traint en er zijn ook mensen die zeggen, het is eigenlijk geen AI, dat is gewoon, je leert gewoon een trucje, je geeft gewoon heel veel dingen en je zegt iedere keer, nee dit is het goede en dat is niet, en dan uiteindelijk komt er iets uit. Dat zijn we al jaren aan het doen toch, Google aan het trainen met are you a robot en dan, nee dit is een trap, dit is een trap, ja precies, eigenlijk wel ja. Ja al dat soort dingen, ik dacht wel dat zij dat gebruiken om hun algoritmes te trainen hoor. Ja dat is zo, dat klopt. Dat zou stom zijn als ze het niet doen. Overigens denk ik dat generative AI nog gevaarlijker is dan echte AI. Ik bedoel als je domme AI beslissingen laat nemen dan. Ja ik hoop niet dat dat gebeurt, het blijft volgens mij, je moet er nog steeds een menselijk input, want als jullie het misschien ook wel eens gehoord hebben, dat hij kan hallucineren zeg maar, hij kan gewoon echt dingen verzinnen die gewoon totaal niet slaan op wat je hem gevraagd hebt en als je daar jouw, ja weet ik veel, een business besluit op gaat baseren, ja automatisch en blind, ja dat wordt wel tricky. Maar ja, marketeers, ja die vinden het fijn om te helpen, ze geven me een stuk tekst, want dan, ja ik heb even een writer's block en dan heb je wel iets zeg maar. Ja het is, we doen hetzelfde toch, ik bedoel wij rammen iets in op Google, we kopiëren het van Stack Overflow, we filteren op Stack Overflow en dus ik snap heel goed dat als jij in een sector zit waar je teksten moet schrijven, dat het heel relaxed is om, het is makkelijker om vanuit een beetje een rough draft iets te doen dan helemaal vanuit het niets, dat hebben wij ook. Het is makkelijker om in een codebase, waar al, of in een codebase kleine aanpassingen te maken dan eerst de hele board template op de hoest uit. Ja dat zien we dus ook in de, in GitHub Actions, daar zag ik ook inderdaad hele handige, hoe noem je ze dingen, van die template-achtige. Ja het zijn workflows en die dingen heten Actions volgens mij. Ja ik moet zeggen ik kom dus van GitLab CI en ik vind de syntax van GitHub Actions wel vrij verbost ten opzichte van GitLab CI, GitLab CI is veel leaner, maar GitHub Actions is wel flexibeler. Ja precies. Dus maar ik denk als instap dat GitLab CI makkelijker te doen, misschien is het ook omdat ik tien jaar lang met GitLab CI heb gewerkt, maar ik ben ook bias. Maar om nog even jouw vraag, jij zei in het begin van ja, moet je beginnen of niet of wanneer moet je beginnen? Ik denk persoonlijke mening is gewoon zo snel mogelijk, want het is een beetje hetzelfde als met test, dan kom je zo'n codebase en er zijn er geen test en dan is het vaak altijd ja, we wilden meters maken, dus we hebben de test laten zitten of iets dergelijks of ja, ik bedoel, we hebben altijd allemaal briljante excuses waarom we geen test schrijven, maar uiteindelijk en dan komen we in de situatie dat ze zeggen, ja nu, het is nu zoveel, we kan nooit al die tests schrijven, terwijl ja, als je gewoon begint en dat is denk ik met CI ook, weet je, je begint gewoon met een hele simpele pipeline die die linters, die Git hoeks anders draaien, dat die ook nog even in de cloud gedraaid wordt, dan heb je in ieder geval, dan komen we weer op, het is makkelijker om dan een extra job daartussen te fietsen, die net weer iets meer doet, die unit test gedraaid, om zo langzaam naar iets wat daadwerkelijk een deployment doet van die pipeline, dan helemaal vanaf scratch dat op te gaan moeten zetten, dus ja. Ik ben met je eens ook omdat hoe je in Git gaat werken, dat is rand voorwaarlijk hoe je als team samen gaat werken, dus je kiest een branching strategie, je kiest hoe je merge request gaat, of pull request gaat afhandelen, wanneer je gaat deployen, dat zijn allemaal afspraken die je met je team moet maken, hoe kan je beginnen met developpen voordat je afspraken hebt gemaakt over hoe je de überhaupt software naar productie gaat werken? Ja, en mensen die erbij komen, die zien, oh, er is een pipeline, ik heb een stukje code gemaakt, ik voeg die test toe, het draait mee in de pipeline. Terwijl als het er niet is, dan doen mensen het niet, want niemand doet het, helemaal als je open source hebt natuurlijk, het is gewoon makkelijker, het nodigt uit, dus wanneer moet je doen nu? Ja, wacht er niet te lang mee, dat is eigenlijk je boodschap. Ja, je kunt niet zonder. Ja, maar die indruk heb ik wel, met elk project waar ik begin, dan weet je, heel vaak als ik met testers die dan ook net leren programmeren, die denken ook van nee, dat is toch allemaal niet nodig, die pipelines, dat is al een brug te ver, want ze moeten überhaupt leren wat programmeren is, maar ik merk wel in alles, ik begin een beetje een way of working te zijn, bij mij in ieder geval, ik kan niet zonder. Vroeger dacht je van ja, dan doe je dat toch al, maar nu denk je van ja, als het in zo'n pipeline zit, hoef ik niet te onthouden, ook gaat die project, ik moet dit doen, ik moet dit doen, ik moet dit doen. Het is ook een stukje te op een taartjesvaart. Als ik bash commando's vanuit een checklist, zit de copypasting naar m'n shell, kan ik beter gewoon in de pipeline zitten, die dat... Dat maakt je ook minder afhankelijk, want je zal net zien dat iemand heeft drie keer zo'n deployment achter elkaar gedaan, om de week, en dan na zes weken gaat die op vakantie en dan zit iedereen te kijken, wat was het ook alweer? Of hij moet dan documenteren en die documentatie is weer stuk. Ja, dat werkt niet. Het is net zoals je een docker image bouwt, weet je dat je een punt erachter moet zetten voor de context en dat iemand het dan copieert zonder punt. En dan denk ik, ja, het werkt niet. Nou, ik wacht wat tot Henk terug is van z'n vakantie. Zeker te wachten op die punt. Hey, maar goed, ik stel voor dat we doorgaan naar de tips. Dat is ons laatste onderdeel van deze podcast. Nou, ik denk dat we het toch wel een paar hebben genoemd, maar misschien kunnen we even een korte revue laten passeren. Ik heb ook met jullie meegeschreven, een paar dingen. Ik vond Rick, zo net begon je over GitHub Actions en ik heb ook wel eens meegewerkt. Ik vond die ook wel een beetje noemenswaardig, van mensen die nog nooit met GitHub überhaupt iets met pipelines gemaakt hebben. Kijk er eens naar, want het is best wel een interessante theorie ook wat ze beschrijven. Mooie documentatie, veel beschikbaar. En wat je zegt, je hebt dus heel veel van modulair die Actions die gewoon veel vrij beschikbaar zijn, waar je eigenlijk je pipeline mee op kan bouwen. Laat je niet afschrikken, ook zeker als je met CI gaat beginnen. Schrik niet van enorme jam op files, dus begin gewoon simpel. GitHub heeft volgens mij ook gewoon die runners die je kan gebruiken. Begin gewoon wat ik zeg, zo simpel mogelijk. Ik moet wel zeggen, ik vind dat een beetje, stel dat je GitHub is, want voor mij GitLab was eerder met, zeg maar, CI. Intervierde pipeline. Ja, dat was ook een beetje de filosofie toen van GitLab. Ik heb met pijn in mijn hart afstand gedaan van GitLab, maar het was denk ik vier of vijf keer zo duur ten opzichte van GitHub. Dus op een gegeven moment, dus weet je, ik moest het ook allemaal verkopen. Want ja, weet je, ik heb hier tien developers die hebben een licentie nodig. Het kost of 50 euro de neus per jaar of het kost 150 euro de neus. Ja, nee, precies. Qua kosten, ja, dat is natuurlijk sowieso die discussie die ga je dan krijgen. Ik vond het heel jammer, want ik was wel fan van GitLab. Maar ook, zeg maar, want we hadden toen redelijk snel. Ik denk dat het ook wel kon dat ze best wel vriendjes wilden zijn met Google, dat ze Kubernetes, zeg maar, integratie hadden ze ook wel heel vroeg. Ik dacht wel voordat het best wel hip was dat je gewoon dingen op kan spinnen, dat je dus vanuit je feature branch een werkend omgeving kreeg en dan kom je even testen. En als je dan goed begonnen had, een up klaar, strik je er omheen, werd alles weggegooid en je kon weer doorgaan. Dat waren de practices, daar waren ze best winst in mijn ogen, best snel bij. Volgens mij zet GitLab zichzelf ook meer in de markt als fullstack DevOps platform. Volgens mij was een filosofie from ID to deployment. Ja, volgens mij dat zal het wel zijn, ja. En GitLab, die zit in een kleiner deel, want het is gewoon een onderdeel van Microsoft. Sinds het overgenomen is door Microsoft zie je wel dat ze echt enorme stappen hebben gemaakt. In eenzelfde ecosysteem als GitLab proberen aan te bieden, tenminste zo zie ik het. Ik krijg het idee dat GitHub op een gegeven moment met features achter GitLab aan het aanlopen was, in plaats van dat het nu lijkt alsof we hier een enorme GitLab zitten te verkopen. Ja, we hebben je aandelen. Nee, maar dat gevoel had ik toen ook en ik vond het wel fijn dat GitLab er was, om een beetje GitHub scherp, zo zag ik het, ze hielden GitHub gewoon scherp. Dus dat heeft denk ik ons allemaal wel school. Iedereen was wel een beetje bang toen GitHub werd overgenomen door Microsoft, en ik denk dat het eigenlijk allemaal goed uitgepakt is als je kijkt. Ja, dat denk ik wel. En hetzelfde met Visual Studio Code natuurlijk, als je ziet hoeveel developers Visual Studio Code gebruiken. Microsoft nu is echt wel anders, een ander beestje zeg maar dan dat het vroeger was. Erik, heb jij nog, even los van alle nerdtalk die we tot nu toe hebben gedaan, heb je nog andere boekseries, websites of andere tips? Ik heb sowieso één boek dat ik altijd tegen iedereen zeg van dit boek moet je lezen, en dat is Clean Code van Robert C. Martin. Ja, het boek is denk ik uit de jaren 90, misschien begin 2000, maar het is nog steeds super relevant. Ook de YouTube filmpjes, die zijn ook heel tof. Ik denk dat je daar heel veel, of tenminste ik heb er zelf heel veel uitgehaald en heel veel geleerd. En ik ga nu niet jouw tips spoileren, maar ik zie een tip van jou staan. Ik ben een tijdje terug met de kinderen zijn wij naar het Game Museum in Soetermeer geweest. Nou dat is echt, je komt wel redelijk overprikkeld er vandaan, maar het is echt een hal vol met eigenlijk alle computer games van de arcade games uit de jaren 80 tot aan gewoon nu zeg maar. Tof. Super vet, maar je wordt wel helemaal simpel van de beepjes en de bliepjes, maar. Maar is het ook echt een locatie, is het tijdelijk of is het echt? Nee, volgens mij is het, ik weet niet waarom het museum heet, want het heeft vrij weinig met museum te maken. Het is eigenlijk gewoon een enorme gamehal, je komt met je museumkaart ook niet binnen. Maar je entry is volgens mij een slot van twee uur, misschien in dat kader een tip. Wij gingen toen naar het laatste slot van de dag en toen waren we een half uurtje te vroeg, maar toen mochten we een half uurtje eerder naar beneden. Goede tip trouwens. Maar ja, het is wel echt zeker als je een beetje van arcade games houdt, maar je kan ook gewoon Dugun doen. Oh, nice. Heel tof. Thanks voor de tip. Ja Gerard, ik heb ook even naar je geluisterd in die zin. Of jij nog wat interessante tips had. Ik heb Netlify toch maar even opgeschreven. Ja, dat lijkt mij wel. Die ken ik nog niet. Een goede tip. Ik zit al de hele tijd mijn hersenen te breken over, je hebt nog een tegenhang van Netlify die ongeveer hetzelfde doet, maar ik kan even niet op de naam komen. Versel. Versel, ja. Ik dacht anders lekker boeiend dat ik het heb gezegd. Ik denk als je met een C zit. Als je begint als web developer en je wilt eigenlijk gewoon een leuke front-end applicatie maken, je wilt wel code gebruiken, dus geen WordPress, dan denk ik dat Netlify en Versel uitermate geschikt zijn om dat te doen. Voor iedereen die leuk vindt op bijvoorbeeld met, ik zou zeggen doe lekker Nuxt met Vue. Dat is een aardige instap. En dan GitLab, Netlify. Dan denk ik dat je met een beetje effort dat je binnen een maand iets leuks online kan hebben. Als je dan een stapje verder wil, bijvoorbeeld iets met Kubernetes, dan zijn er ook platforms zoals Stridebase die dan dat moeilijker van Kubernetes voor je weg nemen. Sorry, Stridebase zeg je? Ja, Stridebase. En wat doet dat? Pace is het, P-A-C-E. Ja, eigenlijk is het een beetje wat Versel en Netlify doen, maar dan met ops voor Kubernetes, dus Managed Kubernetes Clusters, Inclusive Deployments. Volgens mij gaan ze binnenkort GitOps doen. Dus dan hoef je eigenlijk alleen nog maar in je Git repository te zeggen, nou dit is de image en dan whoep, dan flamt hij alles voor je de lucht in. Dus dat is wel een leuke, ik weet niet helemaal of ze al volledig online zijn, dat is een start-up die ik volg, dus hoog verwachten. Dank je wel, dank je wel. Heb je nog boekserie, websites of andere tips? Ja, misschien dat ik toch wel een klein beetje nerdy blijf hoor. In het begin hadden we het heel veel over kinderen, leren programmeren, dat soort dingen. En laatst hebben wij, dat was wel met volwassen hoor, met Code People hebben we een hackathon gedaan waarbij we robots in elkaar gingen zetten. En daar hebben we een robotje van gebruikt, een circuitmess van gebruikt, een circuitmess bij een hoop, als je dat zou vernederlandse. En ja, zij hebben eigenlijk heel veel Arduino bouwpakketten waarbij je bijvoorbeeld zelf een, hoe noemen we dat, een home assistant in elkaar kan zetten of een radiografische auto. En dan is het leuk dat je met je handen bezig kan zijn met de kinderen. Maar er is ook een stukje programmeren bij en daar maken ze gebruik van, volgens mij de building blocks, dat is eigenlijk een soort schilletje om zee heen, waarbij je gewoon blokjes in elkaar kan gooien en dan krijg je werk in de kolen. Dat is geschikt voor kinderen van 11 jaar. Dus als je het leuk vindt om wat met je kinderen samen te doen dan en iets met de techniek dan ja circuitmess is wel voor de jongere kinderen. Wij hadden voor ons een zo'n lego boost. Ja, dat is ook heel vet. De voorlopen van mindstorms, maar dan dus voor jongere kinderen. En dat is ook de nadeel is wel eens met de tablet, maar dan heb je inderdaad ook gewoon wel de core principes van het programmeren. Dus de building blocks, maar dan moet je die, dat zal bij jij uitlegd ook zijn. Die robot moet je dan opdrachten laten uitvoeren. En dat is dan ook onderdeel van bouwen. Dus op de tablet heb je de bouwinstructies en dan telkens bouw je een deel en dan laat je die dan dat deel dat je gebouwd hebt opdrachten uitvoeren. Maar die zijn hier nog wel mindstorms is het niet. Dat verloopt ze niet meer. Ik geloof dat boost ook gaat stoppen. Mindstorms hebben we ook nog inderdaad want dat gaat stoppen. Dus we hebben toen dat zagen ook nog snel een setje aangeschapt omdat het dat het wel echt echt heel leuk is. Ja, maar die zijn trouwens ook niet te krijgen meer. Maar goed, wel een soort van integratie was het allemaal onder support. Ik kon je ook met Java dan ook weer programmeren. Oh nee, Java doe ik niet. Nee, doe ik niet. Snap ik heel goed. Als we het hebben over Lego. Ik had ook nog een tipje. Ik zag toevallig iemand in een groepsjet. Blijkbaar een nieuwe Lego Pac-Man arcade komt er of misschien ook wel uitgebracht. Dus dan moet ik even checken. Maar dan kan je dus in een. Ik heb zelf ook zo'n zo'n Nintendo, zo fake Nintendo natuurlijk Lego pakket een keer gekregen. Oh, die heb ik gezien. Ja, dus de NES, maar van Lego. Ja, maar dan van Lego. Hij doet natuurlijk helemaal niks. Maar deze die volgens mij zit daar ook echt Pac-Man in. Dus ja, dat is misschien wel tof. Als je echt inderdaad van die oude games houdt. Ik had ook wel eens een keertje. Misschien heb ik deze tip al eens eerder gedeeld, maar ik kwam een keer tegen een website dat heette Review Pad en dan was ik nogal van onder de indruk, maar nog nooit echt gebruikt. Die heb ik wel gedaan. Ja, heb ik wel gedaan. Ja. Oké, dan gaan we die gauw stippen. Nee, maar ik mag hem twee keer tippen. Ja, Automated Code Reviews. Wauw. Dus dat de AI misschien weet je wel, je gaat te helpen om de developers in India. Dat is gewoon Review Farms. Ja, ik heb ook wel eens een tool. Ik heb een tool die genereert release notes op basis van je tips. Oh, echt? Of die doet suggesties voor je release notes op basis of de omschrijving van je pull requests. Maar ja, dat heb ik nog nooit gebruikt. Oké, cool. En het laatste tipje was DependerBot, want we hadden het net over GitHub Actions. Ik weet nog wel, toen ik nog bij Ahol werkte, daar waren we DependerBot aan het onderzoeken en dat werkte erg goed om insecure dependencies snel te detecteren. Uiteindelijk wat die deed was ook pull requests maken. Dat is een plugin voor GitHub toch? Ja, want ik zie er wel eens voorbijkomen dat zo'n bot voor je GitHub Actions is. Inderdaad. En dan doet hij automatisch pull requests. Je zou zelfs kunnen accepteren gelijk, maar goed, dat is aan jezelf denk ik. Hoe werkt dat dan? Dat vinkje ergens aan? Ja, het is echt zo simpel als een vinkje aanzetten en dan doe je het voor de hele organisatie en dan is het klaar. En dan krijg je pull requests en dan worden de developers heel erg irriterend. Er wordt er niks mee gedeployed. Nee, precies. Als je dat wil voorkomen, dan zie je het eruit. We hebben daar al een overwasp in de pipeline en dan eigenlijk het enige wat je ziet is suppression, suppression, suppression. Precies, laten we het staan. Maar goed, dat was het. Saber, heb jij nog? Ja, ik heb twee tips, jongen. De tweede is, daar begin ik mee, het slaat nergens op hè. The end of local host, dat is echt maar een blogpost van iemand en gaat erover, zeg maar, dat de ontwikkeldomgevingen, ja nu draaien we alles. We gebruiken Git, we pullen zeg maar de code of we clone een repository. We halen de code lokaal en gaan we op onze eigen ontwikkeldomgevingen lokaal ontwikkelen. Maar dit is de beweging dat je dan alles gewoon in de cloud hebt draaien. Dus je hebt volgens mij open telemetry, scaffold, dat zijn allemaal tools die dat ondersteunen. Ja, van GitHub heb je Codespaces volgens mij, Microsoft heeft DevBoxes. Dus ze zijn allemaal van dat soort dingen. Dus dan draai je eigenlijk alles in de cloud. En daar krijg je ook andere dingen. Je kunt sneller zeg maar je spullen binnenhalen, want alles draait daar toch al. En dat je ook wat meer samen deelt, zeg maar, in die omgeving. En ook dat je gewoon een definitie hebt van oké dit is een ontwikkeldomgeving, dit zijn alle tools die erop zitten. Druk op een knopje, je hebt er eentje bij, een on-boarder van mensen gaat makkelijker. Er zijn altijd voordelen die je daarbij krijgt. Maar goed, die blog posten die zet ik in show notes voorbij. En de serie Silo op Apple TV, die dat is nu de derde aflevering is. Ja, dat boeit nu niet. Wanneer je het luistert, maakt het natuurlijk niet uit. Maar die serie is gewoon leuk. Ik heb nu de derde aflevering gekeken. Ja, ik heb de boeken niet gelezen, want ik lees nooit boeken. Waarom zou ik boeken gelezen? Maar goed, stel de mensen die dit kennen, het is volgens mij een trilogie als boek. Waar gaat het om? Is het in de toekomst? Nou, volgens mij speelt, het is een science fiction film, ik wil niet zeggen dat het in de toekomst is, maar dit speelt zich volgens mij in de toekomst af en het is heel mysterieus. Ze hebben een heel grote silo, zeg maar. Daar leven heel veel mensen in en de buitenwereld is heel gevaarlijk. Je mag er niet uit, want als je eruit gaat, dan is het afgelopen en dan ben je dood en et cetera. En dan hebben ze wel ramen, mensen denken dat ze ramen hebben naar buiten toe. En via die ramen zie je dat de wereld er niet zo heel leuk uitziet, zeg maar. Maar ja, dat weten we dus niet, want je weet nog niet, is dat echt of is dat niet? En wie heeft die silo's gemaakt? En er is 140 jaar geleden, volgens mij, is er een opstand geweest, heel rellen en de bad guys zijn overwonnen. Nou, het is echt wel best een leuke, nee, niet best leuk, het is gewoon een hele leuke serie, echt wel heel goede acteurs ook. Nou goed, dat is mijn tip. Oké, nice. Daar moet je mee doen. Ja, oké. Het moet ineens denken aan een serie op Netflix, waar je ook, ik weet niet of het Netflix was, maar er was een serie waar je dus ook een groep mensen in een bubbel leefde, dus echt letterlijk. Ja, dat kan. Ja, moet even de titel even opzoeken, ik zat al te googelen, maar dan leek het een beetje op. Is het niet The 100? Ja, dat is hem, de serie 100. Ja, dan lijkt het een beetje op. Ja, die was vol corona zeg maar. Ik denk dat dit ook al een beetje ingegeven wordt door corona, van oké, je zit ergens in en je mag niet naar buiten en iemand anders bepaalt voor je. Weet je, ik denk dat dat ook een beetje ingegeven is, doordat we allerlei maatregelen tijdens corona hebben gehad en dat mensen zich dan allemaal een beetje gekneefeld hebben gevoeld. Maar goed, die science fiction boeken waren natuurlijk al veel eerder. Ja, dat is ook zo. Nou goed, ja, dan gaan we afronden. Dat was hem weer voor vandaag. Rick, Gerard, hartstikke bedankt voor jullie tijd. Ik denk dat we een hele leuke aflevering hebben gemaakt dat over CI en CD ging en DevOps een klein stukje. We hebben het ook veel over AI toch uiteindelijk gehad. Dat was uiteindelijk gewoon een beetje natuurlijk ontstaan, maar altijd leuk om weer over te hebben. Niemand weet of wij dat nu hebben gezegd of dat het gegeneerde is. Ja, wie weet. Misschien zijn we allemaal, ja, zit mijn bot hier nu. Even kijken. Maar goed, ja, in ieder geval nogmaals bedankt en natuurlijk ook onze luisteraars voor het luisteren. Hey, Rick en Gerard, hoe zouden de luisteraars jullie eventueel kunnen vinden op het grote internet? Google. Google. Rick de Groot. Ja, dan vindt hij heel veel hits, denk ik. Mocht je daar behoefte aan hebben, wat ik sterk betwijfel, maar dan kun je mij vinden op rickdegroot.io en vanuit daar kun je de rest wel vinden. Niet heel up to date, maar het is in ieder geval een entry point. Ja, precies. Je hebt in ieder geval een API waar we mee kunnen. Nou, sorry. Ja, ik denk dat ik doe een poging om zo goed mogelijk onvindbaar te blijven op internet, behalve op LinkedIn. Daar doe ik wel een poging om een of twee keer per week iets leuks over software development te plaatsen. Dus als je mijn naam Gerard van Engelen op LinkedIn zoekt, dan kun je me wel vinden. Maar in ieder geval gelukt. Ja, dat klopt. Wat misschien wel grappig is, als je überhaupt iets over mensen wilt vinden, dan moet je eerst naar delver.nl gaan. Delver is met ph en dat is toevallig een website van de Koninklijke Bibliotheek, die eigenlijk alle digitale teksten van de Koninklijke Bibliotheek ontsluit. Dus als je daar naartoe gaat en je zoekt op je eigen naam en je hebt een keer ergens in de krant gestaan, dan kan het zijn dat daar een krantartikel over naar voren komt. Nou, nul hits. Vijf minutes, no way dat die mij hoort. Ja, we hebben al vrij nauwkeurig te googlen na. Ja, dat is wel grappig. Nou, goed joh, dank je wel weer. Nou, toch weer. Wederom weer een tip, thanks. Oké, nou ja, nogmaals bedankt allemaal voor het luisteren. Ja, dit was de CodeKlets podcast over de CI-CD aflevering en alle relevante informatie over CodeKlets kun jullie natuurlijk vinden op codeklets.nl. En ja, we gaan natuurlijk ons best doen om de volgende aflevering heel snel weer op te nemen en weer naar jullie toe te sturen. Nee, toe te sturen is een beetje onzin, hè? Dat doen we niet. O nee, dat doen we met continuous delivery, toch? Met CD's. Ja, zeker. Ja, als je het nou gepost hebt, is het gewoon delivered. Ja, precies, precies. Druk op een knop. Hé, tot de volgende weer. Om het belletje in Spotify. Oh ja, dat zou ook nog kunnen, ja. Later. Later.