Windows Developer Config: convierte un Windows 11 limpio en un entorno reproducible

Configurar una PC para desarrollar suele empezar con una lista que nadie quiere volver a ejecutar: instalar Git, PowerShell, Python, Node, .NET, VS Code, WSL, una terminal decente, fuentes, utilidades, cambiar opciones de Windows y, finalmente, recordar qué detalle faltó.

Microsoft está intentando convertir ese proceso en algo mucho más cercano a infraestructura como código para el workstation.

El proyecto open source WindowsDeveloperConfig promete llevar una instalación limpia de Windows 11 a una estación de desarrollo configurada de forma repetible. La idea importante no es simplemente “instalar muchas aplicaciones con un comando”. Es poder describir o automatizar el estado de una máquina, volver a aplicar el setup y reparar el drift sin reconstruir todo manualmente.

Y aquí hay un matiz importante: el repositorio no es una sola “app” ni todo funciona exactamente de la misma manera.

Tres caminos dentro del mismo proyecto

Actualmente el repositorio de Microsoft agrupa tres experiencias:

Windows Dev Config: prepara una estación Windows 11 completa, incluyendo herramientas, configuración del sistema, terminal y WSL.
WSL Comfort: configura una experiencia de shell más pulida dentro de WSL.
Workloads: instala toolchains específicos como Node, Python, SQL, PowerShell, .NET, Rust, Go, Java, PHP, WinForms o WinUI 3.

La diferencia técnica es interesante.

La configuración completa de Windows Dev Config es PowerShell nativo. Microsoft explica que ese flujo necesita resolver cosas que no encajan bien en un único archivo declarativo: elevación, un reinicio obligatorio, continuación automática después del reboot y una experiencia interactiva de progreso.

En cambio, la mayoría de los workloads individuales sí se apoyan en WinGet Configuration y PowerShell DSC para describir el estado deseado.

Esa combinación ofrece dos modelos complementarios:

Windows completo
    |
    +--> PowerShell idempotente
         + elevación
         + reboot
         + reanudación
         + configuración del sistema

Workload específico
    |
    +--> WinGet Configuration
         + DSC
         + YAML declarativo
         + estado deseado

El bootstrap completo

Desde PowerShell 5.1 o PowerShell 7, descarga el wrapper firmado de producción y comprueba su firma Authenticode y el editor Microsoft antes de ejecutarlo:

$ErrorActionPreference = 'Stop'
$url = 'https://raw.githubusercontent.com/microsoft/WindowsDeveloperConfig/main/windows-dev-config/setup-full.ps1'
$script = Join-Path $env:TEMP ("devconfig-" + [guid]::NewGuid() + ".ps1")
try {
    Invoke-WebRequest -UseBasicParsing -Uri $url -OutFile $script
    $signature = Get-AuthenticodeSignature -FilePath $script
    if ($signature.Status -ne 'Valid' -or
        $signature.SignerCertificate.Subject -notmatch '(^|,\s*)O=Microsoft Corporation(,|$)') {
        throw 'Invalid signature or unexpected publisher; stopping.'
    }
    powershell.exe -NoProfile -ExecutionPolicy AllSigned -File $script
    if ($LASTEXITCODE -ne 0) { throw 'Setup did not complete successfully.' }
} finally {
    Remove-Item -LiteralPath $script -ErrorAction SilentlyContinue
}

El proceso hijo de PowerShell usa AllSigned para que la política Restricted predeterminada de una instalación limpia no bloquee el script verificado. El ajuste se limita a ese proceso y no prevalece sobre las directivas de grupo de la organización. Puede aparecer una confirmación de confianza del editor; comprueba que sea Microsoft. Si una directiva sigue impidiendo la ejecución, consulta al administrador en lugar de modificar esas reglas.

El bootstrap solicita elevación cuando la necesita, descarga el repositorio, verifica los scripts firmados para el flujo de producción y deja los archivos de trabajo en un directorio protegido bajo %ProgramData%.

En una máquina limpia, Microsoft estima aproximadamente 30 minutos con una buena conexión.

El proceso instala y configura, entre otras cosas:

Windows Terminal
PowerShell 7
Git
GitHub CLI
GitHub Copilot CLI
Visual Studio Code
.NET SDK 10
Python 3.14 y uv
Node.js LTS y nvm
Coreutils for Windows
Windows App CLI
Oh My Posh
PowerToys
WSL + Ubuntu

También aplica cambios al sistema: Developer Mode, soporte para rutas largas, ajustes de Explorer, Terminal, Start/Search, widgets y otras preferencias.

El reinicio deja de ser un caso especial

WSL requiere habilitar componentes de Windows que obligan a reiniciar.

Un instalador tradicional podría detenerse ahí y dejar el resto del trabajo al usuario. Windows Dev Config trata el reboot como parte del flujo.

El setup ejecuta sus fases iniciales, instala WSL, avisa antes de reiniciar y crea el mecanismo necesario para continuar después de iniciar sesión nuevamente. Tras el reboot aparece un segundo consentimiento UAC y el proceso termina lo que falta.

Esto importa más de lo que parece. Para que un bootstrap sea realmente reproducible no basta con tener un script enorme; tiene que poder sobrevivir a interrupciones inevitables del sistema.

Idempotencia: ejecutarlo dos veces no debería duplicar el mundo

Otra propiedad central es la idempotencia.

El proyecto comprueba el estado antes de aplicar cada cambio. Si una parte ya está configurada, volver a ejecutar el setup no debería repetirla innecesariamente. Si una fase quedó incompleta o fue marcada como problemática, una segunda ejecución puede concentrarse en reparar lo pendiente.

