Si te imaginas un diagrama de Venn, los entornos staging de Kinsta convergerían tanto con el desarrollo para WordPress como con tu ciclo de vida DevOps elegido. Pueden formar parte de tu flujo de trabajo desde la planificación inicial hasta la fase de operaciones. Esto incluye trabajar localmente con WordPress, utilizar el control de versiones y casi cualquier otra tarea que tengas durante un ciclo.
En este artículo, vamos a centrarnos en el desarrollo de sitios junto con los entornos staging de Kinsta. A lo largo de todo el artículo, lo relacionaremos con un ciclo de vida DevOps típico. Hay mucho por hacer, así que empecemos con las razones por las que creemos que deberías utilizar los entornos staging que ofrece Kinsta.
Las ventajas de utilizar los entornos staging de Kinsta
El Staging de Kinsta te ofrece versatilidad y flexibilidad a la hora de desarrollar tu sitio web y probarlo. Estos entornos te permiten desarrollar en un ambiente que refleja tu entorno real. Dado que tu servidor en producción también estará en Kinsta, es un terreno de pruebas fiable y preciso desde el que trabajar.
Por supuesto, puedes crear, gestionar, clonar y eliminar entornos staging a través del panel de control de MyKinsta:
Si necesitas más flexibilidad, el add-on de entorno staging premium te ofrece cinco entornos adicionales. Además, te beneficiarás de nuestra sólida infraestructura, que incluye la Red de Nivel Premium de Google y la integración con Cloudflare.
Como era de esperar, también incluye más potencia oculta. Dependiendo de tu plan, dispondrás de hasta 12 CPUs y 8 GB de memoria, un número de PHP Worker similar al de tu sitio activo y la opción de activar la CDN de Kinsta para mejorar el rendimiento. Es una configuración que se adapta a toda una serie de tareas, como pruebas A/B, comprobaciones de compatibilidad de plugins, pruebas que consumen muchos recursos y mucho más.
Para el desarrollo local, DevKinsta complementa toda la experiencia. Una vez superadas las fases iniciales, puedes enviar tu sitio directamente a los entornos staging de Kinsta.
En general, puedes crear, construir, diseñar, probar y depurar todo dentro del ecosistema de Kinsta. Es más, también se adapta a tu ciclo de vida DevOps. Hablaremos de esto con más detalle próximamente. Sin embargo, ofrezcamos primero alguna información adicional sobre los entornos staging de Kinsta.
Algunos detalles sobre el staging de Kinsta
Los entornos staging de Kinsta son excelentes cuando se trata de probar un sitio en un servidor activo — aunque no de producción. Sin embargo, hay algunas diferencias entre staging y en producción en Kinsta que te conviene conocer:
- En primer lugar, desactivamos por defecto tanto la caché de página completa como el OPcache. Puedes activarlos si lo deseas, pero sin ellos, es probable que los tiempos de carga de las páginas sean mayores.
- Del mismo modo, la indexación del sitio también está desactivada en WordPress. Aunque puedes volver a habilitarlo si lo necesitas, un aspecto que no puedes desactivar son nuestros encabezados restrictivos de indexación de URL temporales.
- Los Cron jobs tampoco se ejecutarán mientras estés en staging, aunque sigan «en su sitio» Esto significa que puedes realizar cambios en ellos, que sustituirán a los cron jobs de tu sitio activo una vez que los pongas en funcionamiento. Sin embargo, mientras estén en staging no se ejecutarán.
- Además, ten en cuenta que tus credenciales de inicio de sesión de WordPress serán las mismas para tu sitio staging que para tu sitio en producción.
Hay un aspecto más en el que queremos centrarnos rápidamente antes de pasar al flujo de trabajo: cómo interactúan los plugins con el staging.
Uso de plugins en los entornos staging de Kinsta
Por motivos de seguridad y rendimiento, Kinsta ya prohíbe la instalación de algunos plugins en WordPress. Sin embargo, cuando se trata de staging, también deberás desactivar algunos de los plugins de tu sitio.
Hay tres situaciones en las que deberás tenerlo en cuenta:
- Si la licencia de tu plugin está vinculada a tu nombre de dominio, puede que no funcione en tu entorno staging.
- Plugins como Jetpack cambiarán a un modo staging de forma automática. Puede que no veas ninguna diferencia, aunque ninguno de los datos que proceses irá a WordPress.com. Además, no podrás desactivar Jetpack en staging.
- Algunos plugins conectan y publican en las redes sociales, como CoSchedule. En estos casos, te recomendamos que los desactives hasta que empieces a publicar. Esto se debe a que pueden programar y publicar URLs desde tu entorno staging.
Tenemos más información sobre esto (y mucho más) en nuestra documentación. Si quieres utilizar los entornos staging de Kinsta y, al mismo tiempo, minimizar los efectos relacionados con tus plugins y temas, es una lectura esencial.
Un flujo de trabajo de desarrollo típico utilizando los entornos staging de Kinsta
Es probable que ya tengas un flujo de trabajo típico para el desarrollo. Utilizando los entornos staging de Kinsta, puedes integrar tu ciclo de vida DevOps para la Integración Continua/Despliegue Continuo (CI/CD) de forma fluida.
De hecho, el proceso comienza con un entorno local para el desarrollo. El proceso de configuración no lleva tiempo y también se encarga de crear una base de datos MariaDB.
DevKinsta también es ideal para proyectos de WordPress headless. Aunque aquí WordPress se asemeja a una Interfaz de Programación de Aplicaciones (API) de contenido, puedes seguir construyendo el front-end utilizando un framework JavaScript como React o Vue.js.
Cuando llegue el momento de enviar a staging, DevKinsta se encargará del back-end de la forma habitual. Para el front end, podrás desplegarlo en el Alojamiento de Sitios Estáticos de Kinsta o en nuestro Alojamiento de Aplicaciones.
Así es como podría ser el resto de un flujo de trabajo típico:
- Enviar al entorno staging. Una vez que hayas completado el desarrollo local y las pruebas preliminares, deberás pasarlas al entorno staging. Esta réplica de producción garantiza que tus pruebas produzcan resultados similares a los de tu sitio en producción. Es un paso crucial en tu proceso CI/CD, ya que puedes implementar pruebas automatizadas y garantizar la calidad antes de desplegar.
- Pruebas y depuración. Seguramente quieras realizar más pruebas dentro de Staging, como pruebas de rendimiento, análisis de seguridad y Pruebas de Aceptación de Usuario (UAT, User Acceptance Testing). Como Kinsta aísla los entornos de staging y en producción, estas pruebas no afectarán al sitio en producción. Utilizando las herramientas de registro y de Monitorización del Rendimiento de las Aplicaciones (APM) de Kinsta, también puedes depurar aquí cualquier problema.
- Integración y despliegue continuos. Tras la fase de pruebas y las aprobaciones finales, tendrás que integrar los cambios en el entorno en producción. Puedes automatizar aspectos de este proceso según tu flujo de trabajo CD/CI. De este modo, tu control de versiones central se mantendrá actualizado y podrás desplegar el código en producción con una intervención mínima.
- Supervisión y feedback. Tras el despliegue, es crucial identificar y rectificar cualquier problema mediante un bucle continuo de feedback y supervisión. El APM de Kinsta puede ayudarte a abordar cualquier problema posterior al despliegue. A partir de aquí, puedes llevar a cabo una mejora continua con los conocimientos y datos que obtengas.
En general, los entornos staging de Kinsta (y DevKinsta) proporcionan una infraestructura robusta para ayudar a agilizar tu flujo de trabajo de desarrollo. Incluso es compatible con aplicaciones WordPress headless. En la siguiente sección, veremos cómo puedes utilizar tus habilidades DevOps existentes en combinación con nuestro staging.
Aplicar técnicas DevOps al utilizar los entornos staging de Kinsta
Aplicar técnicas DevOps en los entornos staging de Kinsta puede mejorar significativamente la colaboración y agilizar el ciclo de vida del desarrollo. Esto es especialmente cierto para los equipos multifuncionales, ya que staging replica la producción lo más fielmente posible.
Esto permite a los desarrolladores, a los equipos de control de calidad (QA) y a otros trabajar juntos y sincronizados en las fases de construcción, prueba y despliegue. Como esto ocurre en un entorno controlado y aislado, ayuda a minimizar cualquier conflicto. También garantiza que puedas identificar y abordar cualquier problema en una fase temprana del proceso de desarrollo.
En esencia, DevOps pretende eliminar las barreras entre los equipos típicos y tradicionales «en silos», el desarrollo y las operaciones. Las prácticas que implementa fomentan una cultura colaborativa, automatizada e integradora.
Es más, las prácticas DevOps adecuadas pretenden mejorar la velocidad, eficacia y seguridad de tu desarrollo y despliegue.
Puedes ver esto en acción a lo largo de las distintas etapas del Ciclo de Vida DevOps. Hay entre cinco y siete, dependiendo de tu proyecto y equipo:
- Desarrollo. Esta etapa implica la planificación y la programación, junto con la elección de tu entorno staging. Aquí escribirás el código, lo probarás y controlarás las versiones (probablemente con Git) antes de pasar a la siguiente etapa.
- Integración. Aquí fusionarás los cambios de código en un repositorio central y te asegurarás de que estas nuevas adiciones no rompan tu sitio.
- Pruebas. A continuación automatizarás las pruebas para que se ejecuten en el entorno staging. Esto te proporciona una segunda capa para garantizar un código sin errores y de calidad.
- Despliegue. Después de validar tu código staging, puedes automatizar el despliegue en producción. Esto garantiza que tu sitio se ejecute siempre con la última versión.
- Monitorización. Tras el despliegue, deberás controlar el rendimiento de tu sitio. Aquí es donde un sistema y un proceso de alerta sólidos ofrecerán valor. Los datos que recopiles aquí también te ayudarán a cumplir en el futuro.
- Feedback. Se trata de una fase posterior al despliegue en la que recopilas información y datos de los usuarios — en este caso, los visitantes del sitio. Utilizarás los comentarios de esta fase para identificar áreas de mejora en el siguiente ciclo de desarrollo.
- Operaciones. Es probable que tengas algún solapamiento con un nuevo ciclo durante esta fase. Aquí es donde minimizas las interrupciones, trabajas para mejorar el tiempo de actividad y optimizas las configuraciones del servidor.
Dependiendo del número de pasos que tengas en tu propio Ciclo de Vida, algunos de ellos estarán en un orden diferente. Por ejemplo, tu fase de integración puede formar parte de tus fases de desarrollo o pruebas. Es más, puede que no tengas algunas de estas etapas, como una fase dedicada al feedback o a las operaciones.
Los entornos staging de Kinsta forman parte integral de la fase de desarrollo, ya que proporcionan un área segura y aislada para la programación, las pruebas y el control de calidad previos al despliegue. Integrar estos entornos en el ciclo de vida DevOps puede ayudar a tu colaboración, impulsar los plazos de entrega y mejorar la calidad de tus entregables.
A continuación, te mostraremos cómo crearlos a través del panel de MyKinsta.
Cómo configurar un entorno staging en Kinsta
No todos los alojamientos ofrecen esta funcionalidad, pero los entornos staging de Kinsta están disponibles en todos los planes que ofrecemos. Todo el proceso lleva un par de minutos y un mínimo de clics.
Es más, no necesitamos abordar aquí cada paso, ya que es algo que puedes encontrar en nuestra base de conocimientos. Sin embargo, en resumen, puedes comenzar la configuración a través de tu panel de MyKinsta:
Tu primera decisión será elegir un entorno de staging estándar o premium. Nuestro consejo es que comprendas lo vital que será el staging para tu sitio en producción. Por ejemplo, un entorno estándar probablemente te convenga si sólo necesitas probar elementos fuera de producción.
En cambio, un entorno premium será necesario si necesitas el mismo nivel y alcance de recursos que tu sitio en producción. También hay otras ventajas, como la posibilidad de configurar varios entornos de staging. Sin embargo, para los sitios que consumen muchos recursos (como las tiendas de comercio electrónico), tendrás que igualar los recursos de tu sitio en producción.
En la mayoría de los casos, es probable que quieras clonar tu sitio existente, que es una de las opciones que tienes después de elegir el tipo de entorno staging.
Si vienes de DevKinsta, puedes configurar un entorno en blanco aquí. Hay un botón dentro de la configuración de tu sitio en DevKinsta para enviar a staging. En cualquier caso, deberás esperar unos minutos para que tu entorno complete su configuración. A partir de ahí, puedes empezar a utilizar tus entornos staging de Kinsta para construir y probar tu sitio.
Dar a tu entorno staging de Kinsta una dirección de subdominio adecuada
En circunstancias normales, tu entorno staging de Kinsta vivirá en una subcarpeta de tu servidor. Tendrá una URL que es un subdominio de kinsta.cloud, pero esto puede causar un par de problemas:
- Algunos plugins no funcionarán, como los que necesitan verificar una licencia a través de un nombre de dominio específico.
- Ciertas configuraciones de WordPress Multisitio experimentan problemas con los subdirectorios en Kinsta o requieren un subdominio personalizado para funcionar de forma óptima.
Por ello, es una buena idea configurar una dirección de subdominio adecuada para tus entornos staging de Kinsta. Para los usuarios premium, Kinsta proporciona direcciones de subdominio dedicadas, pero incluso esto puede no resolver tus problemas.
La respuesta es configurar un dominio personalizado para tu sitio, y luego ejecutar el staging desde un subdominio utilizando el Sistema de Nombres de Dominio (DNS). Una URL de staging personalizada que utilice un dominio y un subdominio adecuados tiene dos ventajas: en primer lugar, puedes mitigar cualquiera de los problemas de los que hablamos. En segundo lugar, tienes un subdominio «más bonito» para compartir con colaboradores o clientes.
Pasar un sitio activo al entorno staging
Un aspecto de tu entorno staging que puede no estar claro al principio es cómo enviar tu sitio activo a él después de configurarlo. Una vez que entiendas que un entorno staging es simplemente una copia de tu sitio activo, será más fácil visualizarlo.
Sin embargo, aquí tienes un resumen rápido del flujo de trabajo para evitar cualquier duda:
- Cuando creas un entorno staging, básicamente copias tu sitio activo en un subdominio. Esto incluye todas tus bases de datos y archivos. Es una réplica completa uno a uno de tu sitio en producción.
- Realizas cambios en el entorno staging según tu ciclo de vida DevOps. Esto será subjetivo y estará relacionado con tu propio proyecto, flujo de trabajo y objetivos.
- A la hora de publicar esos cambios, tienes varias opciones. Puedes utilizar la funcionalidad Enviar a en Producción integrada en Kinsta o realizar cambios manuales. De esto hablaremos con más detalle más adelante.
- A partir de aquí, volverás a tener una réplica exacta de tu sitio, tanto en el entorno de staging como en el real.
Como tal, no hay forma de actualizar tu entorno staging en función del estado de tu sitio activo. Nuestra recomendación es que borres tu entorno staging y lo reconstruyas cuando vuelvas a necesitarlo, ya que así copiarás tu sitio actual. Esta es otra buena razón para utilizar una dirección de subdominio personalizada para tus entornos staging de Kinsta.
Kinsta realiza copias de seguridad tanto de tu sitio activo como del entorno staging. Esto significa que también puedes restaurar una copia de seguridad del sitio activo directamente en el entorno staging. Con esto, consigues una forma de transición entre las fases de tu Ciclo de Vida con mayor facilidad y puedes utilizar permutaciones anteriores de tu sitio durante el desarrollo.
Ten en cuenta que primero tendrás que configurar tu entorno staging, pero puedes restaurar a entornos estándar o premium. En cualquier caso, puedes hacerlo a través del panel de control de MyKinsta:
Esto te llevará un par de clics y también conservará las copias de seguridad existentes para tus sitios en producción y staging, junto con cualquier dominio personalizado que hayas configurado.
Incorporar el control de versiones a tu configuración staging
Muchos desarrolladores utilizan el control de versiones, como Git, que recomendamos. Tanto los entornos activos como los staging en Kinsta ofrecen integración con Git, lo que significa que puedes controlar las versiones de tu sitio staging para mantenerte al día con tu programa de desarrollo.
Extraer y clonar un repositorio en el servidor de Kinsta debería ser pan comido. El proceso consta de unos pocos pasos básicos:
- Conéctate a tu sitio utilizando Secure Shell (SSH).
- Extrae tu repositorio actual de GitHub, GitLab u otro servicio similar.
- Alternativamente, clona tu repositorio desde tu ubicación remota.
La forma de extraer tu repositorio remoto será diferente dependiendo de si es público, privado o tiene Autenticación de Dos Factores (2FA, Two-Factor Authentication). Sin embargo, a la hora de enviar tu código al repositorio remoto, tendrás que encontrar un flujo de trabajo adecuado.
Esto se debe a que los entornos staging de Kinsta y la integración con Git aún no admiten un comando como git push kinsta mysite. Aún así, existen soluciones. Por ejemplo, puedes utilizar una herramienta como WP Pusher:
Los desarrolladores más ingeniosos también están encontrando formas únicas de enviar a GitHub desde Kinsta, aunque sea ejecutando un simple comando desde un cliente Git o automatizando el proceso con scripts. Tendremos más información sobre el concepto general de enviar tu código al sitio activo más adelante.
Realizar pruebas de rendimiento en los entornos staging de Kinsta
Una parte de las fases del ciclo de vida de pruebas y monitorización incluye observar (y comparar) el rendimiento de tu sitio staging con puntos de referencia. La buena noticia es que tienes acceso a todas las herramientas de Kinsta para tu sitio staging, así como para el sitio activo.
En resumen, obtendrás puntos de referencia para tu sitio activo, crearás objetivos que te gustaría alcanzar y optimizarás tu código dentro del sitio staging. A partir de ahí, evaluarás si esos cambios marcan alguna diferencia positiva. Si es así, puedes avanzar. Si no, seguirás con los pasos de programación y pruebas.
Para los entornos staging de Kinsta, es probable que la herramienta APM de Kinsta sea una referencia central:
Se trata de una herramienta personalizada que se centra en los problemas de WordPress y marca el tiempo de toda la actividad que recopila. Puedes monitorizar procesos PHP, tus llamadas HTTP, consultas a bases de datos y mucho más. Por ejemplo, descubrimos que la mayoría de los problemas de degradación del rendimiento se deben a un plugin o tema no óptimo. Kinsta APM puede mostrarte esto con detalle explícito en la pestaña WordPress.
Verás que es posible profundizar en las transacciones individuales, lo que significa que puedes ver con precisión dónde están tus cuellos de botella. En el caso de los sitios staging, a menudo no controlarás el tiempo de transacción de Redis. En su lugar, serán de mayor interés los tiempos de PHP y MySQL.
Utilizar un periodo de tiempo absoluto para solucionar los problemas te ayudará a identificar las áreas problemáticas. La documentación de Kinsta te guía a través del flujo de trabajo general, pero en pocas palabras, la carga lenta de las páginas debería ser tu primera preocupación.
A partir de ahí, puedes indagar en los procesos que componen esas transacciones y erradicar el código menos eficiente o las herramientas de terceros deficientes. Es probable que utilices una mezcla de herramientas para cazar y combatir el código problemático. Para el desarrollo de WordPress, WP_DEBUG y Query Monitor son habituales.
Despliegue continuo: sincronizar los cambios entre staging y producción
La fase de despliegue de tu Ciclo de Vida significa que tendrás que tomar una decisión: qué código enviar. Puede que lo primero que pienses sea desplegarlo todo a la vez, pero no siempre es la mejor idea.
Esto se debe a que, independientemente de lo similares que sean tus entornos de staging y en producción, seguirán teniendo diferencias. Un enfoque medido puede ser más sensato, ya que puedes insertar un conjunto de código para una mejora específica, supervisar los cambios y programar la siguiente inserción.
Este concepto es fundamental para el despliegue continuo, ya que el despliegue seguro debe ser una preocupación clave. En el pasado, la funcionalidad «push-to-live (enviar-a-producción)» de Kinsta con un solo clic enviaba todo tu sitio a tu servidor «en producción», independientemente de tus cambios. Sin embargo, ahora también tienes opciones de envío selectivo: enviar tus archivos, tu base de datos o ambos al servidor activo:
Incluso así, esto incluye también la configuración de tu entorno, como las configuraciones de Nginx, PHP y las redirecciones. Esto aún puede ser excesivo, especialmente cuando sólo haces cambios pequeños o menores en una parte específica de tu sitio.
Por supuesto, también tienes la opción de renunciar a las opciones push-to-live (enviar-a-producción) de Kinsta y realizar el trabajo tú mismo. Lo más seguro es replicar los cambios en el sitio en producción en lugar de automatizarlos. Claro que te llevará más tiempo implementarlos, pero tienes la posibilidad de controlar cada cambio a medida que se aplica.
Sin embargo, sea cual sea tu enfoque del despliegue continuo, tus copias de seguridad serán un componente vital. Kinsta hace copias de seguridad todos los días de cada sitio de tu cuenta. Esto incluye las copias de seguridad que genera el sistema y también tus copias de seguridad manuales.
Es más, cada copia de seguridad es una instantánea completa de un entorno específico. Esto significa que puedes volver a una configuración de trabajo conocida en cuestión de minutos si necesitas arreglar un sitio roto.
Resumen
Los entornos staging de Kinsta pueden ayudarte a crear, probar y desplegar tu sitio en producción, independientemente del número de fases que ejecutes o de la naturaleza de cada paso de tu flujo de trabajo. Son muy flexibles, ya que puedes utilizar el entorno de staging estándar gratuito en todos los sitios que gestiones con Kinsta.
Sin embargo, con un entorno staging premium, puedes configurar múltiples instancias, ejecutar recursos que coincidan con tu sitio en producción, y mucho más. Los entornos staging de Kinsta también son excelentes cuando se utilizan junto con nuestro alojamiento de aplicaciones. De cualquier forma, puedes llevar tu sitio de local a en producción y disfrutar de acceso a todas las herramientas típicas de Kinsta directamente desde el panel MyKinsta.
¿Tienes alguna pregunta sobre el uso de los entornos staging de Kinsta junto con tus técnicas habituales de DevOps? ¡Danos tu opinión en la sección de comentarios más abajo!
Deja una respuesta