Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress
Code

Cómo automatizar y optimizar su desarrollo de WordPress y pruebas en Pantheon

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called How to Use Pantheon to Set Up and Maintain a Production-Safe WordPress Site.
How to Use Pantheon to Set Up and Maintain a Production-Safe WordPress Site
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

En mi tutorial anterior, te guié a través de los pasos de empezar a crear y mantener un sitio seguro de producción de WordPress utilizando una configuración de tres ambientes "Dev-Test-Live" en Pantheon. En esta configuración, siempre actualiza el código en un entorno de desarrollo, luego lo prueba en un entorno de prueba y, una vez que todo se vea bien, póngalo al servidor de produccion.

Si bien esto es una mejora significativa en comparación con la ejecución de una instalación de WordPress único entorno y la carga de sus cambios directamente al servidor de producción, ¡podemos hacerlo mejor!

"Pedir a los expertos que hagan tareas aburridas y repetitivas, y sin embargo técnicamente exigentes, es la forma más segura de asegurar el error humano que podemos pensar, a falta de privación de sueño o embriaguez".

Esta cita de David Farley resume el problema con nuestra configuración actual: mientras que tener tres entornos y un proceso para usarlos ayuda, todavía estamos haciendo todo el trabajo manualmente, lo que fácilmente puede conducir a errores.

En este tutorial, para ayudar a eliminar este problema en la medida de lo posible, primero le mostraré cómo puede realizar algunas de las tareas repetitivas más rápidamente utilizando las herramientas de línea de comandos de Pantheon y luego examinaremos la automatización. Más concretamente, examinaremos la automatización de sus pruebas de aceptación utilizando un servidor de integración continua y el marco de pruebas de Behat.

Después de completar el tutorial, tendrá una sólida comprensión de los principios de desarrollo y creación de un sitio fiable y fácil de mantener WordPress en Pantheon. También estará equipado con muchas ideas sobre cómo hacer que su configuración sea aún mejor, una pequeña mejora a la vez.

¡Empecemos!

1. Utilizar la herramienta de línea de comandos Terminus para controlar el sitio Pantheon

Mientras que Panthéon Web Dashboard le da una presentación visual clara de lo que está sucediendo en sus tres servidores y grandes herramientas para su gestión, hay momentos en que usted prefiere una herramienta de línea de comandos en su lugar.

Podría ser para ahorrar tiempo: cuando usted trabaja en su sitio, pronto notará que el tiempo dedicado a una tarea simple pero repetitiva—como comprometer sus cambios o desplegarlos en el entorno de prueba—se acumula y se convierte en una parte importante de Lo que haces todos los días O podría ser sólo porque te gusta trabajar en la línea de comandos. O tal vez desee crear un script que agrupe varias acciones como el envío de su código, implementarlo en Test y borrar el caché en un comando.

La herramienta de línea de comandos del Pantheon, Terminus, te permite hacer todo esto—y más.

Paso 1: Instalar Terminus

Antes de comenzar a usar Terminus, deberá instalarlo en su computadora.

Las instrucciones de instalación y uso presentadas en este tutorial son para un sistema basado en Unix (como Mac OS X o Linux). Si está en Windows, los comandos son un poco diferentes: consulte las instrucciones de instalación oficiales de Terminus para obtener más información.

Terminus tiene los siguientes requisitos del sistema, así que asegúrese de tenerlos instalados antes de continuar:

Aunque no es requerido por Terminus, recomiendo que también instale Composer para completar el tutorial. También estoy asumiendo que ya está utilizando Git como lo hemos hablado en el tutorial anterior.

Hay algunas formas diferentes de instalar Terminus (puede ver las instrucciones de instalación para más detalles), pero vamos a ir con una sencilla que no requiere muchas herramientas adicionales para ejecutar.

En la consola, escriba:

El comando instala Terminus en /usr/local/bin/terminus en su computadora.

Una vez finalizada la instalación, puede probarlo mediante el siguiente comando:

Uno de los pocos logos de arte ASCII debe aparecer. Aquí está el icono del puño de relámpago de Terminus, por ejemplo:

