WinGet y YAML para automatizar la instalación de software

Montar un PC nuevo o incorporarte a un proyecto suele implicar repetir una y otra vez las mismas instalaciones de programas, ajustes de Windows y herramientas de desarrollo. Con WinGet y archivos de configuración en YAML podemos convertir todo ese proceso en un solo comando, sin tener que ir uno por uno descargando instaladores y haciendo clic en asistentes eternos.

WinGet (Windows Package Manager) es la respuesta oficial de Microsoft al modelo de gestores de paquetes de GNU/Linux como apt o dnf. Combinado con la Configuración de Estado Deseado (DSC) de PowerShell y con archivos de configuración declarativos en formato YAML, permite dejar cualquier máquina Windows lista para trabajar de forma repetible, automatizada y colaborativa, tanto en entornos personales como empresariales.

Qué es WinGet y por qué importa para la automatización

WinGet es la herramienta de línea de comandos del Administrador de paquetes de Windows que viene integrada en las versiones actuales de Windows 10 y Windows 11 (a través del “Instalador de aplicaciones” de Microsoft Store). Su comando principal es winget, al que se le añaden subcomandos para buscar, instalar, actualizar, desinstalar o configurar software.

Frente al modelo tradicional de ir a la web de cada programa, descargar el instalador y hacer clic en Siguiente, WinGet actúa como un índice centralizado: usa la Microsoft Store y un repositorio comunitario en GitHub como orígenes, y se apoya en manifiestos en formato YAML (llamados manifiestos de paquete) que describen cómo instalar cada aplicación y cómo verificar su integridad mediante hashes como SHA256.

El ecosistema de WinGet se compone de tres piezas: la propia herramienta de línea de comandos, los servicios de empaquetado que alojan y validan los paquetes, y los archivos de configuración de WinGet, que son los que permiten consolidar toda la configuración de un equipo o de un proyecto en un único fichero declarativo.

Para desarrolladores y administradores, esto significa poder describir las herramientas y configuraciones necesarias para un entorno de trabajo (IDE, navegadores, SDK, utilidades, políticas de Windows, etc.) y que WinGet se encargue de dejar la máquina en el “estado deseado” de forma fiable y repetible, tanto si es un portátil nuevo como si estás preparando varios equipos en una empresa.

Comandos básicos de WinGet para gestionar aplicaciones

Antes de meternos en YAML y automatización avanzada, merece la pena tener claros los comandos básicos de WinGet, ya que son la base de todo lo demás. Para empezar, basta con abrir PowerShell, Windows Terminal o incluso el símbolo del sistema y teclear winget para ver la ayuda general.

Instalar aplicaciones individuales es tan sencillo como usar winget install seguido del identificador o nombre del paquete. Por ejemplo, para instalar Visual Studio Code desde el repositorio de WinGet podrías ejecutar:

winget install Microsoft.VisualStudioCode

Actualizar aplicaciones también se hace desde la línea de comandos. Con winget upgrade --all se intentan actualizar todos los programas que WinGet sea capaz de gestionar (no solo los instalados con WinGet, en las versiones recientes). Si quieres centrarte en una aplicación concreta, puedes usar por ejemplo:

winget upgrade Microsoft.VisualStudioCode

Para desinstalar software, se emplea winget uninstall, de nuevo seguido del nombre o identificador del paquete, por ejemplo: winget uninstall Microsoft.VisualStudioCode. La desinstalación se limita a lo que WinGet reconoce, ya sea porque lo instaló él o porque detecta el programa en el sistema.

La búsqueda de aplicaciones disponibles se realiza con winget search. Si escribes winget search notepad, obtendrás un listado de paquetes que contienen ese término, junto con el origen (Store o repositorio), el nombre y el ID, que es lo que te conviene usar al instalar desde el repositorio comunitario para evitar ambigüedades.

Por último, puedes listar el software instalado que WinGet detecta en la máquina usando winget list. Esto te ayuda a identificar qué paquetes puedes gestionar directamente con el gestor de paquetes y cuáles no.

Archivos YAML de configuración de WinGet: la clave de la automatización

El verdadero salto de calidad llega cuando pasamos de ejecutar comandos sueltos a usar un archivo de configuración de WinGet en formato YAML. En lugar de lanzar manualmente decenas de comandos, describes el estado final deseado de la máquina y ejecutas un único comando para que todo ocurra de forma desatendida.

