Los sitios de WordPress que se alojan en una infraestructura rápida pueden seguir teniendo problemas de fiabilidad, sobre todo porque esa infraestructura solo determina la rapidez con la que se cargan las páginas. Es el “proceso de gestión del cambio” de la empresa el que determina si el sitio sigue funcionando después de que alguien actualice un plugin, implemente un rediseño o actualice la versión de PHP.
Por eso, el proceso de control, prueba, aprobación y recuperación tras los cambios en un entorno de producción es uno de los principales criterios que tienen en cuenta los equipos empresariales a la hora de evaluar las plataformas de alojamiento.
Una plataforma que no permite llevar a cabo un proceso de cambio estructurado obliga a los equipos a crear sus propios controles en torno a ella: copias de seguridad manuales previas a la actualización que se envían a través del chat, pasos de aprobación informales y soluciones de emergencia tras el despliegue que apartan a los ingenieros de su trabajo en el proyecto de forma recurrente.
Por qué el riesgo de cambio es la principal preocupación empresarial
El alcance de los cambios que requiere un entorno de WordPress a lo largo de su ciclo de vida es mayor de lo que parece a primera vista. Por ejemplo:
- Los lanzamientos del Core de WordPress suelen seguir un calendario fijo.
- En una instalación compleja, las actualizaciones de los plugins pueden llegar a ser de varias docenas al mes.
- Las actualizaciones de la versión de PHP afectan a todo el entorno de ejecución.
- Los cambios en el esquema de la base de datos se producen con las versiones principales de los plugins y pueden entrar en conflicto con las personalizaciones basadas en la estructura anterior.
En las empresas en las que WordPress sustenta un portal de clientes, un flujo de trabajo de contenidos fundamental para el cumplimiento normativo o una plataforma de comercio electrónico de gran volumen de ingresos, cada cambio interactúa con numerosas dependencias que no siempre están documentadas. Pero, cuando se producen fallos, la causa suele ser un despliegue que se lleva a cabo sin un proceso de pruebas fiable, más que la propia infraestructura.
Si un proveedor de alojamiento no cuenta con entornos staging formalizados, rutas de rollback o controles de acceso, la responsabilidad de crearlos recae en tu equipo. Por eso, las preguntas clave son si el despliegue es predecible y, en consecuencia, si la recuperación es rápida.
Cómo los entornos staging crean una vía segura para realizar pruebas antes de pasar a producción
MyKinsta te ofrece las herramientas necesarias para que un proceso de cambios bien organizado sea la norma y no una carga adicional, gracias a entornos staging, envíos selectivos, copias de seguridad por capas y controles de acceso basados en roles.
Todos los planes de Kinsta incluyen un entorno staging estándar gratuito y contenedorizado por sitio web. Para crear uno, ve a Sitios, selecciona el sitio que quieras poner en staging, haz clic en el selector de entornos (por ejemplo, En producción) y elige Crear nuevo entorno. Puedes clonar el entorno de producción existente, instalar una instancia de WordPress en blanco o crear un entorno vacío para una configuración personalizada.
El add-on de staging premium de Kinsta te ofrece hasta cinco entornos staging premium por sitio web, además del entorno estándar gratuito que viene incluido en todos los planes. Es ideal si gestionas flujos de desarrollo en paralelo, necesitas probar funcionalidades que consumen muchos recursos o trabajas con condiciones que deben coincidir con las de producción. Vale la pena que conozcas las diferencias entre los dos tipos de entornos a la hora de definir tu flujo de trabajo:
- El entorno staging estándar siempre se ejecuta en una sola CPU y tiene una asignación fija de RAM. La caché del servidor está disponible sin necesidad de una CDN ni de compatibilidad con edge caching. Es ideal para actualizaciones de plugins, revisiones de diseño y pruebas del flujo de trabajo de contenidos.
- El entorno staging Premium se adapta al perfil de tu contenedor en producción y te ofrece tanto disponibilidad de CDN como compatibilidad con edge caching. Lo usas cuando las pruebas implican configuraciones de mucho tráfico, integraciones con WooCommerce o comportamientos que solo se detectan bajo cargas a escala de producción.
En el caso de las actualizaciones de plugins o temas, tu flujo de trabajo en el entorno staging debería incluir ejecutar la actualización, comprobar todos los puntos de integración a los que pueda afectar, obtener la aprobación de las personas implicadas y, solo entonces, preparar el envío a producción. Es fácil de aplicar cuando los entornos de staging y de producción están separados.
Itineris, cliente de Kinsta, basa los flujos de trabajo de sus clientes empresariales en la infraestructura staging de Kinsta:
Los entornos staging, las copias de seguridad automatizadas y una infraestructura robusta fueron esenciales para optimizar nuestros flujos de trabajo y mejorar el rendimiento del sitio.
Cómo los envíos selectivos controlan el alcance de cada despliegue
El entorno staging elimina los riesgos de la fase de pruebas, pero pasar todo el entorno de staging a producción conlleva otro tipo de riesgo. Ahora, se sustituyen todos los archivos y todas las tablas de la base de datos, incluidos los cambios que no forman parte del despliegue previsto (como el contenido de prueba).
La función de envío selectivo de Kinsta te permite controlar exactamente qué se traslada del entorno staging a producción. Para usarla, selecciona tu entorno staging en MyKinsta, haz clic en Enviar entorno y elige un alcance de despliegue:
- Archivos. Esto transfiere temas, plugins y cambios en el código, dejando intacta la base de datos de producción. Úsalo cuando la base de datos de staging no esté sincronizada con los datos de producción, o cuando el cambio solo afecte al código.
- Base de datos. Aquí puedes aplicar los cambios en la base de datos sin modificar los archivos de producción. Úsalo para cambios estructurales, como actualizaciones de tipos de entrada personalizados o configuraciones de plugins almacenadas en la base de datos.
También tienes menús desplegables para ajustar aún más el envío. Por ejemplo, puedes elegir seleccionar archivos, carpetas o tablas de bases de datos concretos.
Antes de cada envío a un entorno de producción, Kinsta crea automáticamente una copia de seguridad generada por el sistema del entorno de producción que captura el estado justo antes del despliegue. Está disponible como punto de restauración en cuanto se completa el envío. Si el envío da un resultado inesperado, el rollback se hace con una sola operación en MyKinsta, en lugar de tener que reconstruir todo a partir de una copia de seguridad..
El paso de buscar y reemplazar
Si el despliegue implica un cambio en la estructura de las URLs o un cambio de dominio, la base de datos contendrá referencias a la URL del entorno staging. La herramienta de buscar y reemplazar de MyKinsta te permite actualizar ese tipo de cambios.
Ten en cuenta que la opción Buscar y reemplazar del cuadro de diálogo Enviar a producción solo funciona en la base de datos, así que tendrás que dar un paso más para los archivos y las carpetas. Para ello, ve a la pantalla Herramientas de MyKinsta para tu sitio y busca la herramienta Buscar y reemplazar.
Aquí, introduce la URL de staging en el campo Buscar y la URL de producción en el campo Reemplazar por. En cuanto hagas clic en Reemplazar, MyKinsta ejecutará una copia de seguridad generada por el sistema y, a continuación, llevará a cabo la operación de buscar y reemplazar.
En resumen, el envío selectivo, las copias de seguridad previas al envío y un paso específico de buscar y reemplazar convierten el proceso de staging en un proceso con puntos de control obligatorios en cada etapa.
Cómo las copias de seguridad por capas reducen las consecuencias de un cambio fallido
Aunque tengas un entorno staging y un flujo de trabajo de envío selectivo, algunos cambios pueden provocar fallos impredecibles. Por ejemplo, una API de terceros puede comportarse de forma diferente cuando se usan credenciales de producción que cuando se usan las de staging.
Las copias de seguridad pueden ayudarte a minimizar los daños cuando esto ocurra. Si tienes un sitio en MyKinsta, ve a la pantalla Copias de seguridad para acceder a todas ellas:
Kinsta cubre todas las fases del ciclo de despliegue con cuatro tipos de copias de seguridad:
- Las copias de seguridad diarias se ejecutan automáticamente y se conservan entre 14 y 30 días, dependiendo de tu plan. Cada copia de seguridad es una instantánea completa de tu sitio.
- Las copias de seguridad generadas por el sistema se activan automáticamente antes de operaciones clave, como pasar el entorno de staging a producción, aplicar una actualización de un plugin o tema, restaurar una copia de seguridad, realizar operaciones de buscar y reemplazar, y restablecer un sitio. Siempre se crean puntos de restauración antes de que se ejecute automáticamente una operación.
- Las copias de seguridad manuales te permiten crear hasta cinco instantáneas etiquetadas adicionales en cualquier momento desde la pestaña Manual (el número disponible depende de tu plan). Estas instantáneas cubren operaciones que no entran dentro de la programación automática, como una actualización de la versión de PHP o una migración de la base de datos que estés realizando a través de WP-CLI.
- Las copias de seguridad cada hora están disponibles como add-on de pago en dos niveles: copias de seguridad cada 6 horas y copias de seguridad reales cada hora. Echa un vistazo a la página de add-ons para ver los precios actuales.
Si haces clic en el botón Restaurar a de una copia de seguridad y luego eliges el entorno de destino, podrás volver a ese punto concreto de la copia de seguridad. Cuando se complete la restauración, MyKinsta generará una nueva copia de seguridad del sistema que reflejará el estado justo antes de que se ejecutara la restauración.
Crear un proceso de gestión del cambio en torno a este tipo de funcionalidad reduce las ventanas de mantenimiento programadas y los rollbacks formales a un único flujo de trabajo ejecutable dentro de MyKinsta. Por ejemplo, Konica Minolta migró su sitio web de marketing a WordPress en Kinsta en tres meses e identificó la fiabilidad del despliegue como la base del proyecto:
Nuestra mayor preocupación era el tiempo de inactividad y la pérdida de rendimiento durante la migración, pero el equipo de Kinsta lo gestionó todo a la perfección, sin ninguna interrupción.
Cómo el acceso basado en roles garantiza el proceso de cambio en todos los equipos
El despliegue en una empresa suele implicar a varias partes interesadas con diferentes responsabilidades en cada fase del proceso de cambio.
Por ejemplo, los desarrolladores necesitan acceder al entorno staging para crear y probar los cambios, mientras que los ingenieros de control de calidad tienen que validar esos cambios. Más adelante, los jefes de proyecto necesitan saber qué hay en staging sin poder pasarlo a producción, y los revisores del lado del cliente tienen que aprobar el estado de staging.
El modelo de acceso y la gestión de usuarios de Kinsta te permiten definir y aplicar seis roles, aunque para la gestión del cambio en el ámbito empresarial, hay tres que son más relevantes:
- Los desarrolladores de la empresa pueden gestionar todos los sitios y entornos staging, acceder al DNS, ver estadísticas y pasar el entorno de staging al entorno de producción. No pueden acceder a los datos de facturación, aprobar migraciones ni añadir o eliminar add-ons de pago. Este rol es ideal para desarrolladores internos y jefes técnicos con plena autoridad para realizar el despliegue.
- Los administradores del sitio tienen control total sobre un sitio concreto y todos sus entornos. Sin embargo, no pueden eliminar un sitio de la cuenta de la empresa ni crear ni borrar entornos staging premium. Este rol es ideal para los responsables técnicos a cargo de un sitio concreto.
- Los desarrolladores de sitios web tienen acceso a todos los entornos staging de los sitios que se les han asignado, pero no pueden pasar los cambios de los entornos de staging a producción. Tanto si eres un colaborador externo que trabaja en una funcionalidad de desarrollo como si eres un ingeniero de control de calidad que valida una versión candidata, este rol te da acceso a la parte del flujo de trabajo que requiere tu puesto.
MyKinsta te facilita mucho invitar a un usuario a través de la página Configuración de la empresa > Usuarios. Aquí, el botón Invitar usuarios te permite introducir su dirección de correo electrónico y elegir si quieres concederle acceso a nivel de empresa o a nivel de sitio.
Centralización del acceso con SSO mediante SAML
Si eres una empresa que gestiona el acceso a varias herramientas desde un proveedor de identidades central, Kinsta soporta el SSO SAML con cualquier proveedor de identidades (IdP) que utilice el estándar SAML. Entre ellos se incluyen Microsoft Entra ID, Okta, Google Workspace y muchos otros.
Para activarlo, ve a Configuración de la empresa > Inicio de sesión único en MyKinsta y haz clic en Activar. A continuación, configura la aplicación SAML en tu IdP utilizando los datos de conexión que te proporciona MyKinsta y, después, vuelve a MyKinsta para completar la configuración con la URL de SSO, el ID de entidad y el certificado público de tu IdP.
Una vez activado, el usuario se identifica a través de tu IdP usando las credenciales de la empresa que ya tiene. Al activar el SSO obligatorio, se evita que los usuarios se salten el IdP iniciando sesión directamente. Cuando alguien deja la organización, al revocar su acceso en el IdP, este se elimina al mismo tiempo de MyKinsta, siguiendo el mismo proceso que se usa para el resto de herramientas del stack.
Por último, la autenticación de dos factores (2FA) es obligatoria por defecto para todas las cuentas que no estén incluidas en el SSO SAML. El propietario de la empresa puede ver el método de 2FA de cada usuario en la pantalla Configuración de la empresa > Usuarios > 2FA.
La gestión del cambio es la clave para que WordPress a nivel empresarial se adapte de forma segura
Para las grandes empresas, la plataforma de alojamiento es la infraestructura que determina con qué seguridad se puede modificar un entorno de WordPress, no solo lo rápido que funciona. Lo que diferencia a las plataformas en el nivel de alojamiento administrado es si un equipo puede realizar el despliegue de una actualización de WordPress contando con un plan de recuperación fiable si algo sale mal.
Los entornos staging de Kinsta, la función de envío selectivo, el sistema de copias de seguridad por capas y los controles de acceso basados en roles ofrecen a los equipos empresariales las herramientas necesarias para llevar a cabo un flujo de trabajo de cambios bien organizado sin tener que encargarse ellos mismos de esos controles.
Para ver cómo se aplica esto a tu organización, echa un vistazo a las opciones de alojamiento para WordPress para empresas de Kinsta y descubre si necesitas revisar tu proceso actual de gestión de cambios.
