🥇Cómo conectar GitLab y Pantheon y optimizar los flujos de trabajo de Drupal y WordPress

Nuestro invitado, creador de herramientas para desarrolladores de Pantheon, habla sobre cómo automatizar los despliegues de WordPress utilizando GitLab CI/CD.

En Pantheon Me dedico a las relaciones con desarrolladores, por lo que siempre busco nuevas formas de ayudar a los desarrolladores de WordPress y Drupal a resolver problemas de automatización en sus flujos de trabajo. Para ello, disfruto experimentar con nuevas herramientas y combinarlas para trabajar de manera efectiva.

A menudo veo a los desarrolladores lidiar con un servidor intermedio.

No es muy placentero esperar tu turno para usar el servidor intermedio o enviar a los clientes una URL con la nota: "Aquí puedes mirar, pero aquí no mires todavía".

Los entornos multidev son una de las excelentes herramientas de Pantheon, resuelven este problema ya que se pueden crear entornos bajo ramas de Git a pedido. Cada entorno multidev tiene su propia URL y base de datos, por lo que los desarrolladores pueden trabajar tranquilos, verificar la calidad y obtener aprobación sin pisarse los pies mutuamente.

Sin embargo, Pantheon no cuenta con herramientas para control de versiones o integración y despliegue continuos (CI/CD). Pero es una plataforma flexible, con la que se pueden integrar cualquier herramienta.

También he notado que los equipos utilizan unas herramientas para desarrollo y otras para construcción y despliegue.

Por ejemplo, tienen diferentes herramientas para control de versiones y CI/CD. Tienen que lidiar y alternar entre herramientas para editar el código y diagnosticar problemas.

En GitLab Tienen un conjunto completo de herramientas para desarrollo: para control de versiones, tickets, solicitudes de fusión, un pipeline CI/CD de primera categoría, un registro de contenedores y algo más en esa línea. No he encontrado aplicaciones que ofrezcan tanto para gestionar el flujo de trabajo de desarrollo.

Me apasiona la automatización, así que he aprendido a conectar Pantheon con GitLab para que los commits a la rama principal en GitLab se desplieguen en el entorno de desarrollo principal en Pantheon. Además, las solicitudes de fusión en GitLab pueden crear y desplegar código en los entornos multidev en Pantheon.

En esta guía, te explicaré cómo configurar la conexión entre GitLab y Pantheon y optimizar el flujo de trabajo de WordPress y Drupal.

Por supuesto, puedes reflejar el repositorio de GitLab, pero haremos todo manualmente para explorar GitLab CI y en el futuro usar esta herramienta no solo para despliegues.

Introducción

Para este post, es necesario entender que Pantheon divide cada sitio en tres elementos: código, base de datos y archivos.

El código incluye archivos CMS, como el núcleo, los plugins y los temas de WordPress. Estos archivos se gestionan en un repositorio Git, alojado en Pantheon, es decir, podemos desplegar el código desde GitLab a Pantheon a través de Git.
Los archivos en Pantheon se refieren a los archivos multimedia, es decir, imágenes para el sitio. Por lo general, son subidos por los usuarios, y Git los ignora.

Crea una cuenta gratuita, conoce más sobre el flujo de trabajo de Pantheon o solicita una demostración en pantheon.io.

Suposiciones

Mi proyecto en Pantheon y GitLab se llama pantheon-gitlab-blog-demo. El nombre del proyecto debe ser único. Aquí trabajaremos con un sitio de WordPress. También se puede usar Drupal, pero se necesitarán algunos ajustes.

Voy a utilizar la línea de comandos de Git, pero puedes trabajar en la interfaz gráfica, si lo prefieres.

Creando el proyecto

Para comenzar, creamos un proyecto en GitLab (esto lo abordaremos más adelante).

Ahora creamos un sitio de WordPress en Pantheon. Luego instalamos WordPress para el panel del sitio.

Si sientes la necesidad de hacer cambios, como eliminar y añadir plugins, ten paciencia. El sitio aún no está conectado a GitLab, y queremos que todos los cambios de código pasen por GitLab.

Cuando hayamos instalado WordPress, regresamos al panel del sitio en Pantheon y cambiamos el modo de desarrollo a Git.

El commit inicial en GitLab

Ahora necesitamos trasladar el código inicial de WordPress desde el sitio de Pantheon a GitLab. Para ello, clonamos el código del repositorio Git del sitio de Pantheon de forma local y luego lo enviamos al repositorio de GitLab.

