La integración continua publica un cambio en tu web siguiendo siempre el mismo recorrido: el código se escribe en una rama aparte, un sistema automático lo compila y lo prueba, se genera una vista previa, alguien la revisa y solo entonces pasa a producción. Si algo falla, el cambio se detiene antes de llegar a tus clientes.
Los 6 pasos para publicar un cambio en tu web con integración continua
Cualquier cambio recorre seis pasos fijos y cada uno deja registro: un precio, un texto legal o un campo nuevo en el formulario. Como ejemplo, imagina que quieres cambiar el teléfono del pie de página y añadir el campo «Empresa» al formulario de contacto.
1. Una rama propia para el cambio
El desarrollador crea una copia aislada del código, llamada rama, con un nombre descriptivo como contacto-campo-empresa. La web publicada no se toca. Si mañana hay que corregir algo urgente, se hace en otra rama sin mezclar trabajos a medio terminar.
2. Commit y subida al repositorio
Cada modificación se guarda con un mensaje claro («Añade campo Empresa al formulario») y se sube al repositorio. Así queda constancia de quién cambió qué y cuándo, y cualquier versión anterior se puede recuperar.
3. Compilación y comprobaciones automáticas
Al subir la rama, un servidor de integración continua ejecuta una lista de tareas: instala dependencias, compila la web y lanza las comprobaciones configuradas. Si una sola falla, el proceso se marca en rojo y el cambio no avanza.
4. Vista previa en una dirección temporal
Si todo pasa en verde, se genera una versión de la web con el cambio aplicado en una dirección temporal. Tú puedes abrirla desde el móvil, rellenar el formulario y comprobar que el nuevo teléfono aparece bien, sin que tus clientes vean nada.
5. Revisión y fusión con la rama principal
Otra persona del equipo revisa el código y tú validas la vista previa. Con las dos aprobaciones, la rama se fusiona con la principal, que es la que representa la web en producción.
6. Despliegue a producción
La fusión dispara el despliegue automático. El servidor vuelve a compilar desde cero y publica la nueva versión, sin copiar archivos a mano por FTP ni editar en directo.
Qué revisa el pipeline de integración continua antes de publicar
El pipeline es la lista de comprobaciones que se ejecuta en cada cambio, y su contenido se decide al montar el proyecto. Estas son las habituales en una web profesional:
| Comprobación | Qué detecta | Ejemplo en una web | Si falla |
|---|---|---|---|
| Compilación | Errores de sintaxis o archivos que faltan | Una imagen borrada que una página sigue usando | No se genera la vista previa |
| Linter y formato | Código inconsistente o con errores evidentes | Una variable mal escrita en el formulario | Se marca la línea exacta |
| Tests automáticos | Funciones que dejan de comportarse como antes | El formulario deja de enviar correos | Se bloquea la fusión |
| Enlaces y rutas | Páginas que devuelven error 404 | Un enlace del menú a una sección renombrada | Lista de enlaces rotos |
| Tamaño y rendimiento | Archivos excesivos que ralentizan la carga | Una foto subida sin comprimir | Aviso antes de publicar |
Los tests merecen un capítulo propio; aquí importa el principio: la máquina repite las mismas comprobaciones en cada cambio, sin cansarse ni saltarse pasos.
Cómo se deshace un cambio publicado con integración continua
Cada despliegue genera una versión completa e independiente de la web, de modo que volver a la anterior consiste en reactivarla. No hay que reconstruir nada ni buscar qué archivo se modificó.
Hay dos formas de hacerlo:
- Vuelta atrás inmediata. Desde el panel de despliegues se marca como activa la versión previa. Sirve cuando el problema es visible y urgente, como una página en blanco.
- Revert del cambio. Se crea un commit que anula exactamente el cambio problemático y pasa por el mismo pipeline. Es la opción correcta cuando el error es menor y quieres dejar constancia de la corrección.
La diferencia con un despliegue manual es notable. Si alguien sube archivos por FTP y algo se rompe, nadie sabe con certeza cuál era el estado anterior. Con integración continua, el historial responde a esa pregunta siempre.
Integración continua en una web corporativa, una tienda online o un CRM a medida
El recorrido de seis pasos es el mismo en cualquier proyecto, pero las comprobaciones cambian según lo que esté en juego.
- Web corporativa o landing. Basta con compilación, enlaces y rendimiento. En un proyecto de diseño web a medida el pipeline se monta al inicio y protege desde la primera publicación.
- Tienda online. Se añaden pruebas del carrito y de la pasarela de pago en modo de prueba, para que un cambio de diseño no impida cobrar.
- CRM o ERP. Entran en juego las migraciones de base de datos: cambios en tablas que deben aplicarse en orden y sin perder registros. En CRM y aplicaciones a medida también se verifican las integraciones y la automatización de procesos, como el envío de facturas o los avisos por correo.
En un software de gestión para pymes, un error no rompe una página: puede duplicar pedidos o dejar a un comercial sin acceso. Por eso el pipeline es más estricto y la vista previa se prueba con datos ficticios, nunca con los reales.
4 preguntas sobre integración continua que debes hacer a tu proveedor web
Tu proveedor debería responder a estas preguntas sin rodeos antes de firmar:
- ¿Dónde está el repositorio? Lo ideal es que esté a tu nombre. En Sinergia Barcelona el código es propio del cliente y no se trabaja con plantillas genéricas.
- ¿Puedo ver los cambios antes de publicarlos? La respuesta debería ser una vista previa por cada cambio.
- ¿Cómo se vuelve atrás? Pide que te lo muestren en el panel de despliegues.
- ¿Quién aprueba la publicación? Debe haber al menos una revisión humana antes de producción.
Si quieres que valoremos tu web actual o un proyecto nuevo con este flujo incluido, puedes solicitar presupuesto online.
Preguntas frecuentes
¿La integración continua encarece el desarrollo de una web?
La integración continua se configura una vez al inicio del proyecto y después funciona sola en cada cambio. En Sinergia Barcelona forma parte del desarrollo, sin partida aparte. Los cambios fuera del alcance acordado se cobran a 45-60 €/h, igual que cualquier otra modificación.
¿Puedo ver los cambios de mi web antes de que se publiquen?
Los cambios de una web con integración continua generan una vista previa en una dirección temporal. Puedes abrirla en el ordenador o en el móvil, revisar textos y probar formularios. Nada llega a producción hasta que la revisión está aprobada y la rama se fusiona.
¿Qué pasa si un cambio rompe la web después de publicarlo?
Un cambio que rompe la web después de publicarse se deshace reactivando la versión anterior desde el panel de despliegues. Cada publicación queda guardada como versión completa, así que la web vuelve al estado previo mientras se corrige el error con calma en una rama aparte.
¿La integración continua sirve para una landing page sencilla?
Una landing page sencilla también se beneficia de la integración continua, aunque con menos comprobaciones: compilación, enlaces y peso de las imágenes. Evita publicar una campaña con un botón roto o una foto enorme, y permite cambiar textos sin miedo durante la campaña.