When you see the logo you know Terminus was installed successfully

Paso 2: Inicie sesión en Terminus

Antes de utilizar Terminus para gestionar su cuenta Pantheon y los sitios vinculados a el, deberá iniciar sesión.

Hay dos opciones para hacerlo: puede iniciar sesión con su contraseña y correo electrónico de Panteón o utilizar un token de máquina para identificar el equipo en el que inicia sesión.

Vamos a ir con el enfoque de token de máquina, ya que le da un nivel adicional de seguridad. Si su computadora se compromete y necesita deshabilitar el inicio de sesión para ella, puede revocar el token de la máquina y nadie podrá acceder a su cuenta desde ese equipo. Los tokens de máquina también son útiles si ejecuta Terminus en varias máquinas y scripts automatizados—por ejemplo en su servidor de integración continua.

Cada token de máquina que cree proporciona a los usuarios de la máquina el mismo acceso a su cuenta de Pantheon que tiene. Así que asegúrese de revocar las fichas que ya no utilice.

Para crear su primer token de máquina, inicie sesión en su cuenta de Pantheon. A continuación, en la pestaña Account, seleccione la opción de menú Machine Tokens.

Machine Tokens

Haga clic en Create token. Luego, en la siguiente pantalla, ingrese un nombre descriptivo y haga clic en Generate token.

Create New Token

A continuación, verá una ventana emergente que muestra el token recién creado junto con un comando para almacenarlo en Terminus en su computadora.

Your new machine token is ready

Copie el comando Terminus y ejecútelo en la línea de comandos.

Una vez que el comando termina, Terminus está listo para ser utilizado en su computadora.

¡Echemos un vistazo a lo que puedes hacer con él!

Paso 3: Una visión general de los comandos Terminus

En el resto del tutorial, utilizaremos comandos de Terminus aquí y allá cuando establezcamos pruebas automatizadas para su sitio de WordPress. Sin embargo, eso sólo raspará la superficie, así que antes, echemos un vistazo a algunos de los comandos y cómo puede aprender más sobre ellos.

De esta forma, una vez que haya completado el tutorial, tendrá indicadores que puede utilizar para obtener más información y mejorar aún más su flujo de trabajo para que coincida con sus preferencias.

Puede encontrar una lista actualizada de los comandos Terminus en Terminus Wiki.

La lista no incluye documentación para los comandos, por lo que cuando vea un comando que desee utilizar, utilice la herramienta Terminus para obtener más información al escribir:

Si omite <subcommand>, Terminus le mostrará la lista de subcomandos disponibles para el comando especificado.

Ahora, echemos un vistazo a algunos comandos útiles que puede utilizar para realizar acciones desde el tutorial anterior directamente en la línea de comandos.

Administrar sus sitios

Para ver una lista de todos sus sitios en Pantheon, escriba:

También hay comandos para crear un nuevo sitio (terminus sites create) e importar un sitio (terminus sites import) sin visitar el Panel. Estos pueden ser útiles si es una agencia y crea nuevos sitios a menudo. Para el resto de nosotros, el Panel de control hace su trabajo muy bien.

Un comando más útil si ejecuta muchos sitios es terminus sites mass-update, que puede utilizar para actualizar todos sus sitios de desarrollo con una actualización de upstream disponible (en nuestro caso, una nueva versión de WordPress).

Empujar e implementar sus cambios

La mayor parte del trabajo al desarrollar un nuevo sitio es escribir, implementar y probar código. Por lo tanto, si trabaja en modo Git o SFTP, va a hacerlo muchas veces. Es por eso que también es el área en la que se beneficiará más al utilizar la interfaz de línea de comandos en lugar de realizar todas las acciones a través del panel Web.

Estas acciones se agrupan bajo el comando site—puede ver una lista completa escribiendo:

Como aquí es donde tiene lugar la mayor parte de la acción en el Panteón, verás que hay muchos subcomandos. Tómese su tiempo para explorarlos mientras trabaja en su sitio, pero por ahora, veamos algunos de los más útiles.

