15 års release-engineering

"It was fifteen years ago today ..." nej, jeg skal spare jer for en Sct. Pepper parodi, men for snart 15 år siden udkom FreeBSD 1.0.

Ikke ret lang tid efter arvede jeg jobbet som release-engineer for FreeBSD 2.0 og det er ikke et job man nogensinde kan slippe helt igen.

Det er let at være release engineer for en eller anden applikation hvor der bare skal leveres noget source-kode: to kommandoer, en til at hive sovsen ud af et versionskontrolsystem og en rulle til en tar-ball.

Hvis man derimod prøver at release et helt operativsystem, inklusive 3. parts software, så skal der nogle flere armbøjninger til.

Mange flere.

Først skal man gøre sig klart hvilke egenskaber det færdige release skal have.

I FreeBSD's tilfælde skal releaset kunne bootes og installeres.

Men det stopper ikke der.

Det nytter f.eks ikke at brugeren stopper en CD i drevet, installerer og alt kører smukt, hvis han bagefter får et helt andet resultat ved at compilere de sources han har fået med.

Tilsvarende duer det heller ikke til noget, hvis de 3.parts pakker han installerer fra releaset ikke kan køre med den version af FreeBSD der ligger på releaset.

osv.

Lige nu sidder jeg og er ved at release noget software til en kunde, der skal leveres tre forskellige boot-bare disk images, samt en server- og en workstation-installation.

Som en lille krølle på halen, skal kunden kunne hive DVD skiven ud af pengeskabet om 12 år og udvikle videre på softwaren og rulle et nyt release selv.

Med andre ord, skal jeg lave en procedure der kan lave et release der kan lave et release. der kan stable skildpadder op, hele vejen ned.

Lugter det lidt af ISO9000 ?

Det burde det.

I virkeligheden stopper release-engineering ikke når leverandøren afleverer sit release, processen bør fortsætte hos brugeren, som bør have en helt klar og gerne automatiseret process der starter med leverandens release-medier og slutter med et kørende system.

En af de primære grunde til at der stadig kører FreeBSD 4.x systemer rundt omkring er, at folk ikke aner hvordan de blev installeret.

En opdatering er derfor enten en nyinstallation hvor man opdager alle de samme gamle ting og laver alle de samme løsninger forfra, eller det er en arkæologisk ekspedition or at dissekere det kørende system så man kan bygget et nyt tilsvarende.

Og derfor sker opdateringer ikke når de burde.

Mit seneste lille projekt hedder "sysbuild" og er et forsøg på at automatisere installationen af et FreeBSD system, baseret på de oprindelige releases fra software leverandørene, kraftigt inspireret af mit NanoBSD projekt til produktion af indlejrede FreeBSD systemer.

Mere om det næste gang...

phk