Implementación en vivo y puesta en escena con Deploybot

Si ha estado en el desarrollo web por un tiempo, probablemente haya arruinado una transferencia de archivos mientras intentaba actualizar un sitio. En el mejor de los casos, agrega un montón de archivos fácilmente identificables a un directorio y los elimina para corregir el error. Sí, te cuesta tiempo y es molesto, pero no pasa nada.

En el peor de los casos, transfiere un montón de archivos de temas de forma incorrecta. Luego, debe averiguar cuáles se sobrescribieron, cuáles no pertenecen en absoluto y cómo diablos recuperará el estado de funcionamiento adecuado de su tema.

Hoy vamos a abordar la solución de este problema usando Git y Deploybot para automatizar su proceso de implementación.

¿Qué es la implementación automatizada?

Una implementación automatizada básica tiene cuatro piezas, como se muestra en este diagrama.

La mayoría de los desarrolladores comienzan solo con su código y el servidor. Realizan cambios en su copia de trabajo del sitio y luego envían esos cambios directamente al servidor a través de FTP. Herramientas como Coda o Dreamweaver tienen integración FTP directa para que pueda hacer esto desde dentro de su entorno de codificación.

El siguiente paso que toman muchos desarrolladores es agregar un sitio de prueba para que no modifiquen el servidor en vivo directamente. Puedes hacer esto con algo como VVV o MAMP. A menudo, esto también significa que está utilizando un sistema de control de versiones como Git para administrar los cambios que realiza en su sitio de trabajo local.

Cuando agrega un sitio de ensayo, también agrega complejidad. ¿Cómo obtiene los cambios de código de su sitio de trabajo local a un sitio de prueba donde su cliente puede ver los cambios? Sí, como ya dije, puede usar un cliente FTP básico como FileZilla, Transmit o Forklift para mover los archivos a medida que realiza cambios, pero esto es propenso a errores y aquí es donde la automatización de su proceso de implementación le ahorrará mucho tiempo.

En lugar de tomar los archivos que cambia y enviarlos a su servidor de ensayo, utiliza otro sistema para detectar automáticamente los cambios en su repositorio de Git y enviar solo esos cambios al sitio de ensayo que su cliente puede usar para verificar el trabajo.

Sin embargo, eso todavía deja su sitio en vivo como una implementación manual, lo cual es mucho más aterrador porque puede significar la pérdida de dinero real si elimina un sitio de trabajo en vivo. En su lugar, supongamos que va a configurar su sistema de implementación para que se implemente automáticamente en el ensayo, y luego su sistema se implementará con un solo clic en el entorno en vivo cuando esté listo para comenzar.

Así que ahora tienes un sistema que se ve así.

Profundicemos para poder mostrarle cómo configuro este proceso de implementación para cada cliente con el que trabajo. Estos son los pasos que doy tan pronto como empiezo un nuevo proyecto. Siempre me aseguro de que mi proceso de implementación esté configurado y funcionando antes de comenzar a realizar cualquier otro trabajo en un proyecto de cliente.

Cómo estructurar su repositorio Git

Su primera elección es, ¿en qué directorio configurará su implementación automatizada? A menos que mi cliente solicite específicamente ese control completo de la fuente para su instalación de WordPress, uso el directorio wp-content para configurar mi sistema de implementación automatizado. Eso comienza en la terminal emitiendo este comando que inicializa un repositorio de git.

iniciar git

Ahora es el momento de ignorar los archivos que no querrá implementar todo el tiempo. Estos son archivos como archivos de copia de seguridad, imágenes y cualquiera de los archivos de proyectos personalizados que muchos editores de código agregan a un directorio. Puede ver mi archivo .gitignore habitual a continuación.

config/app_config.yml

config/base de datos.yml

config/*.esfinge.conf

config/s3_credenciales.yml

*~

*.cache

*.Iniciar sesión

*.pid

tmp/**/*

.DS_Tienda

