Implementaciones modernas para sus sitios de WordPress

Si es como yo, su primera experiencia al enviar archivos a un servidor web fue a través de un administrador de archivos basado en la web como cPanel o un cliente de Protocolo de transferencia de archivos (FTP) como Transmit o Filezilla. Conéctese al servidor, arrastre sus archivos y espere a que se complete la transferencia.

Fácil, ¿verdad?

Sin embargo, tan pronto como comencé a trabajar con algo más complejo que los archivos HTML estáticos, implementar mi código se volvió mucho más complejo: ¿qué sucede si pierdo un archivo requerido por otros, o un punto y coma en una inclusión global y muestra en pantalla blanca el todo el sitio? ¿Qué sucede si se pierde un paso crucial durante el proceso?

Estos problemas de "codificación de vaqueros" solo empeoran a medida que se involucran más personas, entornos y dependencias. Como resultado, se vuelve cada vez más difícil seguir progresando mientras se hace malabarismo con todas estas partes móviles. Lo peor de todo es que la liberación de código se convierte en un gran problema y una fuente constante de ansiedad.

A medida que nuestras aplicaciones, sitios y tiendas se modernizan, también deberíamos modernizar nuestras implementaciones. Desde el control de versiones hasta la entrega continua, un proceso de lanzamiento moderno puede aliviar la ansiedad en torno a las implementaciones.

Seguimiento de cambios con control de versiones

El primer paso para alejarse de las actualizaciones ad-hoc y la codificación de vaqueros es tener su sitio bajo control de versiones, utilizando una herramienta como Git.

El uso del control de versiones significa que podrá ver qué ha cambiado, quién realizó los cambios e incluso trabajar en varios conjuntos de cambios al mismo tiempo mediante el uso de ramas. Como resultado, el trabajo no se sobrescribe y cualquier conflicto entre archivos se resalta claramente.

Si no ha trabajado antes con Git, no tenga miedo: hemos escrito una introducción a Git y una publicación sobre flujos de trabajo de Git más avanzados.

Decidir qué rastrear

A medida que movemos nuestro sitio bajo el control de versiones, lo que no controlamos es casi tan importante como lo que hacemos:

En términos generales, el control de versiones es para rastrear el código fuente, no los activos generados por herramientas o procesos . Esto incluye cosas como CSS y JavaScript concatenados/minificados, dependencias externas, etc. En conjunto, nos referimos a estos elementos como artefactos .

Por ejemplo, si está utilizando un preprocesador de CSS como Sass, los archivos CSS generados no deben rastrearse bajo el control de versiones. No solo son fácilmente reproducibles, sino que son difíciles de leer y una fuente común de conflictos de combinación cuando hay varios desarrolladores involucrados.

Cuando se trata de dependencias (bibliotecas, complementos de WordPress, etc.), aproveche herramientas como Composer y WPackagist en lugar de agrupar código del que no es responsable en su repositorio.

Además, un repositorio de Git nunca debe contener cosas como contraseñas, claves SSH privadas o cualquier otra información confidencial que se considere secreta , ya que cada desarrollador con una copia del repositorio tendría esa información confidencial en sus computadoras.

Estructuración de su repositorio

Al configurar un repositorio de Git para un sitio de WordPress o WooCommerce, generalmente es mejor tratar wp-content/ como la raíz del repositorio, ya que generalmente no tocará archivos por encima de este directorio.

Los complementos y temas que usa su sitio pero para los que no está manteniendo el código deben cargarse a través de Composer, ya que son dependencias externas. Del mismo modo, los archivos CSS y JavaScript procesados ​​deben excluirse a través del archivo .gitignore, ya que estos artefactos se crearán para nosotros como parte de nuestro proceso de lanzamiento.

Tenemos una plantilla de repositorio gratuita disponible en GitHub para que pueda comenzar.

Una introducción a CI/CD

Cuando se trata de implementar software, hay dos términos importantes que debe comprender: Integración continua (CI) y Entrega continua (CD).

Estos dos términos están estrechamente relacionados, tanto que a menudo se denominan colectivamente "CI/CD", y el camino a través del cual fluyen nuestros cambios se convierte en la "canalización de CI/CD". Esta tubería generalmente toma la siguiente forma:

1. Cree el lanzamiento: instale dependencias (Composer, npm, etc.), luego cree artefactos (Webpack, Grunt, Sass, etc.)
2. Pruebe la compilación: ejecute pruebas unitarias, verifique los estándares de codificación, realice análisis de código estático, etc.
3. Implementar la versión en uno o más entornos

La integración continua es el proceso de probar continuamente nuestro código para garantizar que los cambios no rompan la funcionalidad existente, de modo que nuestros nuevos cambios se integren limpiamente con la base de código existente. Cada vez que se envían nuevos cambios, se ejecutan comprobaciones para garantizar que no estamos "rompiendo la compilación".

Para que la integración continua sea útil, estas comprobaciones deben estar automatizadas. Por ejemplo, si tiene un conjunto de pruebas unitarias, puede optar por ejecutar este conjunto de pruebas cada vez que se abre una nueva solicitud de extracción, lo que le alerta sobre posibles fallas antes de que el código entre en producción.

Sin embargo, la integración continua no se limita a las pruebas unitarias, ya que hay una serie de comprobaciones "sin código" que se pueden ejecutar automáticamente en su código, que incluyen:

