Saltar a contenido

Everything is code

Principio de diseño: el estado completo de la infra está representado en git. No hay cambios "fuera de git" — ni vía SSH manual, ni vía UI mutante, ni vía CLI directo. La cita canónica: "If it's not in git, it doesn't exist." Es el prerequisito que hace posible AI as operator, IaC, y self-healing.

Contexto

Es el principio menos romántico y más alto retorno del wiki. Sin él, ninguna de las prácticas de software engineering que el usuario quiere aplicar funciona: no hay rollback, no hay reproducibilidad, no hay auditoría, no hay forma de que un agente (humano o AI) sepa qué cambió y por qué. Adoptarlo es doloroso al principio (rompe hábitos de "lo arreglo rápido vía SSH") y acumulativamente valioso (cada upgrade futuro es más barato).

Contenido

Qué significa concretamente

Antipattern Patrón "everything is code"
Edito YAML en la UI de HA Edito en repo git, push, GitOps lo aplica
ssh server → vi /etc/nginx.conf Ansible role en repo + ansible-playbook
Apt-get install algo "para probar" Lo agrego a la Ansible role o lo descarto
Cambio una entity registry name desde la UI Update vía YAML / blueprint / customize.yaml en repo
Re-pair de Zigbee device "y veo qué pasa" Documento el procedimiento, lo ejecuto, anoto el resultado

Beneficios derivados

  1. Audit trail completo — git log te dice quién (humano o agente) cambió qué, cuándo, por qué.
  2. Rollback trivial — git revert <commit> deshace cualquier cambio.
  3. Reproducibilidad desde cero — si el hardware muere, terraform apply + ansible-playbook reconstruye.
  4. Disabled drift — si alguien cambió algo a mano, el siguiente apply lo detecta como drift (o lo sobrescribe).
  5. Habilita AI as operator — el agente puede entender el estado leyendo el repo, y puede proponer cambios vía PR que el humano review.

Costos a aceptar

  • Latencia operativa — un cambio que antes era vi + service restart ahora es edit file + commit + push + wait for apply. Esto es deliberado: la latencia te obliga a pensar.
  • Setup inicial caro — convertir un sistema "lleno de cambios manuales" en un sistema "todo en git" lleva semanas. Hay que decidir cuándo se hace.
  • Disciplina cultural — la primera vez que uno "arregla rápido vía SSH" rompe el principio. Tiene que ser política, no buena intención.

Aplicado al setup del usuario

Qué irá a git

  • Toda la config de HA (YAML, blueprints, automations, scripts, custom_components instalados).
  • Toda la config de ESPHome (yaml files por device).
  • Toda la config de Z2M (configuration.yaml).
  • Todos los Ansible playbooks / Terraform modules del host(s).
  • Healthchecks declarativos (Gatus config) + dashboards (Grafana JSON).

Qué no irá a git

  • Secrets en plain text — usar Ansible Vault o sops o env-vars referenciadas.
  • Backups binarios — van a un bucket / NAS, no a git.
  • DBs en runtime (recorder, history) — git no es DB.
  • Coordinator backups de Zigbee (binarios) — sí están en database.db pero no en git; van a backup off-site.

Repo layout sugerido (a refinar)

homelab/
├── terraform/                # Proxmox / VM / DNS
├── ansible/                  # roles para host (Docker, healthchecks, etc.)
├── compose/                  # docker-compose.yml por host
├── home-assistant/           # bind mount del HA Container (subset, sin secrets)
├── esphome/                  # configs por device
├── zigbee2mqtt/              # configuration.yaml
├── monitoring/
│   ├── gatus.yaml
│   ├── prometheus/
│   └── grafana/
└── docs/                     # postmortems, decision logs

Relaciones

Citas / evidencia

Abierto / gaps

  • Cómo lidiar con HA UI: HA mete cosas a .storage/ que son binarios JSON. ¿Se pueden migrar a YAML o son inevitables? Documentar.
  • Patrón concreto para secrets: Ansible Vault vs sops vs Bitwarden vs Infisical (el wiki principal usa Infisical, ver root CLAUDE.md).
  • Cómo el agente AI detecta drift y reacciona: re-apply silente vs alert humano vs PR de reconciliación.
  • ¿Conviene tener un repo monorepo o múltiples (uno por nodo / por dominio)? Trade-offs.