Als je een Windows-desktopapplicatie uitlevert, is de packagingstap meestal het minst interessante deel van je pipeline en tegelijk het deel dat hem het vaakst breekt. De build zelf is schoon. Daarna heeft de packagingfase makeappx.exe nodig, makeappx.exe zit in de Windows SDK, en ineens heeft je build-agent een SDK-installatie van meerdere gigabytes nodig, vastgezet op een specifieke versie, alleen om een map om te zetten in een pakket.
Er is een manier om daaromheen te werken, en daarvoor hoef je de toolingconventies die je pipeline al gebruikt niet op te geven.
Waarom de SDK-afhankelijkheid het echte probleem is
De Windows SDK is een tool voor ontwikkelaarswerkplekken. Hem op een build-agent zetten levert drie terugkerende kosten op.
De eerste is imagegrootte en provisioningtijd. Een gehoste agent die de SDK moet installeren voordat hij kan packagen, betaalt die kosten bij elke schone run. Een self-hosted agent die hem ingebakken heeft, draagt een veel groter image mee.
De tweede is versiedrift. Packaginggedrag kan verschillen tussen SDK-versies, dus zodra de ene agent een andere SDK heeft dan de andere, krijg je een build die op de ene machine slaagt en op de andere faalt om redenen die niets met je code te maken hebben.
De derde is de lastige. De SDK is een groot oppervlak om te verantwoorden tegenover wie tekent voor wat er op de buildinfrastructuur terechtkomt, en hij doet precies één ding voor je: een pakket produceren uit een map.
De packagingengine staat al op de machine
Het belangrijke detail is dat MSIX-packaging niet iets is wat de SDK zelf doet. De AppxPackaging-engine is een onderdeel van Windows. makeappx.exe is een commandoregelwrapper eromheen die toevallig met de SDK wordt meegeleverd.
Dat betekent dat een tool hetzelfde besturingssysteemonderdeel rechtstreeks kan aanroepen. forge_msix, de commandoregelinterface in EtherApps Forge, doet precies dat. Het is een drop-in vervanging voor makeappx.exe: dezelfde verbs, dezelfde switches, dezelfde verwachtingen over wat erin gaat en wat eruit komt. Roept je pipeline nu makeappx pack aan, dan verander je de naam van het uitvoerbare bestand en blijft de fase gewoon werken.
De makeappx-compatibele verbs zijn pack, unpack, bundle, unbundle, validate en make-pri. Als je alleen het SDK-gedrag nodig hebt zonder de SDK op de agent, dekt die set het af.
Een minimale pipelinefase
De vorm van het geheel is onopvallend, en dat is precies de bedoeling.
# Package a build output folder into an MSIX
forge_msix pack /d .\publish\win-x64 /p .\artifacts\ContosoApp.msix
# Validate before anything downstream touches it
forge_msix validate /p .\artifacts\ContosoApp.msix
Twee dingen zijn het weten waard over validate. Het geeft een exitcode ongelijk aan nul terug wanneer het pakket niet geldig is, en dat is wat je in staat stelt de build te laten falen in plaats van het probleem pas bij de uitrol te ontdekken. En exitcode 2 betekent specifiek dat het pakket succesvol is geanalyseerd maar ongeldig is, in tegenstelling tot een tool die helemaal niet kon draaien. Die twee gevallen verschillend behandelen in je pipeline is het verschil tussen een nuttige gate en een verwarrende.
Signeren zonder handmatige stap
Packagen en signeren raken vaak van elkaar gescheiden omdat ze verschillende tools gebruiken, en zo belanden ongesigneerde pakketten in een testring.
Signeren vanuit het certificaatarchief op thumbprint houdt de private sleutel waar die hoort en houdt de pipeline declaratief:
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Gebruik een RFC 3161-tijdstempelserver. Zonder tijdstempel valideert je pakket niet meer zodra het signeercertificaat verloopt, ook al is het rechtmatig gesigneerd toen het certificaat nog geldig was. Met een tijdstempel blijft de handtekening geldig tot voorbij de levensduur van het certificaat zelf.
Let op dat sign een van de verbs met toegevoegde waarde is en niet een van de makeappx-compatibele, dus daarvoor is een actieve Forge-licentie nodig. Hetzelfde geldt voor create, test, assess, de cert--verbs en de dev--verbs.
De inner loop verkorten
Het traagste deel van MSIX-werk is meestal niet het packagen. Het is de lus: packagen, installeren, ontdekken dat er iets mis is, deïnstalleren, één regel wijzigen, opnieuw.
Met de verbs dev-register en dev-test kun je een pakket registreren vanuit een map zonder elke keer een volledig pakket te bouwen en te installeren. Voor wie itereert op manifestmogelijkheden, bestandstypekoppelingen of entry points, haalt dit het meeste wachten weg.
Updates publiceren
Zodra de pipeline pakketten produceert en signeert, blijft distributie als vraag over. make-appinstaller genereert een App Installer-updatefeed, wat je een URL geeft die geïnstalleerde clients controleren op nieuwe versies. Voor een ISV die buiten een beheerd landschap uitlevert, is dat vaak het hele distributieverhaal: publiceer het pakket en de feed, en bestaande installaties werken zichzelf bij.
Waar dit past
Dit is een ander probleem dan waar de meeste content over applicatiepackaging over gaat. Het gebruikelijke scenario is een IT-team dat voor een applicatie staat waarvan het installatieprogramma allang verdwenen is en waarvan de oorspronkelijke leverancier misschien niet meer bestaat, en dat is een vastleg- en remediatieprobleem. Dat werk hoort thuis op onze route MSIX-packaging en uitrol.
Wat hier beschreven wordt, gaat uit van het tegenovergestelde: er is een gezonde buildmap, er hoeft niets te worden vastgelegd, en de wrijving zit in alles wat gebeurt nadat de build is geslaagd. Dat is de route MSIX-packaging voor ontwikkelaars en ISV's, en dat is een werkelijk apart publiek met een aparte set problemen.
Heb je ook compatibiliteitsfixes nodig voor een applicatie die schoon packaget maar zich misdraagt binnen de container, dan wordt de Package Support Framework-staging die in Forge 1.0.6 is toegevoegd behandeld in de releasenotes van 1.0.6.
Test het tegen je eigen pipeline
De eerlijke test is of je bestaande packagingfase blijft werken wanneer je de naam van het uitvoerbare bestand verandert. EtherApps Forge is een Windows-desktopapplicatie met een gratis proefperiode van 7 dagen, dus je kunt die test tegen een echte build uitvoeren voordat je iets besluit.