Allard Baronner nam, net als in de meetup twee jaar geleden, de aftrap. Als de anekdotes en de duidelijke opbouw van zijn betoog nog niet voldoende autoriteit op het gebied van Continuous Delivery (CD) zouden uitstralen, dan doen het afstuderen aan de Erasmus Universiteit en zijn proefschrift uit 2017 dat zeker wel. Hij benoemde niet alleen de voor- en nadelen zoals we die uit de boeken kunnen halen, maar ook de lastiger zaken bij implementatie. Denk aan technische uitdagingen, maar ook weerstand in en rond de organisatie. Het project bij Rijkswaterstaat diende als voorbeeld en hij vertelde hoe het daar steeds beter lukte om die weerstand te overwinnen. Zelfs tot op het punt dat vanuit andere projecten in de organisatie steeds vaker de vraag komt voor eenzelfde aanpak. Bottomline: CD is het vermogen om veilig en op elk moment aanpassingen op de productie-omgeving te kunnen doorvoeren. Er zijn wat extra uitdagingen bij gebruik van bepaalde tools en technieken, maar veel van de genoemde weerstanden bij implementatie gelden ook voor invoering van Agile Scrum. Het overwinnen daarvan gaat ook het best door het ´gewoon´ stapsgewijs in te voeren en te laten zien. Interessant was ook om te zien hoe de CD-pipeline zowel aansloot op de eigen CI-(ontwikkel) omgeving, als op die van leverancier ICTU.

Het technische deel van de presentatie kwam van Wijnand Top. En zeker nu er werd ingezoomd op de tooling, rezen er praktische vragen op. Waarop Wijnand vanuit zijn ervaring gelukkig ook praktische antwoorden had. Bijvoorbeeld: “hoe monitor je alle tools in de pipeline op veiligheidslekken?” Allereerst dien je bij selectie van (open source) pakketten kritisch te kijken naar ondersteuning van de community en de frequentie bij het oplossen van issues. Rijkswaterstaat gebruikt tools die hierbij assisteren, zoals OWASP Dependency Checker. Voor het bepalen van kwetsbaarheden in de hele codebase OWASP ZAP/ ZAPROXY. En voor het bewaken van de code kwaliteit gebruikt men voornamelijk SonarQube. Bij promotie van de code worden steevast alle tests gedraaid. Behalve een paar die nogal resource- en tijd intensief zijn zoals load tests. Die worden met minder regelmaat gedraaid, onder andere omdat de meeste updates daarop weinig invloed zullen hebben. Wijzigingen in het IVS-Next project kunnen nu steeds sneller veilig en betrouwbaar op productie geplaatst worden.