Para hacerlo más fácil y seguro, añadiremos una clave SSH en Pantheon y no tendremos que introducir la contraseña cada vez que clonemos el repositorio Git de Pantheon. De paso, ya añadiremos la clave SSH en GitLab.

Para esto, clonaremos el sitio de Pantheon localmente, copiando el comando del campo Clonar con Git en el panel del sitio.

Si necesitas ayuda, consulta la documentación sobre cómo comenzar con Git para Pantheon.

Ahora cambiamos git remote origin, para que apunte a GitLab en lugar de Pantheon. Esto se puede hacer con el comando git remote.

Vayamos al proyecto en GitLab y copiemos la URL del repositorio del menú desplegable Clonar en la página de detalles del proyecto. Elegiremos la opción Clonar con SSH, ya que ya hemos configurado la clave SSH.

funciona hasta que se finalice manualmente. Por lo tanto, puede ser útil la opción git remote para la copia local del repositorio de código — origen. Esto se puede cambiar con git remote set-url origin [URL del repositorio GitLab], donde, en lugar de los corchetes, introducimos la URL real.

Finalmente, ejecutamos git push origin master --force, para enviar el código de WordPress desde el sitio de Pantheon a GitLab.

El parámetro –force solo se necesita una vez. Luego en los comandos git push no estará en GitLab.

Configuramos las credenciales y las variables

¿Recuerdas cómo añadimos localmente la clave SSH para autenticarnos en Pantheon y GitLab? El token SSH se puede usar para la autenticación en GitLab y Pantheon.

GitLab tiene una excelente documentación. Vamos a ver la sección sobre claves SSH al usar el ejecutor Docker en el documento sobre el uso de claves SSH con GitLab CI/CD.

Ahora vamos a realizar los primeros dos pasos: crearemos un nuevo par de claves SSH localmente con ssh-keygen y añadiremos la clave privada como una variable en el proyecto.

Luego configuraremos SSH_PRIVATE_KEY cómo la variable de entorno GitLab CI/CD en la configuración del proyecto.
En el tercer y cuarto paso crearemos un archivo .gitlab-ci.yml con este contenido:

before_script:
  # Ver https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

Por ahora no vamos a hacer commit del archivo .gitlab-ci.yml, luego necesitaremos añadirle algo más.

Ahora realizamos el quinto paso y añadimos la clave pública que creamos en el primer paso a los servicios a los que necesitas acceder en el entorno de construcción.

En nuestro caso queremos acceder a Pantheon desde GitLab. Seguimos las instrucciones en el documento de Pantheon sobre añadir la clave SSH a Pantheon y realizamos este paso.

Recordemos: la clave privada SSH está en GitLab, la pública en Pantheon.

Configuraremos algunas variables de entorno más. La primera se llama PANTHEON_SITE. Su valor es el nombre del sitio de Pantheon en tu máquina.

El nombre en la máquina se indica al final del comando Clone with Git. Ya has clonado el sitio localmente, así que será el nombre del directorio del repositorio local.

Luego configuraremos la variable de entorno PANTHEON_GIT_URL. Esta es la URL del repositorio Git para el sitio de Pantheon que ya hemos usado.

Ingresamos solo la URL del repositorio SSH, sin git clone y el nombre del sitio en la máquina al final.

Uf. Eso lo hemos hecho, ahora podemos terminar nuestro archivo .gitlab-ci.yml.

Creamos la tarea de despliegue

Lo que haremos inicialmente con GitLab CI es muy similar a lo que hacíamos con los repositorios Git antes. Pero esta vez añadiremos el repositorio de Pantheon como una segunda fuente remota de Git, y luego enviaremos el código desde GitLab a Pantheon.

Para ello configuraremos la etapa deploy y la tarea deploy:dev, ya que desplegaremos en el entorno de desarrollo en Pantheon. Como resultado, el archivo .gitlab-ci.yml se verá así:

etapas:
- desplegar

antes_del_script:
  # Ver https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

desplegar:dev:
  etapa: desplegar
  entorno:
    nombre: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  solo:
    - master

Variables SSH_PRIVATE_KEY, PANTHEON_SITE y PANTHEON_GIT_URL deben parecer familiares; ya hemos configurado estas variables de entorno. Con estas variables, podremos usar los valores en el archivo .gitlab-ci.yml muchas veces, y solo necesitaremos actualizarlas en un solo lugar.

Finalmente, agreguemos, confirmemos y enviemos el archivo .gitlab-ci.yml a GitLab.

Verificamos el despliegue

