Transcript

‘mLinux’ bouwen: black-art of QA-proces ? © ALbert Mietus, PTS software BV Begrippen [Hidden sheet] m Linux Embedded Linux (verkorte schijfwijze) E- m Linux Easy/Embedded Linux (inclusief tools) ( E- * is ‘naam’ van mijn generieke bouw-omgeving) QA Quality Assurance (verkorte schijfwijze) Kernel Kern-deel van een OS (Linux is een kernel) Tools (hier) Aanvulling op ( Linux )kernel, om volledig OS te krijgen E.G. shell(s), ls, mkdir,cron, ssh, ftp  Busybox Set van tools, speciaal voor m Linux  thttpd Kleine web-server, bijvoorbeeld voor embedded systemen. Agenda Linux, … by magic Zo doet u het (toch) niet QA, wat & waarom beheer & reproduceer m Linux & QA de kunst van automatisch bouwen van kunstwerk tot maatwerk Linux, … by Magic Ofwel: Hoe komt uw buurman aan zijn Linux? Linux, by magic Linux wordt gebouwd door super-specialisten Grote delen komen rechtstreeks van het internet Delen worden geïntegreerd totdat het niet meer werkt Patches (bugfix) worden gebruikt, zodra ze beschikbaar zijn Het enige dat telt: is een ‘gratis’ OS , liefst ASAP! Throw know-how away (important!) Add Tools Try-out OK? Mostly not Sometimes Kernel x.y Config TovernaarsVragen Welke features zitten er in MagicLinux ? Bevat onzeLinux ook bugfix No ? Wat is het verschil met de vorige release ? Zijn er verder geen verschillen ? Zeker weten? Deze vragen blijven vaak onbeantwoord! Q uality A ssurance ‘ Zeker weten wat de kwaliteit is’ QA, traditioneel QA is vaak een zwaar proces dat probeert te verzekeren dat, in een complexe omgeving, een ingewikkelde verandering voldoende succesvol is. QA is gericht op het proces, niet het product! QA levert niet direct kwaliteit, maar probeert die kwaliteit constant te houden Effect: veel overhead, input van ‘buiten’ niet vertrouwen Kwaliteit in embedded systemen Voor embedded systemen is het eenvoudig Het ‘doosje’ moet altijd werken. Zo niet, dan zal de klant  Het opnieuw proberen  Een paar tikjes op het systeem geven  Het systeem weggooien En een nieuwe kopen, soms van de concurrent Met andere woorden : Zorg dat u weet wat u levert! Goedkoop? => foutjes worden geaccepteerd QA in embedded systemen QA kan (dus) veel eenvoudiger  De Q-eis is veel eenvoudiger: ‘altijd werken’  De omgeving is eenvoudiger: ‘het doosje’  De verandering is eenvoudig: ‘…’  De SW is relatief klein van omvang. QA in embedded systemen moet gericht zijn op de ‘in ontwikkeling zijnde’ revisie! Want er is (vaak) maar één release Linux & QA Ofwel: Hoe ‘ uw Embedded-Linux ’ bouwen? QA en Linux PRAGMA'S (Kom naar de stand voor uitleg) Vertrouw Linux Zeker het deel dat veel gebruikt is. Vertrouw eigen veranderingen NIET Die zijn te ‘weinig’ gebruikt. Vertrouw het bouwen ‘ by magic ’ NIET Dat is niet herhaalbaar. Vertrouw uw kennis En leg deze vast! Voorkom overhead Altijd een goed idee Eenvoudig QA in Linux QA in Linux kan, door: Het ‘ by magic ’ proces te standaardiseren Te concentreren op ‘eigen inbreng’ De Q van ‘veel’ is goed genoeg Pragmatische aanpak: automatisch bouwen modulair bouwen Effect: (operationele) QA-kosten zijn nihil (of minder!) Automatisch bouwen Bouw automatisch, aan de hand van een configuratie file Deze configuratie: bevat: versienummers, filenamen, download-sites, bouwopties, etc, ... patches met eigen opties, modificaties, etc, … wordt beheerd en ‘opgeleverd’ Bouwen met gelijke configuratie geeft hetzelfde resultaat Configfile(s) TEST co/ verbeter /ci Versie Beheer insert/check fetch patch unzip install make File-list Voorbeeld Template 1 Versie beheer info Relatief pad Wat we bouwen Welke versie En onze veranderingen (hier: config data) default: busybox-0.60.5 Ja, het is een ‘Makefile’ Type: port # ConfigFile, for E- m Linux # $Id: GNUmakefile,v 1.7 2003/09/18 12:20:37 GAM Exp $ # Where is YourEmbeddedLinux? TOPDIR = ../../../. #Module settings PORTNAME = busybox PORTVERSION = 0.60.5 PATCHES = patch-aa patch-ba # Install options ... INSTALLOPT ="PREFIX=${LIVEDIR}" ## Overrule the default Epkg-name #PKGNAME = include ${TOPDIR}/Mk/port.mk Modulair bouwen Opdelen op in (sub)modules Linux, busybox, thttpd, shell(s), … eigenApplicaties, … Per (sub)module een configuratiefile Er kan dus per module gebouwd, getest en beheerd worden Speciaal type configuratiefile: ‘dir’ (of: ‘module’) Bepaalt de bouwvolgorde (sub)modules DUS : ook dat (kan) beheerd & gecontroleerd worden Voorbeeld Een iets andere template Zie ook 2 sheets terug Alle (sub)modules elk in een eigen directory Volgorde is (hier) niet belangrijk Als nodig, leg de gewenste bouwvolgorde (hier) vast Een ander ‘template’ Type: subdir # ConfigFile, for E- m Linux # $Id: GNUmakefile,v 1.21 2003/09/18 13:28:17 ami Exp $ # Where is YourEmbeddedLinux ? TOPDIR= ../../. # Modules to build SUBDIRS += busybox SUBDIRS += links e2fsprogs SUBDIRS += thttpd dhcpcd SUBDIRS += bash dcron netkit SUBDIRS += linux-utils isdn4k-utils #Order to build (“After”: “Before”) busybox: bash include ${TOPDIR}/Mk/subdir.mk QA-‘niveau(s)’ Er is altijd een afweging: (bij gelijke functionaliteit) kosten  kwaliteit . We kunnen dit instellen, door meer of minder ‘ config checks ’ in de configfile op te nemen. md5-checksums  chrooted bouwen File-list  versies van compilers e.d. Het maakt de bouwomgeving duurder (ontwerp, diskruimte, configuratietijd, bouwtijd, …) Maar geeft een grotere garantie op kwaliteit Dit is een ‘management keuze’! Samenvatting & Conclusies (1)  Bouw ‘ m Linux’ door kennis vast te leggen! Vastleggen == documenteren==controleerbaar==herhaalbaar  Externe Wizards helpen niet Dan wordt ‘ by Magic ’ slechts verborgen  Beheer[s] de (module)configuraties Het eigen team moet het beheer s en  Investeer in een maatwerk bouwomgeving Hier is vaak wel externe kennis nodig  Concentreer op ‘eigen … inbreng …’ Wat extern veel gebruikt is, is vast wel goed Samenvatting & Conclusies (2)  QA van ‘Linux’ is mogelijk en eenvoudig Dit hebben we laten zien  Concept is belangrijkste, daarna pas tooling Tools maken het efficiënter, niet beter  Kies een kwaliteitsniveau, dat past Nog beter, is ook complexer en duurder  Kies tools voor ‘ m Linux’ Kan die ‘mooie’ overweg met embedded beperkingen?  ‘ Just do it’! (en verbeter, zodra nodig) Begin goedkoop, verbeter tot het benodigde niveau!