Un archivo de configuración de WinGet enumera versiones de software, paquetes, herramientas, dependencias, scripts y configuraciones del sistema necesarias para dejar un entorno de desarrollo listo. A todo esto se suma la integración con Desired State Configuration (DSC) de PowerShell, que es la tecnología que permite aplicar cambios de configuración en el sistema operativo y en las aplicaciones usando recursos especializados.

La magia se produce con el comando winget configure, disponible a partir de WinGet v1.6.2631. Este comando toma el archivo YAML (o con extensión .winget), lo valida contra un esquema JSON, descarga los recursos de DSC necesarios y aplica todas las aserciones y recursos declarados para empujar al equipo hacia el estado deseado.

La gran diferencia frente a un script tradicional es que estos archivos son declarativos: definen el resultado que quieres, no una secuencia rígida de pasos. WinGet y DSC se encargan de calcular qué hay que hacer, en qué orden y qué puede ejecutarse en paralelo, lo que aporta robustez y flexibilidad a la automatización.

Además, son ideales para colaborar: los archivos de configuración pueden almacenarse en repositorios de Git (por ejemplo en GitHub), en ubicaciones privadas como OneDrive o similares, y compartirse con el equipo. Se pueden crear issues, pull requests y revisar cambios como cualquier otro fichero de código.

Estructura y formato de un archivo de configuración de WinGet

El formato de los archivos de configuración se basa en YAML pero con una especificación de esquema JSON que ayuda a validar la estructura. Microsoft publica los esquemas en la dirección abreviada https://aka.ms/configuration-dsc-schema/, donde se pueden consultar las versiones disponibles (por ejemplo 0.2).

La primera línea del archivo suele ser un comentario especial para que las herramientas como Visual Studio Code (con la extensión YAML de RedHat) sepan qué esquema usar. Un ejemplo típico sería algo como: # yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2, indicando la versión del esquema aplicada al archivo.

El nodo raíz del documento es properties, que contiene tanto la definición de la versión de configuración (configurationVersion) como las dos secciones principales del archivo: assertions (aserciones) y resources (recursos). Estas dos secciones son listas de tareas declarativas que WinGet y DSC evaluarán y aplicarán.

La versión de configuración, por ejemplo configurationVersion: 0.2.0, debe ir actualizándose cuando se hacen cambios relevantes en el contenido. Dentro de properties, las aserciones recogen los requisitos previos y los recursos describen todas las instalaciones y ajustes que se deben llevar a cabo en el sistema.

Cada elemento dentro de assertions o resources se define mediante un nodo resource que indica qué módulo de PowerShell se va a usar y qué recurso de DSC concreto se va a invocar para aplicar el estado deseado, siguiendo el formato {ModuleName}/{DscResource}. A esto se añaden campos como directives, settings, un identificador opcional id y posibles dependencias dependsOn.

Aserciones: comprobaciones previas y requisitos mínimos

La sección de aserciones (assertions) recoge las condiciones previas que deben cumplirse para que la configuración se considere válida. No son pasos de instalación, sino comprobaciones del entorno que se ejecutan antes de aplicar los recursos que dependen de ellas.

Un ejemplo clásico de aserción es la verificación de la versión mínima del sistema operativo. Por ejemplo, WinGet requiere como mínimo Windows 10 versión 1809, y muchas configuraciones modernas pueden exigir versiones más recientes de Windows 11. Definir una aserción de versión de sistema operativo evita intentar instalar herramientas que no van a funcionar.

Estas aserciones pueden ejecutarse en paralelo, sin orden secuencial estricto. Cada una de ellas devuelve si el sistema cumple o no la condición (true o false). Si una aserción falla, cualquier recurso que la declare como dependencia mediante dependsOn se omite automáticamente, y eso se considera un resultado correcto desde el punto de vista de la configuración (no se hacen cambios inconsistentes en el sistema).

En los registros de salida de una ejecución de winget configure es habitual ver mensajes del tipo: una aserción concreta (por ejemplo la versión del sistema operativo) no se ha encontrado o ha fallado, por lo que determinados recursos dependientes (como activar el modo desarrollador o instalar un paquete WinGet concreto) no se han ejecutado.

La gran ventaja es que, aunque fallen algunas aserciones, el resto del archivo se sigue procesando. WinGet continuará ejecutando todas las tareas posibles, llevando la máquina tan lejos como se pueda hacia el estado objetivo. Una vez finaliza la ejecución, el usuario debe revisar los errores y ajustar lo que sea necesario.