Si está trabajando en modo SFTP, como lo hicimos durante la mayor parte del tutorial anterior, tendrá que confirmar los cambios en el control de versiones para almacenarlos y poder implementarlos en los entornos de prueba y en vivo.

Puede hacerlo a través de la CLI, utilizando el siguiente comando:

Reemplace <site> con el ID de su sitio (por ejemplo, tutorial-example-site) y <message> con un mensaje descriptivo de confirmación.

También puede utilizar el comando site code para otras funciones relacionadas con el control de versiones. Echa un vistazo a la página de ayuda del comando para obtener más información.

Una vez que haya confirmado los cambios (o los ha enviado directamente al control de versiones, si está en modo Git), puede implementarlos en Prueba  y Produccion con el comando site deploy:

Mediante este comando, puede implementar desde Dev a Test o Test a Live. Para especificar cuál de ellos está haciendo, establezca el atributo --env en el valor correcto (test o live). Al implementar en Test, también tiene la opción de clonar automáticamente los datos del entorno desde el entorno Live (--sync-content)—quitar el indicador si no desea sincronizar los datos. Si especifica el indicador --cc, Pantheon borrará el caché después del despliegue. Si desea agregar una nota de implementación, puede hacerlo usando el parámetro --note.

Para actualizar la descarga de un solo sitio (en nuestro caso, la instalación de WordPress base) a su última versión, puede utilizar el comando:

Seleccione cualquiera list para listar las actualizaciones o apply para que realmente se apliquen.

Además de estas acciones, puede utilizar el terminus site para hacer muchas otras cosas, como copias de seguridad de ejecución, borrar manualmente la caché, clonar contenido entre entornos y trabajar con entornos Multidev. Consulte la página de ayuda para obtener una lista completa de comandos y parámetros.

Cómo controlar el sitio de WordPress

Para los desarrolladores de WordPress como tú y yo, una gran parte del poder de Terminus reside en el hecho de que nos permite ejecutar comandos WP-CLI en el entorno de destino. De esta manera, puede, por ejemplo, instalar y actualizar complementos en los sitios de sus clientes sin visitar el tablero de WordPress en absoluto.

El comando para ejecutar un comando WP-CLI en su servidor dev de Pantheon es:

Así, por ejemplo, para empujar cambios de configuración de WP-CFM en Dev a Git y luego al entorno de prueba (un excelente ejemplo de una tarea repetitiva a la espera de ser automatizada) con Terminus, podría utilizar los siguientes comandos:

Reemplace tutorial-example-site con su id de sitio real y site_options con el id del paquete de opciones creado en WP-CFM.

A medida que continúe trabajando con Pantheon y Terminus, estoy seguro de que encontrará más y más formas de usar la interfaz de línea de comandos para acelerar y automatizar su trabajo.

Por lo tanto, ¡a seguir experimentando!

2. Comenzar con la prueba de su sitio WordPress

En el tutorial anterior, vio cómo puede utilizar el entorno de prueba para probar su código a fondo antes de que vaya al servidor de produccion para que todos lo puedan usar. Si bien es una gran idea, asegurarse de que ha comprobado todo es un montón de trabajo que implica listas de verificación y hacer clic en las cosas una y otra vez. En otras palabras, es un lugar muy probable para los resbalones.

¡Por eso es el paso perfecto en su proceso de automatización!

En el resto del tutorial, crearemos una configuración de prueba sencilla mediante la herramienta de prueba Behat y la haremos ejecutar automáticamente cada vez que implemente el código de Dev a Test en Pantheon. Para ello, usaremos una combinación de la herramienta en servidor de Pantheon Quicksilver y un servidor de integración continuo que se ejecuta en la nube.

Empezaremos por configurar las pruebas y hacerlas correr en su computadora.

Paso 1: Crear un nuevo proyecto para realizar sus pruebas de Behat

Behat es un framework de desarrollo basado en comportamiento de código abierto para PHP que le permite escribir casos de prueba para comprobar que la experiencia del usuario real coincide con lo que usted espera.