• Comprobaciones de estándares de codificación (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Análisis de código estático (PHPStan, Psalm)

La ejecución de estas comprobaciones automáticamente en cada inserción también garantiza que todo el código se ejecute a través de las mismas comprobaciones, lo que evita que se libere el código que no pasa.

La entrega continua , por otro lado, es la idea de que deberíamos poder "entregar" (implementar) nuestro código en cualquier momento. Para lograr esto, debemos tener un proceso de implementación con secuencias de comandos que, con solo hacer clic en un botón, mueva sin problemas nuestro código a producción.

Tener sus implementaciones con secuencias de comandos significa que puede implementarlas de manera regular y consistente ; cada implementación debería funcionar igual que la anterior. Como resultado, su equipo puede desplegarse más regularmente con un mayor nivel de confianza y menos preocupaciones de que alguien haya perdido un paso en el camino. ¡Para algunos equipos, no es raro implementar docenas (o incluso cientos) de veces al día!

Dependiendo de su sitio, es posible que desee buscar en "el otro CD", Implementación continua ; es muy similar a la entrega continua, pero según este modelo, cada envío a una sucursal se implementa automáticamente. Esto puede ser extremadamente poderoso cuando se usa un esquema de control de versiones ramificado (como Github Flow), pero puede no ser deseable si necesita programar ventanas de lanzamiento o hacer todo el trabajo en la rama principal.

Implementación de un sitio de WordPress o WooCommerce con CI/CD

Ahora que conocemos la terminología básica, echemos un vistazo a la implementación de un sitio típico de WordPress o WooCommerce:

Para este ejercicio, usaremos Branch, una herramienta de CI/CD diseñada en torno a las necesidades de los desarrolladores de WordPress de la misma gente detrás de WP Pusher. ¡Lo mejor de todo es que Branch tiene soporte integrado para implementar en Nexcess!

Para comenzar, regístrese en Branch conectando su cuenta de GitHub, GitLab o Bitbucket y luego cree su primer sitio.

A continuación, querremos configurar todos los pasos necesarios para construir nuestro sitio. Branch ofrece una serie de "recetas" para acciones comunes (instalar dependencias de Composer, ejecutar Webpack, etc.), pero también nos brinda la posibilidad de agregar cualquier número de pasos personalizados.

Una vez que hayamos delineado los pasos necesarios para construir nuestro sitio, podemos pasar a la siguiente etapa de nuestra canalización: la prueba.

Si ya tiene un conjunto de pruebas automatizado para su sitio, simplemente puede decirle a Branch que ejecute los comandos que sean necesarios. Incluso si aún no tiene pruebas, Branch hace que sea muy fácil agregar pelusas, estándares de codificación y verificaciones de compatibilidad.

Ahora que instalamos nuestras dependencias, construimos todo y pasamos nuestras pruebas, ¡es hora de poner nuestro código en producción!

Branch contiene recetas para implementar en Nexcess (así como en otros proveedores de alojamiento importantes), y conectar las dos plataformas es sencillo:

1. Seleccione su sitio en el panel de Branch, haga clic en "Configuración", luego tome la clave SSH pública de su sitio de Branch
2. Agregue esta clave pública a la lista de claves dentro del portal Nexcess

Una vez que Branch pueda comunicarse con su sitio Nexcess, podemos seleccionar la receta de implementación "Nexcess" y completar algunos detalles:

1. El nombre de host y el nombre de usuario del sitio (disponible a través del portal Nexcess en la pantalla de "Acceso" de su sitio)
2. La raíz web en la que estamos implementando. Si nuestro repositorio git está destinado a servir como el directorio wp-content/, este valor debe ser "public_html/wp-content".
3. Los archivos que deseamos implementar (generalmente el valor predeterminado, "*", es suficiente)
4. La rama de git para implementar en este entorno

La configuración de "rama de Git" es especialmente importante, ya que le permite especificar diferentes implementaciones para diferentes ramas. Por ejemplo, puede tener una rama de "prueba" que se implementa en su entorno de prueba, lo que le permite probar los cambios antes de ponerlos en marcha.

Vale la pena señalar que Branch usa el modelo de implementación continua de forma predeterminada, donde la canalización se ejecuta con cada envío a la rama determinada. Si prefiere más un modelo de entrega continua (donde se deben realizar algunas acciones manuales), puede considerar mantener una rama de "producción" que solo se fusiona cuando está listo para lanzar.

¡En este punto, Branch debe estar configurado para construir e implementar su repositorio git en Nexcess! Puede activar su primera implementación haciendo clic en el botón "Ejecutar implementación" en la página "Canalizaciones" de su sitio o ingresando a su repositorio Git.

Personalización de su proceso de lanzamiento

Una de las características realmente agradables de Branch es la capacidad de configurar pasos adicionales después de una implementación exitosa, como borrar automáticamente el caché de objetos de su sitio después de una implementación. Esto se puede lograr usando la receta WP-CLI en "Otro".

El host y el nombre de usuario generalmente serán los mismos que usamos en el paso de implementación, y puede encadenar tantos comandos como sea necesario.

Conclusión

Si todavía está luchando con las payasadas de codificación de vaqueros y / o los lanzamientos plagados de ansiedad, ¡eche un vistazo a Branch y haga que las implementaciones sean muy sencillas!