Om du levererar en Windows-skrivbordsapplikation är paketeringssteget oftast den minst intressanta delen av din pipeline och den del som mest sannolikt bryter den. Själva bygget är rent. Sedan behöver paketeringssteget makeappx.exe, makeappx.exe bor i Windows SDK, och plötsligt behöver din byggagent en flera gigabyte stor SDK-installation låst till en viss version bara för att göra om en mapp till ett paket.
Det finns ett sätt runt det, och det innebär inte att du ger upp de verktygskonventioner din pipeline redan använder.
Varför SDK-beroendet är det egentliga problemet
Windows SDK är ett verktyg för utvecklarens arbetsstation. Att lägga det på en byggagent skapar tre återkommande kostnader.
Den första är avbildningsstorlek och provisioneringstid. En hostad agent som måste installera SDK:t innan den kan paketera betalar den kostnaden vid varje ren körning. En självhostad agent som har det inbakat bär på en betydligt större avbildning.
Den andra är versionsdrift. Paketeringsbeteendet kan skilja sig mellan SDK-versioner, så i samma stund som en agent har en annan SDK än en annan får du ett bygge som går igenom på en maskin och fallerar på en annan av skäl som inte har något med din kod att göra.
Den tredje är den obekväma. SDK:t är en stor yta att motivera för den som godkänner vad som får ligga på byggmiljön, och det gör exakt ett jobb åt dig: producerar ett paket från en mapp.
Paketeringsmotorn finns redan på maskinen
Den viktiga detaljen är att MSIX-paketering inte är något som SDK:t gör på egen hand. AppxPackaging-motorn är en komponent i Windows. makeappx.exe är ett kommandoradsomslag runt den som råkar levereras i SDK:t.
Det betyder att ett verktyg kan anropa samma operativsystemskomponent direkt. forge_msix, kommandoradsgränssnittet i EtherApps Forge, gör precis det. Det är en drop-in-ersättning för makeappx.exe: samma verb, samma växlar, samma förväntningar på vad som går in och vad som kommer ut. Om din pipeline i dag anropar makeappx pack byter du namnet på den körbara filen och steget fortsätter fungera.
De makeappx-kompatibla verben är pack, unpack, bundle, unbundle, validate och make-pri. Om allt du behöver är SDK-beteendet utan SDK:t på agenten täcker den uppsättningen det.
Ett minimalt pipelinesteg
Formen på det hela är odramatisk, vilket är själva poängen.
# 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
Två saker är värda att känna till om validate. Det returnerar en exitkod skild från noll när paketet inte är giltigt, vilket är det som låter dig fälla bygget i stället för att upptäcka problemet vid utrullningen. Och exitkod 2 betyder specifikt att paketet analyserades framgångsrikt men är ogiltigt, till skillnad från att verktyget inte gick att köra alls. Att behandla de två fallen olika i din pipeline är skillnaden mellan en användbar grind och en förvirrande.
Signering utan ett manuellt steg
Paketering och signering tenderar att glida isär eftersom de använder olika verktyg, och det är så osignerade paket hamnar i en testring.
Att signera från certifikatarkivet med tumavtryck håller den privata nyckeln där den hör hemma och håller pipelinen deklarativ:
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Använd en RFC 3161-tidsstämpelserver. Utan en tidsstämpel slutar ditt paket validera i samma stund som signeringscertifikatet går ut, trots att det signerades legitimt medan certifikatet fortfarande var giltigt. Med en tidsstämpel förblir signaturen giltig bortom certifikatets egen livslängd.
Observera att sign är ett av mervärdesverben och inte ett av de makeappx-kompatibla, så det kräver en aktiv Forge-licens. Detsamma gäller create, test, assess, cert--verben och dev--verben.
Att korta ner den inre loopen
Den långsammaste delen av MSIX-arbetet är oftast inte paketeringen. Det är loopen: paketera, installera, upptäcka att något är fel, avinstallera, ändra en rad, upprepa.
Verben dev-register och dev-test låter dig registrera ett paket från en mapp utan att bygga och installera ett fullständigt paket varje gång. För den som itererar på manifestfunktioner, filtypskopplingar eller startpunkter tar det bort merparten av väntandet.
Att publicera uppdateringar
När paket väl produceras och signeras av pipelinen återstår frågan om distribution. make-appinstaller genererar ett App Installer-uppdateringsflöde, vilket ger dig en URL som installerade klienter kontrollerar efter nya versioner. För en ISV som levererar utanför en hanterad miljö är det ofta hela distributionsberättelsen: publicera paketet och flödet, så uppdaterar befintliga installationer sig själva.
Var det här passar in
Det här är ett annat problem än det som de flesta texter om applikationspaketering behandlar. Det vanliga scenariot är ett IT-team som står inför en applikation vars installationsprogram sedan länge är borta och vars ursprungliga leverantör kanske inte längre finns, vilket är ett infångnings- och åtgärdsproblem. Det arbetet hör hemma på vår väg för MSIX-paketering och utrullning.
Det som beskrivs här förutsätter motsatsen: det finns en frisk byggmapp, ingenting behöver fångas in, och friktionen är allt som händer efter att bygget lyckats. Det är vägen MSIX-paketering för utvecklare och ISV:er, och det är en genuint separat målgrupp med en separat uppsättning problem.
Om du också behöver kompatibilitetsfixar för en applikation som paketeras rent men beter sig illa inuti containern, täcks den Package Support Framework-staging som lades till i Forge 1.0.6 i versionsinformationen för 1.0.6.
Testa det mot din egen pipeline
Det ärliga testet är om ditt befintliga paketeringssteg fortsätter fungera när du byter namn på den körbara filen. EtherApps Forge är en Windows-skrivbordsapplikation med en kostnadsfri provperiod på 7 dagar, så du kan köra det testet mot ett riktigt bygge innan du bestämmer något.