Comencemos configurando Behat en un nuevo directorio, el cual podemos desplegar posteriormente en el servidor de integración continua. Las pruebas de Behat se ejecutarán localmente (más adelante en el servidor CI), probando el sitio Pantheon ejecutándose en su entorno de prueba.

Comenzaremos nuestra configuración de Behat descargando una plantilla de inicio rápido de GitHub y luego personalizándola para nuestras necesidades. En un directorio adecuado de su computadora, ejecute los siguientes comandos para descargar el paquete:

Al descomprimir el paquete, se crea un nuevo directorio, WordPress-Behat-Quickstart-master. Cambie el nombre del directorio a algo que coincida mejor con nuestro uso:

A continuación, cambie a ese directorio:

En ese directorio, encontrará algunas plantillas de configuración y dos características de inicio que puede crear para crear sus pruebas de Behat.

Pero antes de verlos, terminemos la instalación. La instalación se realiza utilizando Composer, así que si aún no tiene instalado Composer, descargue e instálelo antes de continuar.

Como el paquete de inicio rápido ya contiene una configuración composer.json y composer.lock para instalar Behat, todo lo que necesita hacer es escribir el siguiente comando en la línea de comandos:

Composer descargará los paquetes requeridos y los almacenará en el lugar correcto. A medida que se ejecuta la instalación, y finalmente se completa, debería ver algo como esto:

Behat installation

Para ejecutar Behat, necesitará dos archivos de configuración: behat.yml y behat.local.yml.

El proyecto de inicio rápido ya contiene archivos predeterminados para ambos, pero el archivo para behat.local.yml se almacena como behat.local.yml.sample para evitar que confirme su configuración local (que puede incluir contraseñas, por ejemplo) a Git. El proyecto también contiene un archivo .gitignore con behat.local.yml.

Copie la configuración de muestra:

Puede utilizar este archivo para almacenar cualquier entorno o configuración específica del usuario que no se debe asignar al archivo real behat.yml. En este tutorial, nuestras pruebas son tan simples que todo lo que necesitamos es asegurarnos de que el archivo esté presente.

A continuación, echemos un vistazo al segundo archivo de configuración, behat.yml.

Modifique el archivo reemplazando la URL especificada por el id base_url con la URL del entorno de prueba. Al final, el archivo debería verse así, donde http://test-tutorial-example-site.pantheonsite.io es la URL de su servidor de prueba:

Una vez que haya actualizado la configuración, compruebe que todo está funcionando al enumerar los escenarios de prueba disponibles en el directorio:

Verá una larga lista de expresiones regulares que describen los escenarios de prueba desde el directorio de features:

Output for binbehat -dl

A continuación, echemos un vistazo más de cerca a las pruebas y ejecute una contra su servidor de prueba.

Paso 2: Ejecutar su primera prueba

Las pruebas en Behat se llaman características y, como mencioné brevemente más arriba, se almacenan en archivos de texto en el directorio de features—un archivo por función para probar.

Si busca en el directorio, encontrará dos características especificadas en el paquete de inicio rápido: homepage_works.feature y blog.feature. Puede utilizarlos como punto de partida para sus pruebas y, a continuación, agregar tantos más como desee, mientras que la construcción de un conjunto completo de pruebas para su sitio WordPress.

Comencemos con homepage_works.feature, una prueba rápida que comprueba que un visitante que llega a su sitio puede cargar la página principal:

Las características de Behat están escritas en un formato llamado Gherkin, que, como se puede ver en este fragmento, parece un lenguaje sencillo, un poco más cuidadosamente formulado que una nota entre nosotros dos. O como dice la documentación de Behat, "una forma que tanto el negocio como los desarrolladores pueden entender claramente".

En este tutorial, no voy a profundizar en la explicación de cómo utilizar Behat para construir sus pruebas. Para eso, recomiendo leer la documentación de Primeros pasos de Behat.