Conceptualmente:

estado actual
     +
configuración esperada
     |
     v
comparar
     |
     +--> ya está correcto -> no hacer nada
     |
     +--> existe drift -> corregir

Esta forma de pensar acerca el workstation al mismo modelo mental que usamos para servidores, pipelines o clusters.

WinGet Configuration: el lado declarativo

Para workloads más acotados, Microsoft usa WinGet Configuration, que a su vez aprovecha recursos de PowerShell DSC.

En lugar de escribir una secuencia imperativa como:

descarga Git
instala Git
descarga PowerShell
instala PowerShell
cambia esta opción
ejecuta este script

el archivo declara qué estado debe existir.

El siguiente ejemplo requiere WinGet 1.11 o posterior y el procesador dscv3. Comprueba la versión con winget --version; WinGet instala el procesador automáticamente cuando hace falta. Es una configuración de actualización continua: useLatest: true sigue deliberadamente las versiones disponibles, así que no garantiza versiones idénticas con el paso del tiempo. Para fijar versiones concretas, usa valores version: revisados y mantenlos explícitamente.

Un ejemplo mínimo con el esquema v3 puede verse así:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json

metadata:
  winget:
    processor:
      identifier: dscv3

resources:
  - type: Microsoft.WinGet/Package
    name: Git
    properties:
      id: Git.Git
      source: winget
      useLatest: true

  - type: Microsoft.WinGet/Package
    name: PowerShell
    properties:
      id: Microsoft.PowerShell
      source: winget
      useLatest: true

La idea es que el archivo describa qué debe existir, no una receta frágil de pasos.

Después se puede validar:

winget configure validate -f .config/configuration.winget

comprobar si la máquina cumple el estado deseado:

winget configure test -f .config/configuration.winget

y aplicarlo:

winget configure -f .config/configuration.winget

Esto abre una posibilidad interesante: guardar la definición del entorno junto al código.

repo/
├── .config/
│   └── configuration.winget
├── src/
├── tests/
└── README.md

Una nueva máquina deja de depender de una wiki desactualizada o de la memoria del desarrollador.

De “setup documentado” a “setup ejecutable”

Durante años muchos equipos han mantenido documentos similares a este:

1. instala Git
2. instala Python
3. marca esta opción
4. configura WSL
5. instala Node
6. añade estas variables
7. reinicia
8. ejecuta este script

El problema es que una guía es una descripción humana del proceso. No garantiza que dos personas terminen con el mismo resultado.

Una configuración ejecutable puede convertirse en un contrato verificable.

Podemos pensar en tres niveles:

Nivel	Qué conserva	Problema
README	instrucciones	depende del humano
script imperativo	pasos	puede acumular estados inesperados
configuración idempotente	estado deseado	permite verificar y reparar drift

Windows Developer Config no elimina todos los problemas del bootstrap, pero representa claramente el movimiento hacia el tercer nivel.

También es interesante para runners y agentes

Este enfoque no sirve solamente para laptops de desarrolladores.

Una máquina Windows utilizada como runner de CI, worker o host para agentes también suele acumular dependencias invisibles:

una versión concreta de Python;
Git y GitHub CLI;
PowerShell;
runtime de .NET;
herramientas auxiliares;
variables;
opciones de Windows;
WSL;
políticas y servicios.

Mientras esa configuración solo existe en la máquina, el host es difícil de reconstruir.

Cuando el estado está versionado:

Git
 |
 +--> configuración del host
       |
       +--> máquina A
       +--> máquina B
       +--> runner efímero
       +--> entorno de recuperación

la máquina deja de ser una mascota que hay que cuidar manualmente y empieza a parecerse a un recurso reemplazable.

Para agentes autónomos esto tiene otra ventaja: el agente puede verificar precondiciones antes de trabajar. En vez de asumir que “seguramente Git está instalado”, puede comprobar declarativamente si el entorno cumple el contrato.

La seguridad sigue siendo parte del diseño

Hay una advertencia que no debe perderse entre la comodidad del “one-liner”.

Microsoft recomienda revisar cualquier WinGet Configuration antes de ejecutarla, especialmente porque una configuración puede instalar paquetes, cargar recursos DSC y efectuar cambios con privilegios elevados.

El bootstrap completo también trata explícitamente la cadena de confianza. En el camino de producción verifica firmas Authenticode de Microsoft y utiliza ubicaciones protegidas para los scripts que continuarán después del reinicio. El switch -AllowUnsigned existe para desarrollo del propio proyecto y omite esas comprobaciones, por lo que no debe confundirse con el camino normal.

La automatización reduce pasos manuales; no elimina la necesidad de revisar qué código recibirá privilegios administrativos.

El patrón que realmente vale la pena copiar

Lo más valioso de Windows Developer Config no es su lista concreta de programas. Esa lista cambiará.

El patrón reutilizable es este:

definir
  ↓
versionar
  ↓
validar
  ↓
aplicar
  ↓
comprobar
  ↓
reaplicar cuando exista drift

Ese ciclo es exactamente lo que hizo valiosa a la infraestructura como código en servidores.

Ahora está llegando de forma más explícita al escritorio del desarrollador.

Una organización podría mantener, por ejemplo:

windows-base/
python-worker/
dotnet-developer/
frontend-developer/
ci-runner/
agent-host/

Cada perfil contendría solo las herramientas y políticas que realmente necesita.

El resultado no es simplemente una instalación más rápida. Es algo mucho más importante: una máquina cuya configuración puede revisarse, reproducirse y reconstruirse.