Cada vez que formateas la máquina, abres ese README de treinta pasos y empiezas a copiar comandos uno por uno. En el paso 14 algo falla, improvisas, te olvidas de anotarlo y seis meses después el siguiente desarrollador —o tú mismo— vuelve a sufrirlo. La configuración manual no es productividad: es deuda técnica que pagas con tu tiempo.
La configuración manual es una fábrica silenciosa de bugs
El problema de seguir los pasos a mano no es que sea tedioso, sino la divergencia. Tú instalas la versión 20 de Node, tu compañero usa la 18 y el CI ejecuta la 22. Nadie se equivoca en el README: el README simplemente no describe lo que realmente está ejecutándose en cada máquina.
Cada ajuste manual es un estado que nadie versiona. «Ah, tuve que exportar una variable en el zshrc» se convierte en conocimiento tribal, desaparece cuando esa persona se va y reaparece como un bug de dos horas. La pregunta correcta no es «¿cómo instalo esto?», sino «¿cómo hago que la máquina se configure sola?».
Bootstrap idempotente: ejecútalo diez veces y el resultado será el mismo
La pieza central es un script de bootstrap —un setup.sh (o .ps1)— que lleva la máquina desde cero hasta un entorno listo. La regla de oro es la idempotencia: ejecutarlo una o diez veces debe producir exactamente el mismo resultado, sin duplicar líneas en los archivos ni fallar si la herramienta ya existe.
En la práctica, esto significa comprobar antes de actuar:
bash if ! command -v gh >/dev/null 2>&1; then brew install gh fi
Los gestores de paquetes ayudan porque ya son idempotentes: ejecutar brew install sobre un paquete existente no causa problemas. El enemigo es >>, que añade contenido a ciegas: ejecútalo dos veces y tu .zshrc tendrá la misma línea duplicada. Es preferible generar el archivo completo a partir de una plantilla que ir acumulando echo.
Deja que el gestor de paquetes haga el trabajo sucio
Descargar un .dmg, arrastrarlo a Aplicaciones y aceptar la licencia: nada de eso escala ni se automatiza bien. Un gestor de paquetes convierte la instalación en una lista declarativa: tú indicas qué quieres y él resuelve cómo hacerlo.
- macOS: Homebrew, con un
Brewfileque lista todo (brew bundle). - Linux: apt/dnf/pacman para el sistema, además de un gestor de versiones (asdf, mise) para los lenguajes.
- Windows: winget o Scoop, que por fin ofrecen un camino realmente scriptable.
La ventaja desaparece si sigues instalando «esos tres más» manualmente. Si forma parte del entorno, debe formar parte de la lista. El Brewfile (o su equivalente) se convierte en la fuente de verdad de lo que necesita tu máquina, y un diff en Git cuenta la historia de cada cambio.
Dotfiles en Git: tu configuración deja de vivir solo en tu cabeza
Tu .zshrc, .gitconfig, la configuración del editor y los aliases son código: trátalos como código. Un repositorio de dotfiles versiona tu configuración y te permite reproducirla en cualquier lugar con un git clone y un enlace simbólico.
No necesitas un framework: una carpeta en Git y un script que cree los enlaces simbólicos (ln -sf) ya resuelven el 90 % de los casos. La verdadera ventaja no es la copia de seguridad, sino el historial. Cuando un alias empieza a comportarse de forma extraña, git log te muestra qué cambió y cuándo. Y separa lo público de los secretos: los tokens y las claves privadas no deben entrar en el repositorio; usa un .env local, un gestor de secretos o variables del sistema.
Si no funciona en una máquina limpia, no existe
Aquí está la trampa: tu script «funciona» porque tu máquina ya tiene la mitad de las cosas instaladas. La única prueba de que el bootstrap funciona es ejecutarlo en un entorno limpio, donde no se dé nada por supuesto.
Tienes opciones económicas: un contenedor Docker (docker run -it ubuntu bash), una máquina virtual desechable o —la opción más honesta— un job de CI que arranque desde cero y ejecute tu setup.sh en cada push. Si GitHub Actions puede instalar tu entorno en una imagen virgen, cualquier nuevo compañero también podrá hacerlo. Es el mismo principio que en una prueba automatizada: sin ejecutarlo en un entorno controlado, solo tienes esperanza.
Empieza poco a poco, hoy
No detengas todo para construir la automatización perfecta. La próxima vez que resuelvas algo manualmente, dedica dos minutos más y añade el comando a un setup.sh. La semana siguiente, mueve tu .zshrc a un repositorio. Después, ejecuta el script en un contenedor y observa qué falla.
En poco tiempo cambiarás el README de treinta pasos por un solo comando, y la máquina nueva estará lista para producir antes de que termines el café.