Para nuestras necesidades en este momento, basta con entender que una característica consiste en uno o más escenarios, que describen cómo actúa el usuario y qué debe suceder como resultado. Si esto parece mágico, no lo es. Detrás de escenas, Behat utiliza expresiones regulares para asignar sus pasos de escenario a las funciones de PHP definidas en su suite de prueba (vea features/bootstrap), o una biblioteca como Mink, que utilizamos para simular un usuario que navega por la web.

Por ejemplo, la línea "I am on the homepage" ("Estoy en la página principal") se traduce a la función iAmOnHomepage() en la biblioteca Mink, y navega el navegador virtual de Mink a la raíz del sitio web especificado en behat.yml—su servidor de prueba.

Ahora, vamos a personalizar la prueba lo suficiente para que pase en su servidor de prueba. Por el momento, la prueba espera encontrar el texto "Test with Robots" en su página de inicio. En otras palabras, a menos que tenga ese texto escrito allí, la prueba fallará.

Así que reemplaza ese fragmento con una frase que sabes que encontrarás en tu página principal (por ejemplo, el título de tu sitio) y guarda los cambios.

A continuación, ejecute el siguiente comando para ejecutar todas las pruebas etiquetadas con @smoke. En este caso, sólo esta prueba.

Debe ver la prueba pasar:

First Behat test completed successfully

Ahora ha configurado una prueba que se ejecuta correctamente en su máquina de desarrollo, probando el sitio de WordPress en su entorno de prueba de Pantheon.

La colección de pruebas es todavía muy limitada, y para un servidor de la vida real, esto es sólo el comienzo. Por lo tanto, después de completar el tutorial, vuelva a este paso, y profundizar en Behat para crear pruebas que realmente pondrá su servidor a prueba, comprobando todas esas pequeñas cosas que se comprobaría si estaba probando el sitio manualmente.

Pero ahora, vamos a pasar al siguiente paso en nuestro viaje a las pruebas de aceptación automática y hacer que la prueba se ejecute en la nube.

3. Hacer que sus pruebas de Behat se ejecuten en la nube

La Continuous Integration (CI) es una práctica de desarrollo de software en la que el código se fusiona con la sucursal principal varias veces al día y se prueba automáticamente cada vez que se pulsa. Hoy en día, esto generalmente significa que tiene un servicio de integración continua que se ejecuta en la nube viendo su repositorio de Git. A continuación, cada vez que empuja un nuevo commit al control de versiones, el servicio CI se dispara, extrae el código de Git y lo genera y lo prueba.

En este tutorial, utilizaremos piezas de este enfoque para desarrollar una configuración que mejor se adapte al flujo de trabajo del entorno Pantheon: en lugar de ejecutar las pruebas en cada git push, las ejecutaremos cuando se implemente un nuevo código en el servidor de prueba.

Utilizaremos Circle CI como nuestro servidor de integración continua, ya que tiene un nivel libre que es lo suficientemente potente para las necesidades del tutorial y una API que podemos llamar desde Pantheon para iniciar la compilación. En su propia implementación, también puede utilizar otro servidor de integración continua, como Travis CI o Jenkins, con algunos cambios en el proceso explicado en el tutorial.

Paso 1: Empuje sus pruebas a Git

La mayoría de los servicios de integración continua basados en la nube están estrechamente vinculados al control de versiones, soportando Bitbucket o GitHub. Algunos soportan ambos. Pero a menos que configure su propio servidor de CI, por ejemplo utilizando Jenkins, tendrá que mantener un repositorio separado de su cuenta de Pantheon para la configuración de integración continua.

Una opción sería mantener todo el sitio en GitHub o Bitbucket e implementarlo desde el servidor de integración continua a Pantheon usando Terminus. Si bien eso estaría más cerca del ideal de integración continua, también es una configuración bastante complicada y—en mi opinión—rompe la idea del flujo de trabajo del Pantheon.

Por eso, en nuestra configuración, almacenaremos sólo la configuración de prueba en un repositorio de GitHub vinculado al servicio CI y mantendremos el código del sitio en Pantheon como lo hemos hecho hasta ahora.

Primero, regístrese en GitHub y cree un nuevo repositorio:

Create a new Github repository

Luego, en su directorio wp-pantheon-behat, inicialice Git y confirme sus cambios:

Observe que los archivos instalados por Composer no se almacenan en git. Se instalarán de nuevo automáticamente en el servidor CI como parte del script de prueba.

A continuación, inserte los datos en su nuevo repositorio GitHub:

Su configuración de prueba ya está disponible en GitHub. ¡Conéctelos al servidor de integración continua!

Paso 2: Configurar el servidor de integración continua

Primero, regístrese para obtener una cuenta Circle CI gratuita usando su cuenta GitHub.

Una vez que haya iniciado sesión, Circle le pedirá que elija un proyecto de su cuenta de GitHub para crear. Por ejemplo, aquí, puede ver el proyecto wp-pantheon-behat en la parte superior de la lista de la derecha.

Add a project

Haga clic en el botón Build project junto al proyecto.

Circle CI comienza inmediatamente la construcción. Clona el proyecto desde Git, instala cualquier dependencia de Composer—en este caso, las herramientas de prueba de Behat—y luego ejecuta las pruebas.

Build started

En su primera compilación, Circle CI se ejecutará y tendras un error:

An error occurred during composer install

De forma predeterminada, Circle CI ejecuta la versión 5.3.10 de PHP, que es demasiado antigua para algunas de las bibliotecas utilizadas por Behat. Por suerte, esto es fácil de arreglar.

En su directorio wp-pantheon-behat, cree un nuevo archivo, circle.yml. Este archivo contendrá cualquier personalización que deseemos realizar en nuestra configuración de Circle CI.

En el archivo, inserte lo siguiente:

Confirmar el archivo en Git y empujar a su repositorio GitHub.

A continuación, vuelva a Circle CI, donde verá que el sistema de integración continua ha comenzado a ejecutar la prueba de nuevo.

En esta ocasión, el paso Composer debería ejecutarse correctamente. Pero todavía hay configuración que hacer: ¡mientras que la estructura pasó, el círculo CI no encontró nuestras pruebas!

No tests found

Para arreglar esto, vamos a decirle a Circle cómo ejecutar nuestras pruebas de Behat.

En circle.yml, agregue una nueva sección, test, justo debajo de la configuración de la versión de PHP que acabamos de crear:

Echemos un vistazo al fragmento.

En primer lugar, en la sección pre, le decimos a Circle CI que cree un archivo de configuración behat.local.yml usando la plantilla antes de intentar ejecutar las pruebas.

Luego, en la sección denominada override, definimos la secuencia de acciones que Circle CI debe tomar cada vez que es el momento de ejecutar las pruebas.

El comando Behat es un poco diferente de lo que usamos al ejecutar las pruebas localmente. Esto se debe a que queremos imprimir los resultados de las pruebas en un formato XML tipo JUnit que puede ser analizado por el servidor CI. La variable $CIRCLE_TEST_REPORTS es una referencia a un directorio en el que Circle CI espera encontrar los informes de prueba.

Confirmar y empujar los cambios de nuevo y volver a Circle CI para comprobar que las pruebas se ejecutan correctamente.

The tests were run successfully

4. Uso de Quicksilver para iniciar las pruebas en tiempo de implementación

Ahora que ha configurado sus pruebas de Behat y las ejecuta en un servidor de integración continuo, el último paso restante es conectar esta configuración con su flujo de trabajo de Pantheon haciendo que Pantheon dispare una nueva compilación en Circle CI cada vez que implemente sus cambios en el ambiente de prueba .

Lo haremos con los Quicksilver Platform Hooks de Pantheon, un sistema que ofrece a los desarrolladores la capacidad de vincular scripts a eventos en el flujo de trabajo de Pantheon.

El desencadenar una nueva construcción en Circle CI es sólo un ejemplo de lo que puedes lograr usando Quicksilver hooks, por lo que te recomiendo que mires en su documentación y ejemplos, y descubra más usos de su propia una vez hecho con el tutorial.

Paso 1: Definir una acción Quicksilver