Recursos: instalaciones, configuraciones y scripts

La sección de recursos (resources) es donde se lista todo lo que queremos instalar y configurar en la máquina: paquetes de WinGet, ajustes de Windows, instalación de componentes concretos (por ejemplo cargas de trabajo de Visual Studio), ejecución de scripts de PowerShell, gestión de servicios, registros, etc.

Cada recurso tiene varios componentes clave: el campo resource con el módulo y el recurso DSC que se va a utilizar, la sección directives con metadatos y requisitos de ejecución, la sección settings con los parámetros que se pasan al recurso y, opcionalmente, un identificador único id y una lista de dependencias dependsOn.

Las directivas (directives) suelen incluir una description que explica la tarea que se lleva a cabo, el indicador allowPrerelease para decidir si se aceptan módulos de versión preliminar desde PowerShell Gallery y el securityContext, que marca si el recurso necesita ejecutarse con privilegios elevados (elevated) o puede funcionar con los permisos del usuario actual.

La sección settings define realmente el comportamiento

Por ejemplo, un recurso que habilite el modo desarrollador de Windows podría usar un recurso Microsoft.Windows.Settings/WindowsSettings con un settings donde se establezca DeveloperMode: true. Un recurso que instale Visual Studio 2022 Community podría usar Microsoft.WinGet.DSC/WinGetPackage con parámetros como id: Microsoft.VisualStudio.2022.Community y source: winget.

Las dependencias (dependsOn) permiten crear relaciones lógicas entre recursos y aserciones. Por ejemplo, un recurso que instale componentes adicionales de Visual Studio puede depender de que primero se haya instalado el propio Visual Studio (identificado por un id de recurso anterior), o de que una aserción de versión de sistema operativo haya sido satisfactoria.

Ejemplos prácticos de archivos YAML para WinGet

Veamos cómo se traduce todo esto en un archivo YAML sencillo. Imagina que quieres definir una configuración básica para comprobar la versión mínima de Windows, instalar Visual Studio Code, Google Chrome y ejecutar un pequeño script de PowerShell para preparar el entorno.

Un esquema simplificado podría incluir dentro de properties una sección de assertions con una comprobación de MinVersion del sistema operativo y una sección de resources con recursos de tipo paquete y de tipo script. Conceptualmente, algo como:

properties:
assertions:
- MinVersion: "10.0.19041.0"
resources:
- package: Microsoft.VisualStudioCode
version: "latest"
- package: Google.Chrome
version: "latest"
- script: |
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name PowerShellGet -Force -AllowClobber

En esta configuración conceptual se establece primero una condición mínima de versión de Windows y, si se cumple, se instalan los dos paquetes indicados (VS Code y Chrome) en su última versión disponible, y se lanza a continuación un script que ajusta la directiva de ejecución y añade el módulo PowerShellGet con los parámetros adecuados.

Aplicar el archivo en una máquina concreta es tan simple como ejecutar en PowerShell el comando winget configure --file ruta\a\tu\archivo.yaml. A partir de ahí, WinGet validará el documento contra el esquema, descargará los módulos DSC necesarios y empezará a evaluar aserciones y recursos.

En archivos más avanzados, como el ejemplo típico configuration.winget, se definen recursos para verificar la versión mínima del sistema operativo, habilitar Developer Mode, instalar Visual Studio 2022 Community como paquete WinGet e instalar componentes extra de Visual Studio a partir de un archivo .vsconfig, empleando propiedades como productId, channelId, vsConfigFile e incluso el parámetro includeRecommended para ampliar la instalación.

Buenas prácticas, organización y variable WinGetConfigRoot

La forma en que organizas la sección de recursos en el archivo influye mucho en su comprensión y mantenimiento. Aunque la ejecución no es secuencial y el orden no es crítico, conviene seguir un criterio coherente para que otros desarrolladores o administradores puedan entenderlo de un vistazo.

Algunos enfoques habituales de organización son ordenar por un supuesto orden lógico de ejecución (qué tiene más sentido que ocurra primero), agrupar por probabilidad de fallo (poner lo más “delicado” arriba para detectar errores cuanto antes) o agrupar por tipo de recurso (paquetes, configuraciones de sistema, scripts, servicios, etc.). Cualquiera puede valer siempre que se documente mínimamente.

