Git, entornos y despliegue continuo: cómo se publica una web profesional

Durante años, publicar un cambio en una web consistía en abrir un programa de FTP, arrastrar unos archivos al servidor y cruzar los dedos. Si algo se rompía, había que recordar qué archivo se había tocado, buscar una copia en el escritorio de alguien y volver a subirla. Todavía hoy nos llegan proyectos así: carpetas llamadas «web_buena», «web_buena_2» y «NO TOCAR», y nadie sabe con certeza cuál es la que está publicada.

En el estudio trabajamos de otra manera desde hace tiempo, y la diferencia se nota sobre todo en la tranquilidad. Cada cambio queda registrado con su autor y su motivo, se prueba en una copia de la web antes de que lo vea nadie y se publica con un proceso automático que siempre hace lo mismo. Si algo no convence, volver a la versión anterior es cuestión de segundos.

Esta guía explica ese flujo sin dar por supuesto que programas: qué es Git, para qué sirven los entornos, qué significa integración y despliegue continuo y cómo se adapta todo a una web corporativa, a una tienda o a un WordPress.

01Git: la memoria de tu proyecto web

Git es un sistema de control de versiones. Dicho de forma sencilla, es un programa que guarda fotografías del estado de todos los archivos de un proyecto cada vez que alguien decide registrar un cambio. Cada fotografía se llama commit y lleva un mensaje que explica qué se hizo, quién lo hizo y cuándo.

El conjunto de commits forma el historial del proyecto, que vive en un repositorio. Ese repositorio está en el ordenador de cada persona del equipo y, normalmente, también en un servicio en la nube como GitHub, GitLab o Bitbucket, que actúa como copia central compartida.

Tres conceptos más y ya tienes el mapa completo:

• →Rama (branch). Una línea de trabajo paralela. La rama principal (main) contiene lo que está publicado o listo para publicarse. Para una mejora nueva se crea otra rama, se trabaja en ella sin afectar a la principal y, cuando está lista, se integra.
• →Petición de cambio (pull request o merge request). La propuesta de integrar una rama en la principal. Es el momento de revisar el código, comentar y aprobar.
• →Etiqueta (tag). Un nombre fijo para un commit concreto, por ejemplo v2.3.0 o lanzamiento-octubre. Sirve para localizar versiones importantes sin buscar entre cientos de commits.

Mensajes de commit que se entienden dentro de un año

Un historial es tan útil como sus mensajes. «Cambios», «arreglo» o «último» no dicen nada. Lo que funciona es una línea corta en imperativo que describa el resultado, y un cuerpo opcional con el porqué. Muchos equipos siguen la convención Conventional Commits, que añade un prefijo de tipo:

feat(contacto): añadir campo de teléfono opcional al formulario
fix(menu): cerrar el menú móvil al pulsar un enlace interno
perf(home): servir el vídeo del hero en AV1 con respaldo en H.264
docs: explicar cómo crear un entorno local en el README

Con esta disciplina, el historial se convierte en un registro legible de la evolución de la web y hasta permite generar automáticamente las notas de cada versión.

02Los tres entornos: local, pruebas y producción

Un entorno es un lugar donde la web funciona. Una web profesional tiene, como mínimo, tres:

La regla de oro es que el entorno de pruebas se parezca todo lo posible al de producción: la misma versión del lenguaje, la misma configuración del servidor, las mismas variables. Si en pruebas funciona y en producción no, casi siempre es porque algo era distinto.

Previsualizaciones por cada cambio

Las plataformas actuales (Vercel, Netlify, Cloudflare Pages y muchos servicios de alojamiento gestionado) generan automáticamente una URL de previsualización por cada rama o petición de cambio. Eso cambia por completo la forma de revisar con el cliente: en lugar de capturas de pantalla, le enviamos un enlace con la web real funcionando, puede navegarla en su móvil y dejar comentarios. Cuando da el visto bueno, ese mismo código es el que se publica.

Variables de entorno y secretos

Las claves de APIs, las contraseñas de bases de datos y los identificadores de servicios cambian según el entorno y nunca deben guardarse en el repositorio. Se configuran como variables de entorno en cada plataforma. Un archivo .env.example en el repositorio documenta qué variables existen, sin sus valores reales, para que cualquier persona nueva sepa qué necesita.

03Integración continua: que las máquinas revisen lo repetitivo

La integración continua (CI, de continuous integration) consiste en que, cada vez que alguien propone un cambio, un sistema automático compruebe que el proyecto sigue en buen estado. En lugar de confiar en que cada persona se acuerde de revisarlo todo, la revisión se escribe una vez y se ejecuta siempre.

En una web, las comprobaciones habituales son:

1. 01Instalación limpia de las dependencias, para detectar paquetes que solo funcionaban en un ordenador concreto.
2. 02Linting: revisión del estilo y de errores comunes del código (ESLint, Stylelint).
3. 03Comprobación de tipos, si el proyecto usa TypeScript.
4. 04Tests: unitarios para la lógica y, en las partes críticas (formulario de contacto, carrito, pago), pruebas de extremo a extremo con herramientas como Playwright.
5. 05Compilación de la web de producción, para asegurarse de que se puede construir.
6. 06Auditorías automáticas de rendimiento y accesibilidad con Lighthouse CI o axe, con umbrales mínimos.

Este es un ejemplo simplificado de flujo en GitHub Actions, el sistema de automatización de GitHub:

# .github/workflows/ci.yml
name: CI
on: [pull_request]
jobs:
  comprobar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build