Quicksilver ya está instalado en el entorno de Pantheon, por lo que puede empezar a usarlo simplemente definiendo su primera acción Quicksilver.

La configuración de Quicksilver del sitio Pantheon consiste en un archivo de configuración, pantheon.yml, ubicado en la raíz del directorio de code del sitio, y los scripts reales escritos en PHP.

Puede cargar estos archivos usando SFTP como lo hicimos en el tutorial anterior o usar el modo Git.

Para realizar los cambios en el modo Git, configure primero el Connection Mode (modo de conexión) de su sitio a Git:

Set the connection mode to Git

Haga clic en Git Connection Info para copiar el comando para clonar su repositorio git y ejecutarlo en un directorio adecuado en su línea de comandos:

Una vez que el comando clon haya terminado, añada un archivo pantheon.yml en el directorio usando su editor de texto favorito, con el siguiente contenido:

En este archivo de configuración, se enumerarán todos los scripts que desea enlazar con los flujos de trabajo de Pantheon, definiendo si desea que el script se ejecute antes o después de ese evento. Para cualquier evento, puedes agregar tantos scripts como necesites.

Actualmente, los siguientes flujos de trabajo están disponibles para conectarse a:

  • Deploy: Se desencadena cuando se implementa el código en prueba o produccion. Los scripts se ejecutan en el entorno de destino.
  • sync_code: Se activa cuando el código se envía a través de Git o se confirma en el panel de control de Pantheon. Los scripts se ejecutan en el entorno committed-to .
  • clone_database: Se activa cuando los datos se clonan entre entornos. Los scripts se ejecutan en el entorno de destino.
  • clear_cache: Se desencadena cuando se borra la caché. Las secuencias de comandos se ejecutan en el entorno despejado.

Cada secuencia de comandos, o acción, consiste de un type (actualmente, sólo webphp, lo que significa que el código PHP se ejecuta en el entorno de destino es compatible), una description y un script, una ruta de acceso a un archivo de script relativo a su repositorio de código.

Por lo tanto, mirando el archivo pantheon.yml anterior, verá que queremos ejecutar el script, private/scripts/circle_ci_notify.php, justo después de un evento deploy.

Paso 2: Crear un script PHP para su acción Quicksilver

Para funcionar, nuestro gancho de acción Quicksilver todavía necesita el script.

Nuestra secuencia de comandos llamará a la nueva acción de compilacion de la API de Circle CI para que las pruebas se ejecuten de nuevo. Para ello, necesitamos recuperar y almacenar las credenciales de Circle CI API de una manera segura en el entorno de Pantheon Test.

En el panel de control de Circle CI, haga clic en Account Settings en el menú del lado izquierdo y, a continuación, seleccione la ficha API Tokens para crear un nuevo token de API.

Dé un nombre descriptivo a su nuevo token y haga clic en Create new token.

Create a new API token

Ahora, tiene un token de API que puede usar para hablar con la API de Circle CI.

Confirmar los secretos API u otros datos confidenciales para el control de versiones se considera mala práctica. Por lo tanto, utilicemos una forma más segura de pasar las credenciales de la API a la secuencia de comandos, creando un archivo de configuración y subiendo a una ubicación segura en el servidor de prueba.

En un directorio que esté fuera del repositorio de código exportado, cree un archivo denominado secrets.json. En ese archivo, coloque el siguiente contenido:

Luego, suba a su entorno de prueba, en un directorio llamado files/private, usando SFTP. Observe que el sistema de archivos (el directorio files de su servidor) está separado del código, y los archivos en él nunca van al control de versiones.

El comando Terminus site connection-info imprime información para conectarse a su entorno, basado en el sitio, el entorno y el método de conexión que pasa como parámetros.