db/cstore/**

db/esfinge/**

documento/api

documento/aplicación

doc/complementos

doc/*.punto

cobertura/*

db/*.sqlite3

*.tmproj

*.¿sudoeste?

*.esproj

_notas*

dwsync.xml

podcast.xml

*.kpf

*sube/*

*.swp

*.ocurrencia

*.sublime-proyecto

*.sublime-espacio de trabajo

*/node_modules/*

etiquetas

*.bak

cache/*

gestionarwp/*

mu-complementos/*

dp.php

corriente ascendente/*

idiomas/*

db.php

plugins/wp-rocket/cache.json

Siéntase libre de agregar o quitar de esto según sea necesario. Casi todos los proyectos en los que trabajo necesitan algún tipo de entrada personalizada para ignorar algún archivo que sea específico de mi sitio de trabajo local para el cual los sitios de prueba y en vivo tendrán su propio archivo personalizado que no quiero sobrescribir.

A partir de aquí, es hora de configurar las sucursales que necesitará para poner en marcha su sistema de implementación. Yo uso dos ramas principales. Primero está la rama maestra que corresponde a mi sitio de producción en vivo. En segundo lugar, es una rama que llamo preparación y corresponde al sitio de preparación que quiero que mi cliente use como una forma de verificar los cambios que estamos haciendo.

Cuando inicializaste tu repositorio de Git, ya obtuviste tu rama maestra, así que usa este comando para agregar una rama provisional y compruébalo.

git checkout -b puesta en escena

Este comando crea y verifica una nueva rama. Si es nuevo en git, puede encontrar más información sobre los comandos disponibles en la documentación de Git.

Ahora deberá insertar su proyecto en su sistema de control de código fuente. Github y Bitbucket son dos opciones populares que funcionan con el sistema de implementación automatizado que usaremos llamado Deploybot. Cuando cree un nuevo repositorio con cualquiera de los sitios, le darán más instrucciones para agregar su repositorio local a su versión en línea en Github o Bitbucket.

• Documentación de configuración del repositorio de Bitbucket
• Documentación de configuración del repositorio de Github

Configuración de Deploybot

Cuando comencé a trabajar en un trabajo más complejo como desarrollador, mi amigo Duane seguía recomendándome Deploybot cuando me quejaba en línea por estropear la implementación manual de FTP. Me tomó una serie de recomendaciones antes de que finalmente hiciera lo que me dijeron, pero ahora he sido un cliente feliz de Deploybot durante años.

Si bien hay otras formas de implementar sus sitios, muchas de ellas implican la interfaz con Git Webhooks o algunos archivos de configuración de implementación automatizados a través de su editor de código. Hay mucho poder en esas otras herramientas, pero si recién está comenzando con la implementación automatizada, entonces ir con algo sencillo como Deploybot es el lugar para comenzar.

Para comenzar, regístrese para obtener una cuenta de Deploybot y conecte Github o Bitbucket a su cuenta. Usaré mi cuenta actual de Bitbucket hoy. Comience agregando un nuevo repositorio a su cuenta de Deploybot.

Una vez que haya encontrado el repositorio que desea configurar para la implementación automática, haga clic en el botón etiquetado como conectar en la parte inferior de la página. Esto lo enviará de vuelta a la página de su repositorio mientras Deploybot termina de inicializar su repositorio. Por lo general, esto se hace en uno o dos minutos, así que llene su café y regrese para terminar de configurar su proceso de implementación.

Una vez que su repositorio esté configurado, haga clic en él para ir a su página principal. Dado que aún no hemos configurado la información de sFTP, tendrá un cuadro grande que le indicará que configure un servidor. Haga clic en el botón para crear un entorno y un servidor.

Comencemos con la implementación en nuestro entorno de prueba. Así que etiquete su servidor como puesta en escena. Elija la implementación automática y asegúrese de configurar la rama en preparación.

Cuando haya terminado, haga clic en el botón Guardar en la parte inferior de la página para pasar a la configuración de su servidor.

En la página siguiente, etiquételo nuevamente como un servidor de prueba e ingrese la información de sFTP de su sitio. Si no está seguro de dónde encontrarlos, lea esta útil guía.

Con su información de sFTP ingresada, puede desplazarse hacia abajo y guardarla. Deploybot luego probará su conexión para asegurarse de que la información que proporcionó funcione. Ahora es el momento de hacer nuestra implementación inicial para el sitio para asegurarnos de que todo funcione. A menudo agrego un archivo test.txt a la implementación como una manera fácil de verificar que la implementación funcionó correctamente.

Para comenzar su implementación en el historial de su entorno, haga clic en implementar.

Ahora verá una página con su último mensaje de confirmación de git como la nota que verá dentro de Deploybot junto a esta implementación. Para cambios grandes, cambiaré esto, pero si solo estoy cambiando CSS o algo menor, el mensaje de confirmación puede permanecer. Dado que esto es una etapa, cada confirmación individual a nuestra rama de preparación se implementará automáticamente, lo que significa que sus mensajes de confirmación serán los que se mostrarán. Es solo la confirmación inicial que debemos hacer manualmente en nuestro sitio de ensayo.

Ahora verifique que sus archivos se hayan publicado en el sitio provisional y que podamos configurar la implementación en vivo.

Para su implementación en vivo, asegúrese de no elegir la implementación automática y asegúrese de elegir la rama maestra como la fuente de su implementación. Queremos que esto sea una implementación manual cuando estemos listos para enviar cambios a nuestro sitio en vivo.

Para hacer esto, deberá verificar su rama maestra y luego fusionar sus cambios de su rama provisional en la maestra.

Puedes hacerlo con estos comandos.

maestro de pago de git

puesta en escena de git merge

maestro de origen git push

Ahora, cuando vaya a su cuenta de Deploybot, podrá implementar manualmente sus cambios tal como lo hicimos con nuestra implementación inicial en nuestro entorno de ensayo. Para su entorno en vivo, asegúrese de cambiar el mensaje de implementación para que se adapte a los cambios que se están enviando a su sitio en vivo. También debe crear una copia de seguridad de su sitio. Puede hacerlo accediendo a la navegación de copias de seguridad en su sitio y luego creando una copia de seguridad manual.

Eso es todo, tiene la configuración de su sistema de implementación automatizado para entornos de prueba y en vivo.

Otras consideraciones de implementación

Si bien este sistema es un gran paso adelante para la mayoría de los desarrolladores, no está exento de problemas. El más grande es que si tiene un montón de cambios, todavía está esperando que FTP termine de transferir los archivos que han cambiado. Esto puede significar que alguien visita su sitio y no todos los archivos que su sitio necesita para funcionar están presentes.

Para muchos clientes, esto no será un problema, pero si es para su sitio, deberá considerar la configuración de un sistema de implementación Atomic. Este tipo de sistema de implementación mueve todos los archivos, verifica que estén funcionando correctamente y luego cambia la configuración de los archivos en su servidor para que el nuevo directorio sea ahora el que ejecuta su sitio.

El proceso de vinculación a una nueva carpeta toma tan poco tiempo que solo una computadora lo notaría. Eso también significa que si encuentra un problema más tarde, puede cambiar el enlace de su sistema a la versión anterior del sitio para volver a la versión que estaba funcionando. De nuevo, esto solo requiere una cantidad de tiempo muy breve y reduce el tiempo de inactividad.

Independientemente de lo que elija hacer, deje de usar un cliente FTP para implementar sus archivos de cliente hoy. El pequeño costo mensual de Deploybot se recupera cada vez que no comete un error al implementar sus archivos.