Development

Software-ontwikkeling
wanhoop

Testen van open source vergt extra aandacht

Grote onderlinge afhankelijkheden maakt testen complex.

© Shutterstock Arjuna Kodisinghe
2 mei 2019

Grote onderlinge afhankelijkheden maakt testen complex.

Recente debacles met de najaarsupdate van Windows 10 tonen aan dat ook na grondig testen eigenlijk nog meer testen nodig zijn. Bij Microsoft voltrekt het hele ontwikkel- en testproces zich nog binnen één bedrijf. Bij de ontwikkeling van opensource-code moet de community zich de testdisciplines zelf opleggen, maar ook rekening houden met andere communities. 

Project Zuul, dat net als Kata Containers deze week een officiële erkenning kregen van de OpenStack Foundation, is precies gericht op dat dilemma. "Wij gaan er van uit dat alles dat niet getest is, niet deugt", stelt Jim Blair, een van de initiatiefnemers van het project. "We willen er zeker van zijn dat we alles testen en als we het doen dat we het consistent en correct doen."

Bovendien, zegt Blair, wil je voorkomen dat een wijziging die je hebt aangebracht in de productiecode uiteindelijk toch niet zo handig blijkt in praktijk doordat er conflicten optreden met software van andere projecten die gebruik maken van de code. Blair: "Zit de wijziging er eenmaal in, dan zul je hem moeten onderhouden." 

Productie simuleren 

Zuul is er daarom op gericht zoveel mogelijk te testen alsof de voorgestelde code onderdeel is van productiecode. Zo kun je door simulaties uit te voeren, zien wat jouw nieuwe code doet met de rest van de code waar deze onderdeel van gaat uitmaken. Dat voorkomt verrassingen achteraf.  Dat proces dwingt Juul af, en maakt daarbij onder meer gebruik van Ansible, het populaire opensource configuratiemanagement en deployment tool. 

BMW al jaren fan

Zuul werd in 2012 opgezet om het testen en de continue integratie van alle projectgroepen die werkten aan het OpenStack-platform te faciliteren. In mei 2018 werd het met de release van versie 3.0 een zelfstandig project. Inmiddels had het gereedschap al fans in aansprekende organisaties buiten OpenStack.
Zo gebruikt BMW Zuul al enkele jaren als een continuous integration, delivery en deployment system (CI/CD-tool) bij alle softwareprojecten van het bedrijf. "Software is al een aantal jaar essentieel voor het verzorgen van veiligheid en comfort in auto's", zei Tobias Henkel, software engineer bij BMW op de OpenStack-conferentie in Berlijn vorig jaar. "De hoeveelheid software om deze eigenschappen mogelijk te maken, maar ook de complexiteit als gevolg van de vele configuratie-opties van moderne auto's neemt steeds verder toe. De bedrijfsbrede inzet van CI/CD is een van de essentiële tools om alle softwarecomponenten op tijd te kunnen leveren en integreren met de vereiste kwaliteit."

Zelf vervolgstappen nemen

Zuul is ontwikkeld om zo veel mogelijk werk van de tester uit handen te nemen. De software kan bijvoorbeeld besluiten nemen over vervolgstappen in de testprocedure. en de vervolgstappen kunnen resultaten uit eerdere test gebruiken. Zuul maakt daarvoor als cloudgebaseerde tool gebruik van de voordelen van de cloud. Blair: "We vinden dat we clouds zo veel mogelijk moeten gebruiken voor het automatiseren van repetitieve taken. Daar zijn mensen niet goed in. We moeten mensen gebruiken voor dingen waar ze wel goed in zijn zoals problemen oplossen en nieuwe dingen bedenken."

Er zijn meer CI/CD-tools beschikbaar zoals Jenkins en Spinnaker, maar Zuul onderscheidt zich daarvan doordat het eenvoudiger omgaat met veel verschillende softwareprojecten en repositories die allemaal naar een gemeenschappelijk doel werken.

Kader CI/CD noodzakelijk voor volgende generatie netwerken

De netwerken van de telecomindustrie zijn inmiddels een complex samenspel geworden van een grot aantal open technologiën zoals IaaS, Software Defined Networking (SDN)  en Network Functions Virtualisation (NFV).

Een groot aantal teams werken ieder voor zich aan een continue verbetering van die technolgieën. Hoewel de projectteams zelf aandacht hebben voor de veilige en consistente ontwikkeling van hun code, kunnen wijzigingen leiden tot onverwachte conflicten op een hoger niveau bij het samenspel van die platformen en tools, zoals bijvoorbeeld OpenStack en OpenDaylight.

Dat is de problematiek waar het OPNFV of wel het Open Platform for NFV (Network Functions Virtualisation) zich over buigt. De leden van de verschillende commissies binnen OPNFV komen van bedrijven die de grote wereldomspannende netwerken bouwen en exploiteren. Fatih Degirmenci, principle developer bij Ericsson legt uit dat de commissie van de OPVFN waar hij in participeert zwaar leunt op CI/CD-tools om de integratie en validatietests te doen die nodig zijn voor de leden softwarewijzigingen kunnen implementeren. "Het is eenvoudigweg niet handmatig te doen. Wij krijgen al de testcases van tientallen opensourceprojecten die we dan weer in samenhang testen."

Vinden de OPFNV-teams problemen, dan gaan ze in gesprek met de betrokken projectteams of helpen ze de problemen op te lossen. 

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.