Por lo tanto, para conectarse al sistema de archivos de su entorno de prueba usando SFTP, puede usar este comando como un pequeño truco, rodeando el comando con caracteres (`) ejecuta el comando impreso en lugar de simplemente mostrarlo a usted (naturalmente, puede También utilice su cliente SFTP favorito):

Ahora que está conectado al servidor, es hora de cargar el archivo de configuración:

Las credenciales están ahora en su lugar. Vamos a crear el script.

En su repositorio de código, cree un directorio private/scripts, y dentro de él, agregue un nuevo script PHP, circle_ci_notify.php.

Se trata de un script PHP normal que se ejecuta en el entorno de destino del evento—en el caso del evento deploy, Test o Live.

Pasemos por el script línea por línea.

En las líneas 2-5, el script comprueba que se está ejecutando en el entorno de prueba.

Luego, en la línea 8, lee los parámetros de la API del archivo JSON que acaba de cargar en el sistema de archivos, utilizando una función auxiliar, _get_secrets, especificada al final del archivo, en las líneas 37-50.

Luego, en las líneas 10-22, el script realiza una llamada HTTP a la API Circle CI para iniciar la compilación.

Finalmente, en las líneas 24-28, el script comprueba la respuesta de la llamada API e imprime un simple mensaje de éxito. Si lo desea, este es un buen lugar para un mayor desarrollo: puede, por ejemplo, hacer que el script envíe una notificación al canal Slack de su equipo.

Ahora, ya está listo. Confirmar y transferir los cambios a su repositorio Git.

Una vez que el git push termine, notarás la siguiente salida, con Pantheon diciéndole que detectó tu recién creado pantheon.yml y aplicó sus acciones al entorno de Dev.

Sin embargo, como mencioné anteriormente, la tarea deploy se ejecuta en el entorno de destino. Por lo tanto, antes de que se ejecute nuestro script, deberemos implementar los cambios a Test.

Hagámoslo usando la interfaz de línea de mandatos Terminus (también puedes usar el Panel de control Web, si quieres):

Nuestro script de Quicksilver ya está disponible en el entorno de prueba.

Para verlo en acción, realice un cambio en la base de código del entorno de desarrollo (por ejemplo, instalando un nuevo complemento o modificando su tema secundario) y confírmelo e implementar los cambios en Prueba.

Cuando visite su panel Circle CI, verá que se ha activado una nueva generación y está funcionando, probando que la página principal del sitio de prueba puede cargarse correctamente.

También puede utilizar Terminus para comprobar que el script se ejecuta correctamente. Para ello, antes de implementar los cambios, en la línea de comandos, ejecute el comando:

Ahora, cuando finalice el despliegue, verá algo como esto, informándole sobre su acción Quicksilver:

Conclusion

La configuración de pruebas automatizadas ya está completa: cada vez que implemente código de su entorno de Pantheon Dev en Test, se disparará una nueva generación en Circle CI y ejecutará las pruebas de Behat en su entorno de prueba. Si algo sale mal, Circle le enviará un correo electrónico informándole sobre una compilación rota para que pueda arreglarlo y volver a intentarlo.

Pero esto es solo el principio.

En primer lugar, tendrá que escribir más pruebas. Piense en todas las cosas que comprueba para asegurarse de que su sitio funciona correctamente y, a continuación, escriba las características de Behat para probarlas. A continuación, piense en cómo sus visitantes y clientes pueden utilizar el sitio, y escribir pruebas para esos casos de uso también.

También puede mejorar la configuración Circle CI, por ejemplo, agregando una notificación Slack sobre una prueba exitosa. De esta manera, sabrás que tus pruebas automatizadas pasan y puedes hacer una revisión final antes de empujar los cambios a la version de produccion. Más tarde, una vez que se sienta confiado acerca de sus pruebas, incluso podría considerar la modificación de su circle.yml para usar Terminus para implementar el código de Prueba a Produccion automáticamente después de una construcción exitosa!

¡Las posibilidades no terminan aquí! También puede utilizar Quicksilver para agregar más scripts automatizados a su flujo de trabajo. Echa un vistazo a algunos ejemplos de los ingenieros del Pantheon. A continuación, ¡puedes crear algunos de los suyos!

Poco a poco, a medida que automatiza su proceso de pruebas y desarrollo, crea un flujo de trabajo cada vez más seguro.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.