Software builden op virtuele machines
Software moet eenvoudig en snel kunnen worden gebuild. Momenteel gebeurt dit allemaal manueel en vergt dit erg veel tijd. Ook het klaarzetten van de fysieke machine waarop de build zal worden uitgevoerd is manueel en statisch. Een van volgende situaties moet bijvoorbeeld kunnen gerealiseerd worden: software A moet kunnen builden op een Suse X machine met kernel Y en bibliotheken D, E en F, terwijl software B moet kunnen gebuild worden op CentOS H met kernel Z en bibliotheken E, J en K. Het is heel belangrijk dat deze omgeving correct wordt klaargemaakt, zodanig dat de software correct kan worden geïnstalleerd. Uiteraard is het onmogelijk om voor iedere softwareversie een fysieke machine bij te houden zodanig dat men die software snel kan rebuilden.
Een software proces is een belangrijke stap in het builden van software. Een build is een lijst van software versies. Deze laatste wordt gedefinieerd door een release note. We kunnen het builden van software beschrijven als het compileren en packagen (RPM weatie) van alle componenten in een releasenote. De probleemstelling van deze thesis situeert zich dan ook net in de buildomgeving. Deze omgeving bestaat uit een aantal componenten die een specifieke versie hebben zoals
* compilers (Java, C, ...)
* scripting talen (Perl, Bash, ...)
* packagers (RPM, ...)
* andere tools (make, maven, ...)
Vaststelling
( klik op figuur om te vergroten )
* Een releasenote komt overeen met een lijst van componenten met een bepaalde versie. Deze componenten zullen worden gebuild en gecompileerd in een package. Dit gebeurt in een specifieke buildomgeving met een bepaalde versie.
* Een buildomgeving evolueert mee met de software componenten.
* Niet alle buildomgevingen zijn op hetzelfde moment nodig.
Probleemstelling
* Het bijhouden van welke releasenote in welke buildomgeving wordt gebuild. (Hoe?)
=> deelprobleem: Mogelijk worden niet alle componenten voor één releasenote in éénzelfde buildomgeving gemaakt. Het uitgangspunt is om alle dependencies te laten builden in dezelfde buildmachine.
* Het hercreëer van de juiste buildomgeving op het moment dat men ze nodig heeft.
* Software moet worden gecompileerd in dezelfde omgeving als waar ze moet draaien.
Momenteel vergt dit erg veel energie voor de Valdiation Engineer die zich bevindt op stap (M) van Figuur 1.
Uitdaging
Newtec wil in de toekomst build omgevingen creëer op basis van Xen instanties. Xen is een technologie die gebruikt zal worden om het buildproces te vereenvoudigen. Het is een manier van virtualisatie. Xen biedt de mogelijkheid om een volledig gescheiden virtuele machine te laten draaien. Het uiteindelijke proces zal bestaan uit 4 stappen:
1. aanmaken van buildmachines, bestaande uit 2 complementaire stappen:
A) Aanmaken van nieuwe instantie
Hier begint men vanaf nul, er is enkel lege schijfruimte. De bedoeling is een tarball te maken die zich op een root filesysteem bevindt. Deze moet kunnen worden uitgepakt op een bepaalde partitie samen met een specifieke Xen kernel. Vervolgens wordt er een Xen config file aangemaakt. Vertrekkend van de fysieke machine ('domain 0' genoemd) wordt de virtuele machine opgestart. Eens deze virtuele machine opgebracht is, kan men een verbinding leggen naar deze virtuele instantie via het netwerk (zo biedt Xen ook consoles aan die men kan gebruiken om de virtuele instantie te bereiken). Indien men de virtuele machine niet meer nodig heeft, brengt men deze gewoon \textsl{down}. Een andere kan men dan eventueel \textsl{up} brengen, men kan uiteraard meerdere machines \textsl{up} brengen, afhankelijk van het beschikbare geheugen.
B) Verscheidene instanties die klaar staan
Hier vertrekt men van een bestaande instantie die reeds \textsl{up} gebracht is, dit wil zeggen met een buildomgeving geïnstalleerd.
De machine wordt in een begintoestand gebracht, door residu's van vorige builds te verwijderen. Hierop wordt vervolgens verder gewerkt. Indien men bepaalde machines nodig heeft, kan men ze on the fly aan of afzetten Zo bouwt men een zekere vorm van parallellisme op. Het builden van verschillende machines tegelijk is ook mogelijk.
2. Bepaal voor elke softwarecomponent welke buildomgevingen mogelijk zijn.
3. Ontleed vervolgens een releasenote en controleer welke buildmachines die nodig heeft. Wat zijn de componenten? Hoe komt men er aan?
4. Definieëren van de targets en de deploy omgevingen. Een target kan worden beschouwd als een machine die de uiteindelijke software zal draaien. Het is belangrijk dat de juiste buildmachine wordt gekozen die het meest vergelijkbaar is met deze target machine.
Mogelijke opties en uitbreidingen
* detecteren van de juiste buildomgeving: het starten van een build moet abstract kunnen bekeken worden. Commando's zouden als parameters kunnen worden meegegeven (make, bash, maven, ...)
* Er moet worden gecontroleerd of de build succesvol is. Indien hij succesvol is, kan men hem afhalen en wordt het resultaat geïdentificeerd en opgeslaan zodat het achteraf terug kan worden opgehaald. Indien het builden verkeerd loopt, zal er gemeld worden wat er precies fout ging.
De bedoeling is om stap per stap te werken. Indien men een werkend iets heeft, wil men net daarop verder gaan uitbreiden. Het is momenteel moeilijk in te schatten hoe vlug het doorlopen van opeenvolgende stappen zal gebeuren. Het direct meenemen van parametrisatie bv kan het geheel te ingewikkeld maken. Het maken van een basisversie waarop dan verder wordt uitgebouwd, is dan ook een must!
