De copiar HTML por SSH a un flujo con Git, Gitea y entorno de desarrollo

Desde la última entrada del blog hasta hoy han pasado varias cosas interesantes en mi laboratorio técnico. No estoy trabajando solamente en que franxu.tech sea la punta del iceberg de mi perfil profesional: también estoy metido en varios proyectos internos a los que todavía no he dedicado el tiempo suficiente para publicarlos por aquí.

Por eso he querido hacer una pausa breve, ordenar un poco la casa y volver a escribir. Principalmente porque no quiero que quede en vano el trabajo inicial que supuso levantar esta web estática exactamente de la forma en la que quería: sencilla, sin CMS, sin base de datos y tocando HTML directamente.

En esta entrada voy a contar cómo he descubierto América estando ya descubierta: el flujo de trabajo con Git aplicado a una web estática personal.

El problema

franxu.tech empezó siendo una web estática sencilla, sin CMS ni base de datos. Prefería tocar el HTML directamente —sí, me gusta complicarme— y editar manualmente las URLs necesarias para que todo funcionase correctamente. El problema es que, cuando todo depende de cambios manuales, también es fácil olvidarse de actualizar enlaces, referencias, RSS, sitemap o cualquier otro fichero relacionado.

El flujo era simple: abría un HTML, lo editaba, revisaba los enlaces y copiaba los ficheros al VPS por SSH. Funcionaba, evidentemente. Pero cada cambio terminaba haciéndose muy cerca de producción, y ya sabemos que trabajar directamente sobre producción no suele ser una buena práctica. En casa del herrero...

De hecho, un enlace roto hacia un segundo post que acabé eliminando estuvo durante semanas mostrando un precioso error 404. No estamos hablando de un entorno crítico ni de la web de un banco, lo sé. Es una web estática personal. Pero si algo he aprendido con los años es que conviene dejar el terreno limpio y fácil de mantener, aunque el proyecto sea pequeño.

Decidí cambiar mi forma de trabajar

Antes editaba casi directamente sobre producción, y eso ya me había pasado factura. Por pereza, dejé el fallo sin corregir durante más tiempo del que debería. Mientras tanto, estaba trabajando en otros proyectos donde Git ya era parte natural del flujo de trabajo, especialmente en desarrollo de aplicaciones y documentación técnica.

Ahí fue cuando pensé: franxu.tech no podía ser menos. Es una web sencilla, sí, pero precisamente por ser manual es fácil que aparezcan errores. Así que decidí llevarla también a un repositorio, trabajar con ramas y dejar de tratar los cambios como simples copias de archivos.

No descubrí nada nuevo. Git lleva ahí toda la vida. Pero muchas veces conocemos las herramientas y no las aplicamos a nuestros propios procesos hasta que un pequeño problema nos obliga a ordenar la forma de trabajar.

Separar desarrollo de producción

El siguiente paso fue separar entornos. Por muy pequeño que sea un proyecto, tener una copia de trabajo y un entorno de pruebas aporta mucha tranquilidad.

En mi caso, la estructura queda así:

• franxu.tech: entorno de producción, público.
• dev.franxu.tech: entorno de desarrollo, protegido con autenticación básica.

Esto me permite probar cambios en una URL real, servida por Nginx y en el mismo VPS, pero sin exponerlos directamente al público. Cuando algo funciona en desarrollo, entonces tiene sentido llevarlo a producción.

Mis primeros Pull Requests en este flujo

No son mis primeros Pull Requests de la vida. Hace años ya trabajé con GitHub cuando aprendía desarrollo Android nativo en Java. Pero sí los considero mis primeros Pull Requests dentro de mi propio ecosistema local, usando Gitea y aplicándolo tanto a este blog como a otros proyectos personales.

Para un desarrollador, Git es una herramienta diaria. Para alguien de sistemas como yo, no siempre ha sido un requisito imprescindible en el trabajo del día a día, porque no suelo dedicarme a desarrollar software como actividad principal. Aun así, cada vez tengo más claro que Git no sirve solo para código: también sirve para versionar configuraciones, documentación, scripts, procedimientos y cualquier pieza técnica que merezca trazabilidad.

Automatizando mi vida

Si eres sysadmin y llevas unos años en esto, sabes que si no te creas tus propias herramientas y no automatizas tareas repetitivas, acabas apagando fuegos mientras se encienden siete más alrededor.

Para mí, automatizar no es un extra: es parte del oficio. En este caso, Git se ha convertido en una herramienta complementaria para organizar mejor mi trabajo. Puedo crear ramas, probar cambios, hacer Pull Requests y desplegar solo cuando tiene sentido hacerlo.

Además, he añadido scripts de despliegue para no depender de recordar comandos largos de rsync. La idea es sencilla:

• deploy-dev.sh despliega en dev.franxu.tech.
• deploy-prod.sh despliega en franxu.tech.

Con esto, el flujo deja de ser “edito y copio a mano” para convertirse en algo mucho más ordenado:

rama de trabajo
  ↓
commit
  ↓
Pull Request
  ↓
develop
  ↓
deploy a dev
  ↓
validación
  ↓
main
  ↓
deploy a producción

Conclusión

Estoy cómodo trabajando con Git para casi todo. Y no necesariamente para escribir código. También para versionar configuraciones, documentar cambios, guardar scripts y evitar que todo termine perdido en directorios y subdirectorios que se convierten en un cajón de sastre.

franxu.tech sigue siendo una web estática sencilla, pero ahora tiene un flujo de trabajo mucho más serio detrás: repositorio en Gitea, ramas, Pull Requests, entorno de desarrollo, entorno de producción y despliegues automatizados.

No es una infraestructura compleja, ni pretende serlo. Pero está más ordenada, es más mantenible y me permite seguir publicando sin miedo a romper producción por un cambio manual mal revisado.