Infraestructura para un equipo que todavía no existe
El problema
Antes de escribir la primera línea de un sistema hace falta un lugar donde guardar el código, un lugar donde correrlo, y una forma de que lo segundo se actualice cuando cambia lo primero.
Con dos condiciones: el código no puede salir de la red de la empresa, y hoy hay un solo desarrollador — pero eso puede cambiar.
Y había un tercer problema, más chico de contar y más caro de tener: el circuito era probar en mi máquina y de ahí a producción, sin nada en el medio. Mi máquina no es producción. El primer lugar donde se veía la verdad era el único donde no se podía fallar.
Qué se ve desde afuera
- Afuera Internet Sólo llega hasta acá. No hay ninguna máquina de la red expuesta directamente.
- Entrada única Reverse proxy Recibe todo el tráfico externo y lo reenvía hacia adentro. Es lo único visible.
- Adentro Servicios Aplicaciones en contenedores sobre servidores propios, con el motor de base compartido entre sistemas.
Qué construí
- Repositorio Git self-hosted con Gitea, dentro de la red. Lo monté y lo administro: usuarios, organizaciones, permisos.
- Dos servidores Docker separados: uno de producción y otro de staging, con su propia base de datos.
- Despliegue automático por entorno con Gitea Actions: un push a
mainconstruye y publica en producción; un push a la rama de staging hace lo mismo del otro lado.
Los servicios quedan detrás de un reverse proxy, en red privada, sin exposición directa a internet.
El reverse proxy lo montó un compañero del área. Yo administro la topología y despliego los servicios detrás de él.
Dos ramas, dos destinos
push a main
Producción
- Servidor Docker propio, separado del de staging.
- Clona desde el volumen local de Gitea, que vive en la misma máquina.
- Nunca se toca desde el pipeline de staging.
push a staging
Staging
- Otro servidor Docker, con su propia base de datos.
- Clona por red: Gitea no vive de ese lado.
- Descartable: se pisa con cualquier rama que se quiera mostrar.
Vista ilustrativa · el banner de entorno
- Bobina 48 g · rollo 1.240 mmdisponible
- Bobina 45 g · rollo 900 mmen uso
- Tinta negra · lote 4471disponible
- Placa CTP · caja 200 ubajo mínimo
Las decisiones que costaron
Construir como si el equipo ya fuera más grande. Como único desarrollador, lo razonable sería armar todo a mi medida. No está hecho así: hay usuarios y organizaciones en lugar de un repositorio pelado, despliegue automático en lugar de un script que corro yo, y decisiones escritas en lugar de decisiones que viven en una sola cabeza.
Todo eso es exagerado para uno solo y es exactamente lo necesario para tres. La diferencia importa el día que alguien más entra: o encuentra un lugar donde trabajar, o encuentra un sistema que sólo yo sé operar.
Un repositorio propio, no un servicio externo. El código de la empresa no puede salir de la red. Eso descarta de entrada cualquier servicio alojado afuera, por cómodo que sea, y obliga a montar y sostener el repositorio adentro: usuarios, permisos, backups, actualizaciones.
Staging descartable por diseño. No es un entorno estable que hay que cuidar: es un banco de pruebas que se pisa. Cualquier rama de feature se fuerza encima para presentarla, y lo que había antes se pierde sin drama.
Un staging “prolijo” termina siendo un segundo sistema que mantener, con su propio estado que nadie quiere romper — y entonces vuelve a no haber dónde equivocarse.
Un banner visible que dice en qué entorno estás. El frontend de staging se construye con una variable distinta, y eso pinta un cartel en la interfaz. Parece cosmético y no lo es: la falla más cara de tener dos entornos parecidos es hacer en el equivocado lo que ibas a hacer en el otro. Cuesta una variable de build y elimina esa clase entera de error.
El compose de staging viaja con el código; el de producción no. En staging, la definición de los servicios está versionada en el repo y cada despliegue la copia. Así un cambio de topología se prueba junto con el código que lo necesita, en vez de ser un cambio manual en el servidor que alguien tiene que acordarse de replicar.
El motor de base compartido es un límite, no una elección. Lo prolijo sería una instancia por sistema. La infraestructura disponible no da para eso. No lo cuento como decisión de diseño porque no lo fue: es una restricción real, y el trabajo consistió en armar todo lo demás sabiendo que existe.
Resultado
El código llega a producción por un push, y cualquier rama se puede levantar en staging para verla funcionando antes. Sobre esta infraestructura se despliegan todos los sistemas de esta página.