Si hemos hecho todo correctamente, la tarea deploy:dev se ejecutará con éxito en GitLab CI/CD y enviará el commit .gitlab-ci.yml a Pantheon. Vamos a comprobarlo.

Enviamos ramas de solicitudes de fusión a Pantheon

Aquí utilizaremos mi función favorita de Pantheon— multidev, donde se pueden crear entornos adicionales de Pantheon por solicitud para ramas de Git.

El acceso a multidev es limitado,así que esta sección puede no ser necesaria. Pero si tienes acceso, puedes mejorar significativamente el rendimiento configurando la creación automática de entornos multidev en Pantheon a partir de las solicitudes de fusión de GitLab.

Primero, hagamos una nueva rama de Git localmente usando git checkout -b multidev-support. Ahora cambiemos algo de nuevo en .gitlab-ci.yml.

Me gusta incluir el número de la solicitud de fusión en el nombre del entorno de Pantheon. Por ejemplo, la primera solicitud de fusión— mr-1, la segunda— mr-2 etc.

La solicitud de fusión cambia, así que necesitamos definir dinámicamente los nombres de las ramas de Pantheon. En GitLab es simple—solo hay que usar variables de entorno predefinidas..

Podemos tomar $CI_MERGE_REQUEST_IID, para identificar el número de la solicitud de fusión. Vamos a aplicar todo esto junto con las variables de entorno globales que definimos anteriormente, y agreguemos una nueva tarea desplegar:multidev al final del archivo .gitlab-ci.yml.

desplegar:multidev:
  etapa: desplegar
  entorno:
    nombre: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Consulta la rama fuente de la solicitud de fusión
    - git checkout $CI_COMMIT_REF_NAME
    # Agrega el repositorio git de Pantheon como un remoto adicional
    - git remote add pantheon $PANTHEON_GIT_URL
    # Envía la rama fuente de la solicitud de fusión a Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  solo:
    - merge_requests

Se parecerá a nuestra tarea, deploy:devsolo que la rama se envía a Pantheon, no a master.

Hemos agregado y confirmado el archivo actualizado, .gitlab-ci.ymlahora enviaremos la nueva rama a GitLab con git push -u origin multidev-support.

Ahora crearemos una nueva solicitud de fusión desde la rama multidev-support, haciendo clic en Crear solicitud de fusión.

Una vez creada la solicitud de fusión, veamos cómo se ejecuta la tarea CI/CD deploy:multidev.

Mira: se ha enviado una nueva rama a Pantheon. Sin embargo, si vamos a la sección multidev en el panel del sitio en Pantheon, no veremos allí un nuevo entorno.

Veamos la sección Git Branches.

Al final, nuestra rama mr-1 ha llegado a Pantheon. Crearemos un entorno a partir de la rama mr-1.

Hemos creado un entorno multidev, y ahora volvamos a GitLab y echemos un vistazo a la sección Operations > Environments. Veremos registros para dev y mr-1.

Esto se debe a que hemos agregado un registro entorno llamado name y url en las tareas de CI/CD. Si hacemos clic en el ícono del entorno abierto, iremos a la URL del entorno multidev en Pantheon.

Automatizamos la creación de multidev

En principio, podríamos detenernos aquí y simplemente recordar crear un entorno multidev para cada solicitud de fusión, pero este proceso se puede automatizar.

En Pantheon hay una herramienta de línea de comandos Terminus, donde podemos trabajar con la plataforma de forma automática. En Terminus se pueden crear entornos multidev desde la línea de comandos, lo que es ideal para GitLab CI.

Necesitamos una nueva solicitud de fusión para probar esto. Crearemos una nueva rama usando git checkout -b auto-multidev-creation.

Para usar Terminus en las tareas de GitLab CI/CD, se necesita un token de máquina para la autenticación en Terminus y una imagen de contenedor con Terminus.

Creando un token de máquina Pantheon, guárdalo en un lugar seguro y añádelo como variable de entorno global en GitLab con el nombre PANTHEON_MACHINE_TOKEN.

Si olvidaste cómo agregar variables de entorno en GitLab, vuelve a donde definimos PANTHEON_SITE.

Creando un Dockerfile con Terminus

Si no usas Docker o no te gustan los archivos Dockerfile, toma mi imagen registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest y omite esta sección.

En GitLab hay un registro de contenedores, donde se puede construir y hospedar el Dockerfile para nuestro proyecto. Vamos a crear un archivo Dockerfile con Terminus para trabajar con Pantheon.

