El Pipeline de Despliegue que la Mayoría de Agencias Se Salta

Si alguna vez una actualización del sitio web ha tumbado tu web en producción — un cambio de plugin que rompió el diseño, una edición que dejó la página en blanco — el problema normalmente no es la actualización en sí. Es que se hizo directamente en el sitio en producción, sin red de seguridad. Esto explica, en lenguaje sencillo, el pipeline de despliegue que los buenos equipos usan para actualizar un sitio web sin romperlo.

Forma parte de nuestra serie sobre mantener un sitio fiable tras el lanzamiento; el contexto completo está en el artículo sobre el deterioro post-lanzamiento.

Por qué las actualizaciones del sitio web rompen las cosas

Las actualizaciones de un sitio web rompen las cosas principalmente por una razón: el cambio se hace directamente en el sitio web en producción, por lo que si algo sale mal, tus visitantes lo ven al instante — no hay margen entre hacer el cambio y que el público lo vea.

Editar en producción es rápido, que es exactamente por qué tanta gente lo hace. Pero un sitio WordPress está hecho de partes que interactúan — el software principal, el tema, los plugins, el código personalizado — y un cambio en uno puede chocar con otro de maneras que no puedes predecir hasta que realmente se ejecuta. Hazlo en el sitio en producción y el choque ocurre delante de tus clientes: un diseño roto, una pantalla en blanco, un formulario de contacto o un flujo de reservas que silenciosamente deja de funcionar. Lo mismo que hace atractivo editar en producción — su inmediatez — es lo que lo hace arriesgado.

Cómo es un pipeline de despliegue real

Un pipeline de despliegue real mueve cada cambio a través de cuatro etapas — desarrollo, staging, validación, luego producción — para que un cambio se pruebe en una copia privada del sitio antes de que llegue a tus visitantes en producción.

1. Desarrollo. Los cambios se construyen y prueban en un entorno de desarrollo separado, nunca en tu sitio en producción.
2. Staging. El cambio se sube a un sitio de staging — una copia privada y completa de tu sitio en producción — con tu contenido real sincronizado, para que se pruebe contra la realidad en lugar de una pizarra en blanco.
3. Validación. El sitio se verifica en staging: ¿sigue funcionando todo, carga rápido y se ve bien? Nada avanza hasta que pasa.
4. Producción. Solo una vez validado va el cambio a producción — el sitio en vivo que tus visitantes realmente ven.

El principio es simple: nada se edita directamente en el sitio en producción. Cada cambio tiene que ganarse el paso a producción funcionando primero en staging. Es la mitad operativa del mismo pensamiento de «más difícil de romper» que hay detrás de nuestro sistema de componentes con barandillas y nuestro framework propio de WordPress.

Por qué desplegamos en días programados, no cuando sea

Los buenos equipos despliegan cambios en el sitio en producción en días programados en lugar de en momentos aleatorios, porque las ventanas de publicación predecibles hacen que los problemas sean más fáciles de detectar, contener y revertir.

En la práctica, eso significa que los despliegues van a producción en días establecidos — en nuestro caso, de martes a jueves — deliberadamente no en viernes ni durante el fin de semana, cuando un problema podría quedar sin detectar sin nadie disponible para solucionarlo. Las ventanas programadas significan que un humano está mirando cuando un cambio entra en producción, los cambios relacionados se agrupan y validan juntos, y siempre hay tiempo para responder si algo parece incorrecto. Cambia un poco de inmediatez por mucha seguridad, que es el intercambio correcto para un sitio del que depende tu negocio. Las correcciones de seguridad genuinamente urgentes son la excepción — esas se gestionan bajo el estándar de soporte (SLA).

Las redes de seguridad: copias de seguridad y rollback

Incluso con las pruebas, la buena práctica asume que algo podría escaparse — por eso una configuración adecuada mantiene copias de seguridad diarias y control de versiones, lo que significa que cualquier cambio se puede deshacer y el sitio se puede restaurar rápidamente.

Hay dos redes. Las copias de seguridad diarias de tu código, archivos y base de datos significan que siempre hay una copia reciente y limpia desde la que restaurar si algo va mal — o si el sitio es alguna vez comprometido. El control de versiones significa que cada cambio está rastreado y es reversible: si un despliegue causa un problema, se vuelve a la última versión que funcionaba en lugar de intentar deshacerlo manualmente. Juntos, convierten «rompimos algo» de una crisis en una corrección rápida y tranquila.

Por qué esto es invisible hasta que te salva

Un pipeline de despliegue es invisible cuando funciona — solo notas realmente su valor el día en que un cambio malo se detecta en staging en lugar de llegar a tus clientes.

Esa es la parte silenciosamente importante. Cuando todo va bien, un pipeline puede parecer sobrecarga: ¿por qué no hacer el cambio y seguir adelante? Lo aprecias el día en que una actualización habría roto tu formulario de contacto y no lo hizo, porque se detectó y corrigió primero en staging. Para una empresa financiera o jurídica, eso es la diferencia entre un no-evento y una caída en medio de una presentación o una campaña.

Así es como se gestiona cada sitio en Agile One — nuestra suscripción web premium: los cambios fluyen desde el desarrollo al staging, se validan y luego se despliegan a producción en días programados — con control de versiones y copias de seguridad diarias — con la misma disciplina de desarrollo WordPress detrás de cada actualización. Está incluido en los 500 £ al mes, sin permanencia, y es gran parte de por qué un sitio gestionado se mantiene estable en lugar de romperse poco a poco.

Preguntas frecuentes

¿Cansado de que las actualizaciones rompan tu sitio en producción? Descubre cómo desplegamos →