Configurar des de zero un nou PC amb Windows cada vegada que canvies d'equip o t'incorpores a un projecte nou pot ser un autèntic suplici: descarregar instal·ladors, següent-següent, acceptar llicències, reinicis, ajustaments del sistema… i repetir el mateix a cada màquina. Amb WinGet i arxius YAML pots transformar tot aquest ritual manual en una única ordre que deixa l'entorn llest per treballar de manera fiable, repetible i automatitzada.
La idea és molt simple però tremendament potent: defineixes en un fitxer de configuració quines aplicacions vols, quina versió de Windows necessites, quins ajustaments s'han d'aplicar i quins scripts s'han d'executar. Després deixeu que Windows Package Manager (winget) , recolzat en PowerShell Desired State Configuration (DSC), s'encarregueu d'instal·lar, configurar i verificar que el vostre equip queda exactament en l'estat desitjat, com si fos una recepta de cuina però per al teu entorn de treball.
Què és WinGet i per què és clau per automatitzar instal·lacions
WinGet (Windows Package Manager) és el gestor de paquets oficial de Microsoft per a Windows 10 i Windows 11. Funciona des de la línia d'ordres i et permet instal·lar, actualitzar, configurar i desinstal·lar aplicacions de manera similar al que es fa a GNU/Linux amb gestors com apt o dnf, però integrat a l'ecosistema de Windows.
En lloc de caminar buscant instal·ladors per la web, descarregar EXE o MSI i executar-los un a un, amb WinGet només cal llançar una ordre com a winget install perquè el sistema descarregui el paquet des dels seus orígens autoritzats i completi la instal·lació sense que hagis de fer clic en res. Això redueix errors humans, estalvia temps i obre la porta a lautomatització massiva dequips.
Les fonts principals de programari que utilitza WinGet són Microsoft Store i el repositori de la comunitat . A més, pots afegir repositoris addicionals, per exemple un privat de la teva organització, cosa que permet controlar quins paquets es distribueixen internament sense dependre només del catàleg públic.
La solució de WinGet no es limita a l'eina de consola. L'ecosistema complet inclou la CLI winget , els serveis per enviar i allotjar paquets (manifests) i el mecanisme d' arxius de configuració declaratius a YAML que són els protagonistes quan parlem d'automatitzar instal·lacions i configuració de Windows.
Ordres bàsiques de WinGet per gestionar aplicacions
Abans de ficar-nos de ple als arxius YAML , convé tenir clares les ordres essencials de WinGet per al dia a dia. Tot es fa des de Terminal de Windows, PowerShell o el clàssic Símbol del sistema.
Per veure l'ajuda general i comprovar que winget està disponible, només cal escriure winget en un terminal. Veureu la versió, les ordres principals i les opcions disponibles.
Instal·lar una aplicació és tan senzill com executar:
Exemple d'instal·lació: winget install Microsoft.VisualStudioCode
En aquest exemple, Microsoft.VisualStudioCode és l'ID del paquet Visual Studio Code al repositori de WinGet. Si el paquet està disponible a la Store, també es pot instal·lar usant el seu nom, usant cometes quan inclogui espais.
Per actualitzar totes les aplicacions que WinGet reconeix al sistema es fa servir:
Ordre d'actualització: winget upgrade --all
Si només vols actualitzar un programa concret, n'hi hauria prou amb:
Actualitzar paquet específic: winget upgrade Microsoft.VisualStudioCode
Inicialment WinGet només actualitzava aplicacions instal·lades amb ell, però en versions recents detecta més programari instal·lat i pot actualitzar-lo sempre que hi hagi un manifest vàlid als seus orígens.
En cas que necessitis desinstal·lar un programa , l'ordre és:
Ordre de desinstal·lació: winget uninstall Microsoft.VisualStudioCode
La desinstal·lació funciona tant amb paquets instal·lats per WinGet com amb aquells que el propi sistema reconeix i té mapejats al catàleg de WinGet, encara que no tots els escenaris estan suportats.
Per localitzar programari disponible, podeu utilitzar winget search . Per exemple, per cercar paquets relacionats amb “notepad”:
Cerca de paquets: winget search notepad
ID del paquet: Aquesta ordre retorna una llista de coincidències mostrant el nom, l'ID del paquet i l'origen (Store, repositori comunitari, repositori privat, etc.). Aquest ID serà el que utilitzes posteriorment a les ordres d'instal·lació o actualització per assegurar que instal·les exactament el paquet desitjat.
Finalment, si el que necessites és veure quines aplicacions reconeix WinGet instal·lades al sistema, pots utilitzar:
Llistat d'aplicacions: winget list
Automatitzar instal·lacions massives amb arxius YAML
La veritable màgia de WinGet apareix quan deixes de llançar ordres un per un i passes a descriure tot un entorn de treball en un únic fitxer de configuració. En lloc de tenir un llistat de comandes soltes en un bloc de notes o un script improvisat, defineixes el teu “estat ideal” en format YAML i l'apliques amb una sola ordre.
Aquests fitxers de configuració de WinGet (sovint anomenats configuration.winget o similars) segueixen una estructura declarativa: no escrius una seqüència de passos imperatius, sinó que indiques com vols que quedi la màquina . WinGet, recolzant-se en PowerShell Desired State Configuration (DSC) , s'encarrega d'instal·lar paquets, activar característiques de Windows, canviar valors de registre, executar scripts i, en general, deixar l'equip d'acord amb allò descrit.
Per poder utilitzar aquest tipus de configuracions, necessiteu la versió WinGet 1.6.2631 o posterior , ja que és a partir d'aquí quan s'introdueix el suport per a la integració amb DSC 3.0 i la funcionalitat de winget configure.
El gran avantatge és que tot el procés es pot llançar de forma desatesa : executes l'ordre corresponent, acceptes els acords de configuració necessaris i deixes que l'equip treballi. Mentrestant pots anar a buscar un cafè mentre Windows instal·la totes les teves eines, habilita el mode desenvolupador, configura polítiques i aplica scripts.
A més, aquests fitxers de configuració es poden versionar i compartir fàcilment en un dipòsit GitHub, GitLab, OneDrive o un altre mitjà segur. Això converteix la preparació de lentorn de desenvolupament en un veritable cas dInfrastructure as Code (IaC) aplicat a lescriptori de Windows.
Com funciona winget configure i la integració amb DSC
La comanda winget configure és el punt d'entrada a tota la part declarativa. És l'encarregat de llegir el fitxer YAML, validar-ne l'estructura, descarregar els mòduls de PowerShell necessaris, executar els recursos de DSC i comprovar si el sistema entra a l'estat desitjat.
Habilitar DSC: Abans d'aplicar una configuració, podeu habilitar explícitament el suport DSC a WinGet amb:
winget configure --enable
A continuació, és molt recomanable validar el fitxer YAML per assegurar-te que la sintaxi és correcta i coincideix amb l'esquema oficial:
Validació del YAML: winget configure validate ruta\a\tu_configuracion.yaml
Tingues en compte que YAML és molt sensible a la indentació i utilitza espais (no tabuladors) per definir blocs imbricats. Un espai de més o menys pot trencar la configuració, per això és important utilitzar un editor com a Visual Studio Code amb l'extensió de YAML de Red Hat i l' esquema JSON de WinGet vinculat.
Aplicar la configuració: winget configure --file ruta\tu_configuracion.yaml --accept-configuration-agreements
En aquest moment entra en acció el procés ConfigurationRemotingServer.exe , que interpreta el YAML, descarrega els mòduls de DSC des de PowerShell Gallery quan cal i comença a avaluar assercions i recursos. Algunes tasques s'executen en paral·lel, d'altres requereixen privilegis elevats (UAC) i d'altres depenen que es compleixin certes condicions prèvies.
Prova en sec: winget configure test -f ruta\tu_configuracion.yaml --accept-configuration-agreements
En aquesta modalitat, WinGet revisa el sistema, el compara amb l'estat descrit i us indica si la màquina està o no en la configuració esperada. Quan alguna cosa no quadri, veureu missatges del tipus “System is not in the described configuration state.” per a aquells elements que difereixen.
En tornar a aplicar el YAML, WinGet només implementa els canvis necessaris per corregir les diferències, cosa que garanteix idempotència : pots executar la mateixa configuració tantes vegades com vulguis sense por de “trencar” res per duplicar accions.
Remot: winget configure --accept-configuration-agreements --disable-interactivity -f https://ruta/a/tu/archivo.yaml
Configuració centralitzada permet que els equips d'IT o els administradors publiquin una configuració centralitzada i que els clients només hagin d'executar una ordre per aplicar-la, cosa molt útil en desplegaments massius o equips remots.
Estructura i seccions d'un fitxer de configuració WinGet
Els fitxers de configuració de WinGet usen sintaxi YAML, però a més referencien un esquema JSON públic que defineix quina és l'estructura vàlida. Això facilita la validació automàtica i l'autocompleta en editors compatibles.
La convenció de noms per a aquests fitxers recomana utilitzar l'extensió .winget, Per exemple configuration.winget. En projectes amb control de versions (Git, per exemple) és bona pràctica col·locar-los sota un directori .config, de manera que la ruta sigui alguna cosa com ./.config/configuration.winget. Si necessiteu més d'un fitxer per a diverses variants d'entorn, podeu conviure tots en aquesta mateixa carpeta.
La primera línia del fitxer sol ser un comentari especial que indica l' esquema :
Capçalera de l'esquema: # yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
En aquesta URL trobareu la versió més recent de l'esquema suportat. Convé revisar de tant en tant les actualitzacions, perquè Microsoft pot publicar noves versions amb capacitats addicionals.
Sota aquest comentari, el node arrel és properties . Dins d'ell es declara una configurationVersion (per exemple, 0.2.0) que hauríeu d'anar actualitzant a mesura que canvieu el fitxer, i apareixen les dues seccions clau: assertions i resources.
La secció assertions recull les condicions prèvies o requisits que cal complir per considerar que la configuració aplica al sistema actual. La secció resources llista tot el programari, ajustaments, scripts i elements de sistema que vols instal·lar o configurar.
Assercions: comprovacions prèvies i dependències
Les assercions són com les proves de salut del sistema abans d'aplicar canvis. Cada asserció és un recurs DSC que verifica una condició; per exemple, que la màquina està executant una versió mínima de Windows compatible amb la configuració.
Un cas clàssic és l'asserció de versió de sistema operatiu. Pots especificar que la configuració requereix, per exemple, Windows 10 19041 o superior, o bé una versió concreta de Windows 11. Si la màquina no compleix, l'asserció torna false i qualsevol recurs que en depengui a través de dependsOn no s'executarà.
Avaluació paral·lela: Les assercions no tenen un ordre seqüencial obligatori : WinGet les pot avaluar en paral·lel. Això simplifica força els fitxers llargs, ja que no t'has de preocupar de en quina posició introdueixes una nova asserció mentre declaris bé les dependències.
Si una asserció falla, el normal és que la configuració segueixi intentant executar altres tasques que no en depenguin, portant la màquina tant lluny com pugui a l'adreça desitjada. Al final del procés, hauràs de revisar la sortida de l'execució per veure què ha anat bé i què no.
Exemple d'error: Assert::OsVersion The configuration unit could not be found. Apply::DeveloperMode This configuration unit was not run because an assert failed or was false. Apply::WinGetPackage [vsPackage] This configuration unit was not run because an assert failed or was false.
En aquest escenari, la verificació de versió del sistema operatiu no es compleix, així que recursos com l'activació del mode desenvolupador o la instal·lació de determinats paquets queden sense executar perquè depenen explícitament d'aquesta asserció.
Recursos: paquets, paràmetres de Windows i scripts
La secció resources és on declares tot el que vols que WinGet i DSC facin a la màquina: instal·lar aplicacions, configurar el sistema, llançar scripts de PowerShell, gestionar serveis, tocar el registre, habilitar rols de Windows, etc.
Cada entrada de la llista de recursos indica un recurs en format {NombreModulo}/{NombreRecursoDSC}, Per exemple Microsoft.Windows.Settings/WindowsSettings o Microsoft.WinGet.DSC/WinGetPackage. WinGet s'encarregarà d'instal·lar el mòdul des de Galeria PowerShell si no el teniu ja disponible i d'executar aquest recurs de DSC.
A més del tipus de recurs, podeu definir un id únic, molt útil quan un altre recurs necessita declarar-ho al camp dependsOn. D'aquesta manera construeixes cadenes de dependències clares: primer instal·lo Visual Studio, després aplico una configuració de workloads, etc.
Cada recurs inclou un bloc directives amb metadades com la descripció de la tasca, si es permet utilitzar versions preliminars del mòdul (allowPrerelease) I el SecurityContext. Si aquest últim s'estableix a elevated, WinGet sol·licitarà elevació de privilegis a l'inici de la configuració i executarà aquest recurs amb permisos d'administrador.
El bloc settings conté els paràmetres concrets que es passen al recurs DSC: per exemple, l'ID del paquet a instal·lar, l'origen (winget, msstore, dipòsit privat), la ruta a un fitxer .vsconfig, un valor de registre a establir o una bandera per habilitar el mode desenvolupador del Windows.
Mitjançant el camp dependsOn s'indiquen les dependències respecte a altres assercions o recursos. Si un d'aquests elements falla, el recurs dependent es marcarà automàticament com a fallit i no s'executarà. Això us permet construir configuracions complexes sense necessitat d'ordenar manualment cada pas.
Exemple pràctic de fitxer YAML i ús de ${WinGetConfigRoot}
Un fitxer de configuració típic pot incloure des de la comprovació de la versió de Windows fins a la instal·lació d'entorns de desenvolupament complets i execució de scripts personalitzats. Tot i que la sintaxi detallada pot variar, l'estructura general segueix el patró que hem comentat.
Un exemple senzill d'ús de recursos seria una cosa així (simplificada): primer es comprova una versió mínima del sistema operatiu, després s'instal·len paquets com ara Visual Studio Code o Google Chrome i, finalment, s'executa un script de PowerShell per ajustar la configuració o instal·lar mòduls addicionals.
En els entorns de desenvolupament és molt útil la combinació de recursos com Microsoft.VisualStudio.DSC/VSComponents juntament amb un fitxer .vsconfig. Podeu indicar al YAML que, un cop instal·lat Visual Studio, es llegeixin des d'aquest fitxer les workloads, components opcionals i recomanacions que voleu afegir a l'IDE.
Per evitar codificar rutes absolutes, WinGet ofereix la variable ${WinGetConfigRoot}, que representa el directori des del que executes winget configure. A partir d'aquí pots construir rutes relatives, per exemple per apuntar a un fitxer de configuració dins del propi repositori del teu projecte, sense dependre de la unitat o carpeta on estigui clonat.
La lògica seria com: a la configuració s'especifica que VS Components llegeixi el seu fitxer de configuració des de '${WinGetConfigRoot}\..\.vsconfig', el que implica que l'usuari ha d'haver col·locat prèviament aquest fitxer a la ruta relativa adequada respecte a la seva carpeta de treball.
A més de paquets i components de Visual Studio, pots definir recursos que gestionin serveis de Windows, variables d'entorn, claus de registre (per exemple, per activar la còpia de seguretat periòdica del registre mitjançant EnablePeriodicBackup) o fins i tot processos concrets que s'han d'iniciar o aturar com a part de la configuració.
Organització lògica del fitxer de configuració
En projectes grans , els fitxers de configuració poden créixer força, així que val la pena pensar com organitzar-los perquè segueixin sent llegibles i fàcils de mantenir, tant per a tu com per a la resta de l'equip.
Una forma d'organitzar-los és per ordre lògic d'execució : primer assercions i comprovacions bàsiques, després instal·lació d'eines base, més tard configuració d'IDEs i finalment ajustaments de sistema i scripts opcionals. Tot i que el motor no depèn de l'ordre físic, els humans ens ajuda veure la seqüència de manera clara.
Un altre enfocament és agrupar els recursos per nivell de risc o probabilitat d'error . Aquells passos que solen fallar (per exemple, instal·lacions que depenen molt de la xarxa o de credencials específiques) poden situar-se al principi per detectar problemes aviat, abans que l'usuari perdi temps esperant la resta del procés.
També és molt comú agrupar per tipus de recurs : paquets WinGet, ajustaments de Windows, scripts, rols i característiques del sistema, configuracions d'IDE, etc. Aquest patró s'assembla a com s'estructuren molts projectes de programari i sol resultar força natural per als equips de desenvolupament.
Sigui quin sigui el criteri, és bona idea acompanyar l'arxiu amb un README al repositori de codi obert o intern, explicant l'estructura, les decisions de disseny i com s'espera que es faci servir la configuració (per exemple, quins paràmetres cal ajustar abans d'executar-la).
Aquesta documentació addicional facilita les contribucions d'altres desenvolupadors i redueix el risc que algú trenqui la configuració en intentar afegir un recurs nou sense tenir clares les dependències existents.
On trobar mòduls DSC i exemples de configuració
Perquè els recursos funcionin , WinGet i DSC necessiten mòduls de PowerShell que implementin la lògica corresponent. Microsoft ofereix una sèrie de recursos de safata d'entrada per a tasques habituals com gestionar el registre, instal·lar MSI, arrencar serveis o modificar variables d'entorn.
Entre aquests recursos estàndard trobem, per exemple: Environment (gestiona variables d'entorn), msiPackage (instal·la o desinstal·la MSI), Registry (claus i valors del registre), Script (executa blocs de PowerShell), Service (control de serveis de Windows), WindowsFeature (rols i característiques), i WindowsProcess (iniciar o aturar processos).
Més enllà dels mòduls de Microsoft, a la PowerShell Gallery hi ha centenars de mòduls DSC aportats per la comunitat. Podeu aplicar el filtre “Recurs DSC” a la categoria de cerca per centrar-vos en els que contenen recursos de configuració d'estat desitjat.
Precaució amb la Galeria: La PowerShell Gallery no està auditada per Microsoft , així que és crucial revisar la procedència, el codi i la seguretat de qualsevol mòdul abans de confiar-hi. Qualsevol script pot incloure accions perilloses si no es revisa amb cura, especialment quan sexecuta amb privilegis elevats.
Microsoft manté a més un repositori amb arxius de configuració WinGet d'exemple , accessible a través de l'enllaç curt https://aka.ms/dsc.yaml , on podeu veure configuracions de referència per a diferents escenaris. També hi ha documentació específica sobre com comprovar la fiabilitat d'una configuració abans d'executar-la i de bones pràctiques generals de seguretat.
D'altra banda, a la comunitat comencen a sorgir repositoris col·laboratius que recopilen patrons d'instal·lació silenciosa i ordres confirmades per a programari complex (AutoDesk, solucions de VPN, clients de Citrix, etc.), cosa que pot servir d'inspiració quan hagis de bregar amb paquets especialment “pesats”.
Fonts de paquets, repositoris privats i control empresarial
Per defecte, WinGet obté els paquets de l'origen comunitari i de Microsoft Store, però les organitzacions poden anar molt més enllà. És possible afegir repositoris REST addicionals, per exemple un catàleg privat allotjat a Azure o una solució com WinGetty desplegada on-premise amb Docker.
Per afegir un nou origen, només cal obrir PowerShell com a administrador i executar:
Afegir origen: winget source add --name <nombre_repo> --arg <URL_repo>
Pots complementar aquesta ordre amb opcions com –type (tipus de font, normalment REST), –trust-level (none o trusted) i –accept-source-agreements per acceptar acords de llicència sense interacció manual, cosa molt habitual en scripts automatitzats.
Per verificar els orígens configurats a la màquina, utilitza:
Llistar orígens: winget source list
En l'àmbit empresarial, WinGet juga un paper important no només en la instal·lació de programari, sinó també en la seguretat i el compliment . S'integra amb Microsoft Intune i amb la infraestructura de directives de grup, permetent controlar quins orígens estan permesos, com es maneja el servidor intermediari, si s'accepten certificats específics, etc.
Per exemple, hi ha una directiva anomenada BypassCertificatePinningForMicrosoftStore que controla si WinGet verifica que el certificat de Microsoft Store coincideix amb un dels certificats coneguts abans destablir la connexió. Deshabilitar aquest ancoratge pot ser necessari en alguns entorns amb inspecció SSL, però també obre la porta a atacs de tipus man-in-the-middle , per la qual cosa només s'ha de fer amb ple coneixement dels riscos.
A més, hi ha directives específiques per bloquejar l'ús de fitxers de configuració WinGet en una organització (per exemple, els objectes de directiva de grup EnableWindowsPackageManagerConfiguration i la seva explicació associada) o per definir quins orígens es permeten, quines funcionalitats experimentals es poden activar i com es gestionen les instal·lacions locals de manifest.
Les plantilles de directiva de grup (.admx i .adml) específiques per a WinGet s'inclouen a partir del Windows 11 i també es poden descarregar des del repositori de GitHub del projecte, dins del paquet DesktopAppInstallerPolicies.zip. Copiant aquests fitxers a C:\Windows\PolicyDefinitions i la subcarpeta d'idioma corresponent, podreu configurar polítiques avançades des de la consola d'administració de directives de grup.
WinGet, els fitxers YAML i DSC converteixen la configuració d'equips Windows en un procés declaratiu, repetible i controlable, tant per a desenvolupadors individuals com per a grans organitzacions. Amb un sol fitxer versionat a Git i un parell d'ordres, pots aixecar en minuts un entorn de treball que abans requeria hores d'instal·lacions manuals, i fer-ho a més de manera segura, traçable i coherent a tots els teus dispositius.