Veel bedrijven werken nu of gaan werken conform de DevOps methodiek. Volgens deze methodiek heeft ieder team zijn eigen verantwoordelijkheid over een bepaald gedeelte van de software. Hierdoor kunnen ze sneller ontwikkelen en deployen naar productie. Een nadeel van deze manier van werken is dat niemand het overzicht meer heeft over de gehele keten van applicaties binnen een bedrijf. Dit kan tot problemen leiden, vooral als er een complexe keten van applicaties en/of batches aanwezig is met diverse achterlanden binnen één organisatie. Een kleine aanpassing in een achterland of in de front-end kan grote gevolgen hebben voor de gehele keten. Aangezien het testen van de gehele keten buiten de scope van het DevOps team valt, worden de gevolgen voor de keten vooraf niet afgedekt.
Er zijn meerdere manieren om ervoor te zorgen dat de gehele keten blijft werken. Een manier om dit soort productie problemen te voorkomen is om een scrum-of-scrum te houden met de verschillende partijen in de keten. Dit werkt goed als de diverse partijen binnen de keten op dezelfde fysieke locatie zitten en binnen dit overleg in het kort de diverse aanpassingen bespreken waarna de ketenimpact kan worden bepaald. Om de scrum-of-scrum te laten slagen is het van belang dat elke partij binnen de keten iemand afvaardigt met voldoende kennis van de applicatie en de keten. Echter als de keten complex is en veel verschillende partijen bevat, is een scrum-of-scrum niet handig. Het wordt nog lastiger als de diverse afdelingen op verschillende locaties zitten waardoor een scrum-of-scrum helemaal niet mogelijk is.
Een andere manier om de correcte werking van de keten te waarborgen is om een ketentest te houden bij elke wijziging. Een ketentest geeft een goed beeld of de diverse applicaties nog correct met elkaar communiceren en of de keten nog correct werkt. Het nadeel van een ketentest is dat het tijd kost om zo'n test op te zetten en er goede afspraken moeten worden gemaakt tussen de diverse DevOps teams. Als dit echter goed is ingericht dan hoeft de uitvoering van een ketentest niet lang te duren. Door een ketentest regelmatig uit te voeren, zullen de betrokkenen partijen ook met elke ketentest meer kennis en ervaring op doen. Daardoor wordt de doorlooptijd van een ketentest verkort en kunnen changes nog steeds snel naar productie. Alleen nu met de zekerheid dat de gehele keten blijft werken.
Ondanks dat een ketentest een goede manier is om de kwaliteit binnen een keten te waarborgen, zie je dit in de praktijk niet vaak gebeuren. De belangrijkste reden hiervoor is dat iemand het initiatief moet nemen en de tijd moet investeren om de diverse partijen bij elkaar te krijgen. Aangezien de ketentest niet de verantwoordelijkheid is van één DevOps team maar van alle teams binnen de keten is het moeilijk om één team de verantwoording te laten pakken.
Soms zie je dat er een ketentest wordt geïnitieerd vanuit een programma dat een wijziging wil doorvoeren wat impact heeft op een gehele keten. Hiervoor wordt in sommige gevallen een los ketentestteam opgezet. Zelf vind ik een los ketentestteam een slechte optie omdat deze mensen de kennis niet hebben van de diverse onderdelen binnen de keten. Dit aparte team zal alsnog de mensen van de DevOps teams moeten raadplegen om de diverse testgevallen te bepalen. Net als voor ondersteuning als het resultaat afwijkt van de verwachting, omdat bij het ketentestteam de kennis hiervan ontbreekt.
Naar mijn mening is het de moeite waard om te investeren in een ketentest om de kwaliteit te waarborgen. Doordat deze ketentest regelmatig wordt uitgevoerd, blijft de werking van de keten gewaarborgd. Om dit op te zetten zal tijd geïnvesteerd moeten worden, maar uiteindelijk betaalt dit zich terug. Doordat de werking van de keten gewaarborgd blijft, voorkom je incidenten in productie. En fouten herstellen in productie is talloze malen duurder dan in de testfase…