Terminus es una herramienta de línea de comandos en PHP, así que comencemos con una imagen de PHP. Estoy instalando Terminus a través de Composer, así que usaré la imagen oficial de Docker Composer. Creamos Dockerfile en el directorio del repositorio local con el siguiente contenido:

# Use the official Composer image as a parent image
FROM composer:1.8

# Update/upgrade apk
RUN apk update
RUN apk upgrade

# Make the Terminus directory
RUN mkdir -p /usr/local/share/terminus

# Install Terminus 2.x with Composer
RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2"

Sigamos las instrucciones para construir y enviar imágenes en la sección Build and push images en de la documentación del registro de contenedores, para construir una imagen desde Dockerfile y enviarla a GitLab.

Abrimos la sección Registry en el proyecto de GitLab. Si todo ha salido según lo planeado, allí estará nuestra imagen. Anota el enlace al tag de la imagen; lo necesitamos para el archivo .gitlab-ci.yml.

Sección script en la tarea deploy:multidev está empezando a crecer, así que trasladémoslo a un archivo separado. Creamos un nuevo archivo private/multidev-deploy.sh:

#!/bin/bash

# Store the mr- environment name
export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID

# Authenticate with Terminus
terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN

# Checkout the merge request source branch
git checkout $CI_COMMIT_REF_NAME

# Add the Pantheon Git repository as an additional remote
git remote add pantheon $PANTHEON_GIT_URL

# Push the merge request source branch to Pantheon
git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force

# Create a function for determining if a multidev exists
TERMINUS_DOES_MULTIDEV_EXIST()
{
    # Stash a list of Pantheon multidev environments
    PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)"

    while read -r multiDev; do
        if [[ "${multiDev}" == "$1" ]]
        then
            return 0;
        fi
    done <<< "$PANTHEON_MULTIDEV_LIST"

    return 1;
}

# If the mutltidev doesn't exist
if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV
then
    # Create it with Terminus
    echo "No multidev for $PANTHEON_ENV found, creating one..."
    terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV
else
    echo "The multidev $PANTHEON_ENV already exists, skipping creating it..."
fi

El script está en un directorio privado y no permite acceso web en Pantheon. Tenemos un script para nuestra lógica multidev. Ahora actualicemos la sección deploy:multidev archivos .gitlab-ci.yml, para que quede así:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Ejecutar el script de despliegue multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Es necesario asegurarse de que nuestras tareas se ejecuten en la imagen personalizada creada, así que añadiremos la definición image con la URL del registro en .gitlab-ci.yml. Al final, obtenemos un archivo como este .gitlab-ci.yml:

image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest

stages:
- deploy

before_script:
  # Ver https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  only:
    - master

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Ejecutar el script de despliegue multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Añadimos, hacemos commit y enviamos private/multidev-deploy.sh y .gitlab-ci.yml. Ahora volvemos a GitLab y esperamos a que se ejecute la tarea CI/CD. Paciencia: multidev puede tardar unos minutos en crearse.

Luego vamos a ver la lista de multidev en Pantheon. ¡Oh, maravilla! El entorno multidev mr-2 ya está aquí.

Conclusión

Mi equipo trabaja mucho más alegremente cuando comenzamos a abrir solicitudes de fusión y crear entornos automáticamente.

Con las potentes herramientas de GitLab y Pantheon es posible conectar GitLab a Pantheon automáticamente.

Dado que utilizamos GitLab CI/CD, hay un gran potencial para hacer crecer nuestro flujo de trabajo. Aquí hay un par de ideas para empezar a trabajar:

Agregue un paso de compilación.
Agregue pruebas automatizadas.
Agregue una tarea para garantizar el cumplimiento de las normas de codificación.
Agregue pruebas de seguridad de aplicaciones dinámicas.

Escriba lo que piensa sobre GitLab, Pantheon y la automatización.

P.D. ¿Sabía que Terminus, la herramienta de línea de comandos de Pantheon, se puede extender a través de complementos??

Hemos trabajado bien en Pantheon en la versión 2 de nuestro complemento para herramientas de compilación Terminus con soporte de GitLab. Si no deseas complicarte con la configuración para cada proyecto, prueba este complemento y ayúdanos a probar la beta v2. Para el equipo de Terminus build:project:create solo necesitas un token de Pantheon y un token de GitLab. Desplegará uno de los ejemplos de proyecto con Composer y pruebas automáticas, creará un nuevo proyecto en GitLab, un nuevo sitio en Pantheon y los conectará utilizando variables de entorno y claves SSH.