Cambias de notebook, formateas la máquina o entras en un equipo nuevo. Y ahí se van dos días reinstalando cosas, buscando aquel alias que juraste que nunca olvidarías y descubriendo, en el peor momento, que el proyecto funciona con Node 18 y tú instalaste la versión 22. La reproducibilidad no es un lujo para quien tiene TOC. Es lo que separa a un desarrollador que vuelve a producir en minutos de otro que tarda días.
El problema no es la máquina, sino la memoria
El entorno de desarrollo es conocimiento que vive en tu cabeza y se evapora. Cada export, cada brew install, cada ajuste en .bashrc es una decisión que no recordarás dentro de seis meses. El objetivo es simple: transformar ese conocimiento tácito en archivos versionados. Si está en un repositorio, sobrevive al formateo.
Dotfiles: tu entorno en un repositorio
Tus archivos de configuración —.zshrc, .gitconfig, .vimrc, aliases— son los dotfiles. Colócalos en un repositorio Git y tendrás todo tu shell versionado. La técnica más limpia consiste en usar un bare repo que apunte a tu home, pero para empezar basta con una carpeta ~/dotfiles y un script que cree los symlinks:
bash ln -sf ~/dotfiles/zshrc ~/.zshrc ln -sf ~/dotfiles/gitconfig ~/.gitconfig
¿Máquina nueva? Ejecutas git clone, corres el script y tu terminal vuelve a ser la de siempre. Herramientas como chezmoi y stow automatizan este proceso y también gestionan las diferencias entre máquinas —por ejemplo, la del trabajo y la personal—. Solo no caigas en la tentación de versionar secretos junto con ellos; llegaremos a eso.
Gestores de versiones: deja de pelearte con las versiones
Instalar Node, Python o Ruby directamente en el sistema es buscar problemas. Cada proyecto necesita una versión diferente y el sudo global se convierte en un campo minado. Los gestores de versiones resuelven esto: nvm para Node, pyenv para Python y rbenv para Ruby.
Mejor aún: asdf —o mise, su sucesor más rápido— unifica todo en una sola herramienta. Declaras las versiones en un archivo .tool-versions en la raíz del proyecto:
nodejs 20.11.0 python 3.12.2
Al entrar en la carpeta, el entorno cambia automáticamente a las versiones correctas. Haz commit de este archivo y todo el equipo ejecutará el mismo runtime: se acabó el «en mi máquina funciona».
Containers y devcontainers: la máquina es descartable
El gestor de versiones resuelve el lenguaje. Pero ¿qué pasa con Postgres, Redis o esa molesta librería del sistema que cuesta tanto instalar? Ahí entran los containers. Un docker-compose.yml en el repositorio levanta la base de datos y las dependencias con un solo comando, de forma idéntica para todo el equipo y sin contaminar tu máquina.
Los devcontainers van más allá: describes todo el entorno en un .devcontainer/devcontainer.json y VS Code —o GitHub Codespaces— monta un container con todo listo: extensiones, herramientas y versiones. El onboarding se convierte en «abre el proyecto y espera a que termine el build». La máquina física pasa a ser solo un cliente delgado; el entorno vive en el repositorio.
Secretos y .env: donde la mayoría se quema
Regla número uno: .env nunca va al Git. Añade .env al .gitignore antes del primer commit, no después: un secreto que ya llegó al historial seguirá allí aunque borres el archivo.
La práctica adecuada es versionar un .env.example con las claves, pero sin sus valores:
DATABASE_URL= API_KEY=
Así, la siguiente persona que desarrolle el proyecto sabrá qué debe completar sin que expongas nada. Para secretos reales, usa un gestor —1Password CLI, doppler, sops— que inyecte los valores al ejecutar la aplicación, sin dejar rastros en el disco. Y si un secreto se filtró en el historial, rota la clave. Borrar el commit no deshace la filtración.
La prueba de fuego: configura todo desde cero
La prueba de que tu entorno es reproducible es brutalmente sencilla: toma una máquina limpia —o un container— y configura todo siguiendo únicamente lo que está en el repositorio. Si te atascas en algún paso, ese paso es conocimiento que todavía vive solo en tu cabeza: documéntalo o automatízalo.
Empieza poco a poco: hoy, mueve tus dotfiles a un repositorio. Mañana, adopta un gestor de versiones. La próxima semana, escribe el docker-compose. No necesitas una configuración perfecta; necesitas una que puedas reconstruir. Porque la próxima máquina nueva está en camino, y la diferencia entre el café caliente y el café frío es cuánto automatizaste antes.