Si alguna comprobación falla, la petición de cambio queda marcada en rojo y no se integra hasta resolverlo. Configuramos además la rama principal como protegida: solo recibe cambios a través de peticiones revisadas y con todas las comprobaciones en verde.

04Despliegue continuo: publicar sin ceremonias

El despliegue continuo (CD, de continuous deployment o continuous delivery) es la segunda mitad: cuando un cambio entra en la rama principal, se publica de forma automática o con un solo clic, siempre con el mismo procedimiento.

Despliegues atómicos

El concepto clave aquí es el despliegue atómico. La nueva versión de la web se construye completa en una carpeta aparte y, solo cuando está lista, el servidor pasa a servirla de golpe. Nadie llega a ver una web a medio subir, con unos archivos nuevos y otros viejos.

En plataformas como Vercel o Netlify esto viene de serie. En un servidor propio se consigue con una estructura de carpetas por versión y un enlace simbólico que apunta a la activa:

/var/www/miweb/
  releases/
    2026-07-18-1030/
    2026-07-21-1645/
    2026-07-22-0915/   <- nueva versión, construida y probada
  current -> releases/2026-07-22-0915
  shared/              <- archivos subidos y configuración que persisten

Publicar es cambiar el enlace current; volver atrás, apuntarlo a la carpeta anterior. Herramientas como Deployer o Capistrano automatizan este patrón, y un sencillo script con rsync también lo resuelve bien en proyectos pequeños.

Volver atrás en segundos

La reversión (rollback) es la red de seguridad de todo el sistema. Mantenemos siempre las últimas versiones publicadas y comprobamos de vez en cuando que la vuelta atrás funciona, igual que se prueba una alarma. Cuando un cambio afecta a la base de datos, la migración se diseña en dos pasos compatibles hacia atrás: primero se añade la columna o tabla nueva sin borrar la antigua y, en un despliegue posterior, cuando todo está estable, se retira lo que sobra.

Después de publicar

Un despliegue no termina al copiar archivos. La lista corta que repasamos tras cada publicación importante:

• →La portada, una página interior y el formulario principal responden correctamente.
• →El certificado HTTPS y las redirecciones siguen en su sitio.
• →La caché del CDN se ha invalidado si hacía falta.
• →Los errores del servidor y del navegador están en niveles normales (Sentry o los registros de la plataforma lo muestran).
• →Las métricas de Core Web Vitals no empeoran en los días siguientes.

05Cómo se aplica a cada tipo de web

Webs a medida y sitios estáticos

Es el caso ideal. Proyectos con frameworks como Next.js, Astro o Eleventy encajan de forma natural con previsualizaciones por rama y despliegues atómicos. Si te interesa por qué los usamos, en la guía sobre qué es Next.js y sus ventajas lo contamos con calma, y en la de SSR, SSG e ISR explicamos cómo influye la forma de renderizar en el despliegue.

WordPress

WordPress mezcla código y contenido, y eso pide separar las dos cosas:

• →En Git: el tema, el tema hijo, los plugins propios y la configuración (sin contraseñas).
• →Gestionado con versiones fijas: el núcleo y los plugins de terceros, mediante Composer (con WPackagist) o con una lista documentada.
• →Fuera de Git: la base de datos y la carpeta wp-content/uploads, que se sincronizan con WP-CLI o con herramientas específicas, y siempre de producción hacia pruebas, no al revés.

Así las actualizaciones de plugins se prueban primero en staging, que es donde suelen aparecer las sorpresas. Lo hablamos también en cuándo tiene sentido WordPress.

Tiendas online

Aquí el despliegue convive con pedidos reales, así que se programa en franjas de poco tráfico, se evita publicar justo antes de una campaña y se prueba el circuito de compra completo (con la pasarela en modo de pruebas) en cada previsualización.

06Ejemplo resuelto: de FTP a despliegue continuo en una semana

Una empresa de alquiler vacacional de la zona llegó al estudio con una web en PHP que se actualizaba por FTP desde dos ordenadores distintos. Cada temporada aparecían errores que nadie sabía de dónde venían. El cambio se hizo así:

1. 01Descargamos la versión publicada y la convertimos en el primer commit de un repositorio privado.
2. 02Comparamos esa versión con las carpetas que había en los dos ordenadores y documentamos las diferencias.
3. 03Creamos un entorno de pruebas protegido con contraseña, con la misma versión de PHP que producción.
4. 04Montamos un flujo de CI sencillo: instalación, revisión de sintaxis y una prueba automática del formulario de reserva.
5. 05Configuramos el despliegue atómico con carpetas de versión y enlace simbólico, y deshabilitamos el acceso FTP.
6. 06Escribimos un README de una página con cómo pedir un cambio, cómo previsualizarlo y cómo volver atrás.

Desde entonces, cada mejora pasa por una previsualización que la propietaria revisa en su móvil, y el historial responde en segundos a la pregunta que antes costaba una tarde: qué cambió y cuándo.

07Un proceso que da tranquilidad

Un buen flujo de publicación no se ve desde fuera, pero se nota en todo: menos sustos, cambios más frecuentes y pequeños, y la confianza de que cualquier mejora se puede probar sin miedo. Complementa además a un buen plan de copias de seguridad, porque el código queda protegido en el repositorio y lo demás, en las copias.

En SIMA este circuito forma parte de cada proyecto de desarrollo web y apps y del mantenimiento web que hacemos para nuestros clientes. Si quieres pasar de las subidas a mano a un proceso con red, escríbenos y lo planteamos juntos.