Si distribuye una aplicación de escritorio para Windows, el paso de empaquetado suele ser la parte menos interesante de su pipeline y la que más probabilidades tiene de romperla. La compilación en sí es limpia. Después la fase de empaquetado necesita makeappx.exe, makeappx.exe vive dentro del Windows SDK, y de repente su agente de compilación necesita una instalación del SDK de varios gigabytes fijada a una versión concreta solo para convertir una carpeta en un paquete.
Hay una forma de evitar eso, y no implica renunciar a las convenciones de herramientas que su pipeline ya utiliza.
Por qué la dependencia del SDK es el problema real
El Windows SDK es una herramienta de estación de trabajo de desarrollo. Ponerlo en un agente de compilación genera tres costes recurrentes.
El primero es el tamaño de la imagen y el tiempo de aprovisionamiento. Un agente alojado que tiene que instalar el SDK antes de poder empaquetar paga ese coste en cada ejecución limpia. Un agente autoalojado que lo lleva integrado carga con una imagen mucho mayor.
El segundo es la deriva de versiones. El comportamiento del empaquetado puede diferir entre versiones del SDK, así que en cuanto un agente tiene un SDK distinto de otro obtiene una compilación que pasa en una máquina y falla en otra por motivos que nada tienen que ver con su código.
El tercero es el incómodo. El SDK es una superficie grande que justificar ante quien aprueba lo que se instala en la infraestructura de compilación, y está haciendo un solo trabajo para usted: producir un paquete a partir de una carpeta.
El motor de empaquetado ya está en la máquina
El detalle importante es que el empaquetado MSIX no es algo que el SDK haga por sí mismo. El motor AppxPackaging es un componente de Windows. makeappx.exe es un envoltorio de línea de comandos a su alrededor que resulta que se distribuye dentro del SDK.
Eso significa que una herramienta puede llamar directamente al mismo componente del sistema operativo. forge_msix, la interfaz de línea de comandos de EtherApps Forge, hace exactamente eso. Es un reemplazo directo de makeappx.exe: los mismos verbos, los mismos parámetros, las mismas expectativas sobre lo que entra y lo que sale. Si su pipeline llama hoy a makeappx pack, cambia el nombre del ejecutable y la fase sigue funcionando.
Los verbos compatibles con makeappx son pack, unpack, bundle, unbundle, validate y make-pri. Si lo único que necesita es el comportamiento del SDK sin el SDK en el agente, ese conjunto lo cubre.
Una fase de pipeline mínima
La forma del asunto es poco llamativa, que es justamente el objetivo.
# 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
Merece la pena saber dos cosas sobre validate. Devuelve un código de salida distinto de cero cuando el paquete no es válido, que es lo que le permite fallar la compilación en lugar de descubrir el problema en el despliegue. Y el código de salida 2 significa concretamente que el paquete se analizó correctamente pero no es válido, frente al caso en que la herramienta no llegara a ejecutarse. Tratar esos dos casos de forma distinta en su pipeline es la diferencia entre una puerta de control útil y otra confusa.
Firmar sin un paso manual
El empaquetado y la firma tienden a separarse porque usan herramientas distintas, que es como los paquetes sin firmar acaban llegando a un anillo de pruebas.
Firmar desde el almacén de certificados por huella digital mantiene la clave privada donde corresponde y mantiene la pipeline declarativa:
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Use un servidor de marca de tiempo RFC 3161. Sin marca de tiempo, su paquete deja de validarse en cuanto caduca el certificado de firma, aunque se firmara legítimamente mientras el certificado estaba vigente. Con ella, la firma sigue siendo válida más allá de la vida del propio certificado.
Tenga en cuenta que sign es uno de los verbos de valor añadido y no uno de los compatibles con makeappx, así que necesita una licencia activa de Forge. Lo mismo aplica a create, test, assess, los verbos cert- y los verbos dev-.
Acortar el ciclo interno
La parte más lenta del trabajo con MSIX no suele ser el empaquetado. Es el ciclo: empaquetar, instalar, descubrir que algo está mal, desinstalar, cambiar una línea, repetir.
Los verbos dev-register y dev-test permiten registrar un paquete desde una carpeta sin construir e instalar un paquete completo cada vez. Para quien itera sobre capacidades del manifiesto, asociaciones de tipos de archivo o puntos de entrada, esto elimina la mayor parte de la espera.
Publicar actualizaciones
Una vez que la pipeline produce y firma paquetes, la distribución es la pregunta que queda. make-appinstaller genera un feed de actualizaciones de App Installer, que le da una URL que los clientes instalados consultan en busca de versiones nuevas. Para un ISV que distribuye fuera de un entorno gestionado, esa suele ser toda la historia de distribución: publique el paquete y el feed, y las instalaciones existentes se actualizan solas.
Dónde encaja esto
Este es un problema distinto del que aborda la mayoría del contenido sobre empaquetado de aplicaciones. El escenario habitual es un equipo de TI ante una aplicación cuyo instalador desapareció hace tiempo y cuyo fabricante original puede que ya no exista, que es un problema de captura y remediación. Ese trabajo vive en nuestra ruta de empaquetado y despliegue MSIX.
Lo que se describe aquí supone lo contrario: hay una carpeta de compilación sana, no hay nada que capturar, y la fricción es todo lo que ocurre después de que la compilación tenga éxito. Esa es la ruta de empaquetado MSIX para desarrolladores e ISV, y es un público genuinamente distinto con un conjunto de problemas distinto.
Si además necesita correcciones de compatibilidad para una aplicación que se empaqueta sin problemas pero se comporta mal dentro del contenedor, la preparación del Package Support Framework añadida en Forge 1.0.6 se cubre en las notas de la versión 1.0.6.
Pruébelo contra su propia pipeline
La prueba honesta es si su fase de empaquetado actual sigue funcionando cuando cambia el nombre del ejecutable. EtherApps Forge es una aplicación de escritorio de Windows con una prueba gratuita de 7 días, así que puede ejecutar esa prueba sobre una compilación real antes de decidir nada.