Se distribuisce un'applicazione desktop Windows, il passaggio di packaging è di solito la parte meno interessante della sua pipeline e quella che più facilmente la rompe. La build in sé è pulita. Poi la fase di packaging ha bisogno di makeappx.exe, makeappx.exe risiede nel Windows SDK, e all'improvviso il suo agente di build ha bisogno di un'installazione dell'SDK da diversi gigabyte fissata a una versione specifica solo per trasformare una cartella in un pacchetto.
C'è un modo per aggirare tutto questo, e non comporta rinunciare alle convenzioni di tooling che la sua pipeline già usa.
Perché la dipendenza dall'SDK è il vero problema
Il Windows SDK è uno strumento da postazione di sviluppo. Metterlo su un agente di build genera tre costi ricorrenti.
Il primo è la dimensione dell'immagine e il tempo di provisioning. Un agente ospitato che deve installare l'SDK prima di poter creare il pacchetto paga quel costo a ogni esecuzione pulita. Un agente self-hosted che lo ha già integrato si porta dietro un'immagine molto più grande.
Il secondo è la deriva di versione. Il comportamento del packaging può differire tra versioni dell'SDK, quindi nel momento in cui un agente ha un SDK diverso da un altro si ottiene una build che passa su una macchina e fallisce su un'altra per motivi che non hanno nulla a che vedere con il codice.
Il terzo è quello scomodo. L'SDK è una superficie ampia da giustificare a chi approva ciò che finisce sull'infrastruttura di build, e sta facendo un solo lavoro per lei: produrre un pacchetto a partire da una cartella.
Il motore di packaging è già sulla macchina
Il dettaglio importante è che il packaging MSIX non è qualcosa che l'SDK faccia da solo. Il motore AppxPackaging è un componente di Windows. makeappx.exe è un wrapper a riga di comando attorno a esso che si trova a essere distribuito nell'SDK.
Questo significa che uno strumento può richiamare direttamente lo stesso componente del sistema operativo. forge_msix, l'interfaccia a riga di comando di EtherApps Forge, fa esattamente questo. È un sostituto diretto di makeappx.exe: gli stessi verbi, gli stessi switch, le stesse aspettative su cosa entra e cosa esce. Se la sua pipeline oggi chiama makeappx pack, cambia il nome dell'eseguibile e la fase continua a funzionare.
I verbi compatibili con makeappx sono pack, unpack, bundle, unbundle, validate e make-pri. Se le serve solo il comportamento dell'SDK senza avere l'SDK sull'agente, quell'insieme copre tutto.
Una fase di pipeline minima
La forma della cosa è poco appariscente, ed è proprio questo il punto.
# 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
Ci sono due cose che vale la pena sapere su validate. Restituisce un codice di uscita diverso da zero quando il pacchetto non è valido, il che le permette di far fallire la build invece di scoprire il problema al momento del deployment. E il codice di uscita 2 significa nello specifico che il pacchetto è stato analizzato correttamente ma non è valido, a differenza del caso in cui lo strumento non sia riuscito a partire. Trattare quei due casi in modo diverso nella sua pipeline è la differenza tra un controllo utile e uno che confonde.
Firmare senza un passaggio manuale
Packaging e firma tendono a separarsi perché usano strumenti diversi, ed è così che i pacchetti non firmati finiscono per raggiungere un anello di test.
Firmare dall'archivio certificati tramite impronta digitale tiene la chiave privata dove deve stare e mantiene la pipeline dichiarativa:
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Usi un server di marcatura temporale RFC 3161. Senza una marca temporale il suo pacchetto smette di essere valido nel momento in cui scade il certificato di firma, anche se è stato firmato legittimamente mentre il certificato era attivo. Con essa la firma resta valida oltre la vita del certificato stesso.
Da notare che sign è uno dei verbi a valore aggiunto e non uno di quelli compatibili con makeappx, quindi richiede una licenza Forge attiva. Lo stesso vale per create, test, assess, i verbi cert- e i verbi dev-.
Accorciare il ciclo interno
La parte più lenta del lavoro su MSIX di solito non è il packaging. È il ciclo: creare il pacchetto, installarlo, scoprire che qualcosa non va, disinstallarlo, cambiare una riga, ripetere.
I verbi dev-register e dev-test permettono di registrare un pacchetto da una cartella senza costruire e installare ogni volta un pacchetto completo. Per chi itera su capability del manifest, associazioni di tipi di file o punti di ingresso, questo elimina gran parte dell'attesa.
Pubblicare gli aggiornamenti
Una volta che i pacchetti vengono prodotti e firmati dalla pipeline, resta la questione della distribuzione. make-appinstaller genera un feed di aggiornamento App Installer, che le fornisce un URL che i client installati controllano alla ricerca di nuove versioni. Per un ISV che distribuisce fuori da un parco gestito, spesso è tutta la storia della distribuzione: pubblichi il pacchetto e il feed, e le installazioni esistenti si aggiornano da sole.
Dove si colloca tutto questo
Questo è un problema diverso da quello affrontato dalla maggior parte dei contenuti sul packaging applicativo. Lo scenario abituale è un team IT davanti a un'applicazione il cui installer è sparito da tempo e il cui fornitore originale potrebbe non esistere più, che è un problema di cattura e remediation. Quel lavoro vive nel nostro percorso packaging e distribuzione MSIX.
Quanto descritto qui presuppone il contrario: c'è una cartella di build sana, non c'è nulla da catturare, e l'attrito è tutto ciò che accade dopo che la build è riuscita. Questo è il percorso packaging MSIX per sviluppatori e ISV, ed è un pubblico davvero distinto con un insieme di problemi distinto.
Se le servono anche correzioni di compatibilità per un'applicazione che si pacchettizza senza problemi ma si comporta male dentro il container, la preparazione del Package Support Framework aggiunta in Forge 1.0.6 è descritta nelle note di rilascio 1.0.6.
Lo provi sulla sua pipeline
La prova onesta è se la sua attuale fase di packaging continua a funzionare quando cambia il nome dell'eseguibile. EtherApps Forge è un'applicazione desktop Windows con una prova gratuita di 7 giorni, quindi può eseguire quella prova su una build reale prima di decidere qualsiasi cosa.