// workshop equipo de dev

Por qué usar 12-Factor

Doce reglas para apps que se despliegan, escalan y se mudan sin drama. Cada una, accionable.
el problema

La app que solo corre en una máquina

  • ✕Config y credenciales hardcodeadas en el código.
  • ✕Estado guardado en el disco local: no puedes escalar ni reiniciar.
  • ✕"En prod hay que hacer unos pasos manuales" que nadie recuerda.
12-Factor es el checklist para que tu app corra igual en cualquier lado.
analogía
Una app 12-factor es un inquilino que se muda sin drama: no deja nada pegado a la casa.
// empaca sus cosas (config, datos) afuera; la casa (el server) es intercambiable
el mapa

El mapa completo

ICodebase: un repo, muchos deploys
IIDependencias: declaradas y fijadas
IIIConfig: en el entorno
IVBacking services: recursos por URL
VBuild, release, run: separados
VIProcesos: sin estado
VIIPort binding: expones un puerto
VIIIConcurrencia: escalas por procesos
IXDisposability: arranca y para rápido
XDev = prod
XILogs: como stream a stdout
XIIAdmin: procesos one-off
$_
manos a la obra

Los que más mueven la aguja

Cinco reglas que puedes aplicar hoy.
config afuera

La config vive en el entorno

# mal: hardcodeada en el código
DB = "postgres://user:pass@localhost/db"
# bien: del entorno
import os
DB = os.environ["DATABASE_URL"]
La misma imagen, distinta config por entorno. Los secretos nunca en el código.
la regla de oro
La config no vive en el código. Vive en el entorno.
// mismo build para dev, staging y prod; solo cambian las variables
nada a mano

Nada de «instala esto a mano»

# nada de "instala esto a mano en el server"
requirements.txt / package-lock.json
uv.lock / go.mod
Un lock file fija la versión exacta. La build es idéntica en cualquier máquina.
sin estado

Procesos desechables, datos afuera

  • →Nada de guardar sesión o archivos en el disco local del proceso.
  • →Estado en un backing service: DB, Redis, S3, por URL.
  • →Así puedes reiniciar, escalar y mover el proceso sin perder nada.
Cambiar de proveedor = cambiar una URL, no el código.
un solo stream

Logs a stdout, como stream

# mal: escribir a un archivo que la app rota
# bien: imprimir el evento y ya
print(json.dumps({"level":"info","msg":"pago ok"}))
El entorno (Docker, la nube) captura el stream y lo enruta. Tu app no gestiona archivos de log.
build y parity

Build, release, run separados

  • →Build: compilas una imagen. Release: le sumas la config. Run: la corres.
  • →Un release es inmutable y tiene versión: puedes hacer rollback.
  • →Dev y prod lo más parecidos posible: Docker te lo da casi gratis.
Conecta con Docker: la imagen es el build; la config, el release.
el lunes

Acerca una app a los 12 factores

01Saca la config al entorno (env vars).
02Fija dependencias con un lock file.
03Quita el estado del disco local.
04Manda logs a stdout, no a archivos.
05Empaqueta con Docker (dev = prod).
06Separa build, release y run.
cierre

Corre igual en todos lados

Config afuera, sin estado, logs al stream, dev = prod. Acerca una app tuya a los 12 factores esta semana.
seguimos en contacto

Sígueme

# notas técnicas y proyectos
web dev.jotive.com.co
# instagram
ig @jotive.dev
A · 01 Por qué usar 12-Factor · workshop ← → 01 / 13