Es muy recomendable acompañar la configuración con un archivo README en el repositorio, donde se explique la estrategia de organización, las dependencias clave, cómo ejecutar la configuración, qué requisitos previos de Windows o permisos necesita, y cualquier consideración de seguridad.

Un truco muy útil para rutas es usar la variable ${WinGetConfigRoot}, que representa el directorio de trabajo desde el que se ejecuta winget configure. En lugar de meter rutas absolutas, puedes construir rutas relativas basadas en esta variable, lo que hace que el archivo sea más portable entre distintos equipos.

Por ejemplo, un recurso de tipo Microsoft.VisualStudio.DSC/VSComponents puede usar ${WinGetConfigRoot} para localizar un fichero .vsconfig en el directorio raíz del proyecto, como en '${WinGetConfigRoot}\..\.vsconfig'. Eso implica, por supuesto, que el usuario debe asegurarse de que el archivo exista en esa ruta relativa antes de lanzar la configuración.

Creación, nombres de archivo y convenciones recomendadas

Para crear un archivo de configuración de WinGet desde cero conviene seguir una serie de pasos lógicos: decidir el nombre y ubicación del archivo, familiarizarse con el esquema y formato, definir aserciones y recursos, y determinar dependencias y parámetros.

Microsoft recomienda usar la extensión .winget para estos archivos de configuración, por ejemplo configuration.winget. En proyectos basados en Git, la convención sugerida es almacenarlos dentro de un directorio oculto .config, concretamente en ./.config/configuration.winget como configuración por defecto.

Si un proyecto necesita varias configuraciones (por ejemplo, diferentes toolchains, distintos perfiles de desarrollador o preferencias de usuario), se pueden añadir archivos adicionales en el mismo directorio .config, cada uno con su propio nombre descriptivo para reflejar su propósito.

El proceso típico de diseño de un archivo de configuración incluye identificar todas las aserciones necesarias (versiones de sistema, presencia de ciertas características, etc.), listar los recursos (software, paquetes, ajustes de sistema) que se quieren aplicar, localizar en PowerShell Gallery los módulos y recursos DSC adecuados y definir de forma explícita las directivas y dependencias de cada recurso.

Para comprobar la validez del archivo mientras se redacta, es muy útil usar Visual Studio Code con la extensión de YAML de RedHat y vincular el esquema JSON correspondiente. Esto habilita validación de estructura, autocompletado, sugerencias de campos y resaltado de errores de formato que podrían pasar desapercibidos a simple vista.

Seguridad, confianza y directivas de grupo con WinGet

Al tratarse de una herramienta capaz de instalar y configurar software en masa, la seguridad es un aspecto clave. WinGet se integra con Microsoft Store usando un origen denominado msstore y emplea técnicas de “anclaje de certificados” para garantizar que la conexión con la Store es legítima y no está siendo interceptada.

En entornos empresariales donde se emplean firewalls con inspección SSL, esta validación puede provocar errores si el tráfico es interceptado y reempaquetado. Para esos casos existe una directiva llamada BypassCertificatePinningForMicrosoftStore, que permite indicar si WinGet debe omitir esa validación de hash de certificado o mantenerla activa.

Las opciones de esta directiva son: dejarla sin configurar (comportamiento recomendado por defecto, respetando los valores estándar del Administrador de paquetes de Windows), habilitarla (WinGet no validará el certificado de Microsoft Store) o deshabilitarla (WinGet exigirá que el certificado coincida con uno conocido de Microsoft Store antes de aceptar la conexión).

Deshabilitar el anclaje de certificados incrementa el riesgo de ataques de tipo “man-in-the-middle” que interceptan comunicaciones para robar credenciales u otra información sensible. Por eso solo debería considerarse cuando no quede más remedio y se conozcan bien las implicaciones en la política de seguridad de la organización.

Además de esta directiva, WinGet ofrece una serie de plantillas de directiva de grupo (archivos .admx y .adml) que permiten a los departamentos de TI controlar aspectos como los orígenes permitidos o bloqueados, la habilitación de funciones experimentales, la política de desarrollo local, las opciones de proxy o el comportamiento de la interfaz de línea de comandos.

Estas plantillas se distribuyen dentro de un archivo DesktopAppInstallerPolicies.zip en las versiones de WinGet publicadas en GitHub. Una vez descargado, se extraen los ficheros y se copian a las rutas estándar de directivas en Windows (C:\Windows\PolicyDefinitions para los .admx y la subcarpeta de idioma, como en-US, para los .adml), y a partir de ahí ya se pueden gestionar desde la Consola de administración de directivas de grupo.

Repositorios, orígenes adicionales y catálogo de paquetes

De fábrica, WinGet tiene dos grandes fuentes: la Microsoft Store (msstore) y el repositorio comunitario de WinGet alojado en GitHub, que actúa como índice de paquetes y manifiestos. En este repositorio ya hay una larga lista de aplicaciones conocidas: navegadores como Chrome o Firefox, utilidades de compresión como 7Zip, herramientas de desarrollo como OpenJDK, Git o Visual Studio, aplicaciones de diseño como Blender o Inkscape y un largo etcétera.

Los proveedores de software independientes (ISV) pueden utilizar WinGet como canal de distribución, enviando manifiestos de sus paquetes al repositorio comunitario mediante pull requests. Estos manifiestos y los binarios a los que apuntan se someten a validación automática y, en muchos casos, a revisión manual para garantizar un mínimo de calidad y seguridad.

Al igual que sucede en GNU/Linux con los repositorios adicionales, WinGet permite añadir orígenes propios. Una organización puede mantener un repositorio privado con manifiestos específicos para sus aplicaciones internas, ya sea en Azure, en un servidor on-premise o en soluciones dedicadas como proyectos que proporcionan infraestructura para repositorios WinGet autoalojados mediante Docker.

Agregar un origen alternativo se hace abriendo PowerShell como administrador y ejecutando un comando de la forma winget source add --name <nombre_del_repositorio> --arg <URL_del_repositorio>. Opcionalmente se pueden usar parámetros adicionales como --type (por lo general fuentes REST), --trust-level (ninguno o de confianza) y --accept-source-agreements para aceptar automáticamente los acuerdos de licencia del origen.

Para comprobar que el origen se añadió correctamente, se puede usar winget source list, que mostrará todas las fuentes disponibles junto con su nombre y tipo. A partir de ese momento, las búsquedas e instalaciones podrán tener en cuenta el nuevo repositorio según cómo se haya configurado.

WinGet, DSC y dónde encontrar recursos adicionales

La unión de WinGet con DSC de PowerShell es lo que permite ir más allá de la mera instalación de aplicaciones y pasar a controlar realmente la configuración de la máquina. DSC cuenta con multitud de recursos listos para usar (llamados “inbox”) y otros muchos aportados por la comunidad que se publican en la PowerShell Gallery.

Entre los recursos de configuración de estado deseado habituales se encuentran módulos para gestionar variables de entorno, instalar o desinstalar paquetes MSI, manejar claves y valores del Registro, ejecutar scripts de PowerShell, administrar servicios de Windows, añadir o quitar roles y características del sistema y arrancar o detener procesos de Windows.

La PowerShell Gallery alberga cientos de módulos con recursos DSC adicionales, que se pueden localizar aplicando el filtro “Recurso DSC” en la categoría correspondiente. Es una fuente muy potente para ampliar las capacidades de tus archivos de configuración, pero también exige prudencia.

La advertencia importante es que la PowerShell Gallery, aunque es muy popular, no es un repositorio verificado por Microsoft. Contiene contribuciones de muchos autores y editores diferentes, y cualquier recurso puede incluir scripting arbitrario. Por lo tanto, siempre hay que revisar los módulos para evaluar su credibilidad y seguridad antes de integrarlos en una configuración que se vaya a desplegar en máquinas de producción.

Microsoft recomienda encarecidamente validar siempre la integridad y confiabilidad de cualquier archivo de configuración de WinGet: revisar su contenido a mano, entender qué módulos y scripts emplea, probarlo primero en entornos aislados o de laboratorio y apoyarse en las mejores prácticas descritas en la documentación oficial sobre cómo comprobar la confianza de un archivo de configuración.

WinGet, los archivos YAML de configuración y DSC de PowerShell forman un combo muy potente que permite pasar de configurar equipos a mano a describir entornos de forma declarativa, compartible y automatizable. Con un único comando puedes replicar una máquina de desarrollo, estandarizar el software en una empresa o simplemente ahorrarte el tostón de reinstalar siempre lo mismo cada vez que estrenas equipo.