El despliegue de una aplicación web, es lanzar (hacer “push”) la aplicación, los cambios, o actualizaciones de un entorno a otro, para que esté disponible para el público o para un equipo de trabajo específico para su uso o pruebas.

Al configurarse un sitio web, este tendrá el sitio en vivo, entorno en vivo o entorno de producción.

¿Cómo era el despliegue antes?

La forma tradicional de un sitio web era crear las diferentes páginas html en el entorno de desarrollo, con la respectiva funcionalidad, que se ejecutaba en el cliente. En el entorno de producción (servidor web, el despliegue se realizaba usando un cliente ftp, para subir los ficheros al servidor).

Entornos de trabajo utilizados

Se pueden tener varios entornos como el local, o el de desarrollo, para que en este último se publiquen ahí los cambios, para realizar las respectivas pruebas antes de moverse a producción.

Los entornos adicionales pueden ser un entorno de preparación (también conocido como sitio de preparación o staging). La cantidad de entornos necesarios depende del equipo de trabajo y de la complejidad del proyecto en el que se esté trabajando.

Pasos en el flujo de despliegue

Se pueden destacar 5 pasos en el proceso de despliegue de nuestras aplicaciones:

Planeación. El plan debe incluir reglas sobre cuándo implementar desde los diferentes entornos, al entorno en vivo o producción. Tener un plan, reduce el riesgo de conflictos entre los diferentes cambios y se asegura de que el proceso de implementación sea lo más fluido y sencillo posible.
Desarrollo. Una vez se determina el plan se procede a desarrollar las diferentes tareas de la aplicación, en el entorno local o de desarrollo. Finalizado el proceso de desarrollo, se realizan las pruebas de código.
Pruebas. Probar los cambios es crucial para asegurarse de que ningún error llegue al entorno de producción final. Una vez probados los cambios en el entorno local o de desarrollo, se pueden implementar los cambios en el siguiente entorno (como el de ensayo o staging), donde se deben realizar las pruebas de control de calidad finales. Una vez probado todo se implementa en vivo.
Despliegue en el entorno en vivo. Terminadas las pruebas y solucionados los errores, se procede a implementar los cambios en el entorno en vivo.
Monitoreo de los cambios. Estando los cambios en el entorno de producción, es muy importante monitorear constantemente la aplicación para evitar que los usuarios tengan una mala experiencia con ella. Es recomendable al momento de realizar el despliegue a producción realizarse en una hora que no perturbe a muchos usuarios, para realizar las respectivas pruebas en el entorno y que de esta manera se pueda solucionar rápidamente el problema o se puedan revertir los cambios a tiempo.

¿Cuáles son las ventajas del despliegue en múltiples entornos?

Se reduce el riesgo en el que la aplicación se rompa. Esta es una principales razones para usar múltiples entornos, de esta manera se reduce el riesgo de que los cambios tengan un impacto negativo.
Ahorro de tiempo. Sin la preocupación de que se rompa algo, se puede optimizar el flujo de trabajo para realizar los cambios. Si está trabajando en el entorno local, los cambios se procesan más rápido y a la hora de la implementación, se ahorra tiempo.
El contenido prioritario es fácil de administrar. Hay contenido que puede tener mucha mayor prioridad y ser sensible para algunos usuarios, el poder realizar el despliegue en diferentes entornos para realizar las pruebas pertinentes, ayuda que se pueda cumplir en plan de despliegue al entorno de producción, de forma efectiva.

Github Actions

Nos permite realizar el despliegue de nuestros proyectos de forma automatizada, desde nuestro repositorio en Github.

Pero no solo permite ayudarnos con nuestro despliegue, Github Actions es una herramienta gratuita, para automatizar flujos de CI/CD de nuestros repositorios.

¿Qué es CI/CD?

Es una práctica recomendada de las metodologías ágiles, que implementan los equipos de desarrollo junto con la infraestructura, para con ella cumplir los requerimientos, hacer código de calidad y pensar en que la aplicación sea segura de usar.

CI/CD incorpora una automatización continua y un control permanente en el ciclo de vida de la aplicación.

CI — Continuous Integration o Integración Contínua. Se integran los cambios en el código a la rama principal de un repositorio común. Para evitar que cada desarrollador, cree código de manera aislado y que se una todo en el despliegue a producción, se trabaja realizando un flujo de trabajo donde cada desarrollador contribuye a una parte del repositorio, dependiendo de las tareas que deba realizar. Con el CI, las integraciones de código son más rápidas y con mayor frecuencia.
CD —Continuous Delivery/Deployment o Entrega Contínua. Inicia donde termina la CI, el CD automatiza la entrega de aplicaciones a determinados entornos, para permitir implementaciones fáciles y confiables en el entorno de producción. En la Entrega Continua, los despliegues ocurren frecuentemente, al ser automatizados los procesos no se requiere de procesos manuales. Los despliegues a producción no requieren una validación manual, si se identifica una falla en el proceso o se identifica un error este proceso se detiene.

¿Cómo es el CI/CD con Github Actions?

Github Actions, tiene un concepto de workflow (flujo de trabajo), el cual es el encargado de todo nuestro proceso (o Pipeline). Que puede ser configurable, y en donde se puede especificar que se analicen diferentes aspectos del proyecto, para evitar algún error en el proceso.

Workflow: es un procedimiento automatizado el cual se añade a un repositorio. En él se hace el build, test, package, release/deploy de un proyecto.
Job: es un conjunto de steps que se ejecutan en runner de nuestro proceso.
Step: es una tarea individual que puede ejecutar comandos dentro de un job. Un job está formado por uno o más steps y éstos están ejecutados sobre el mismo runner a la hora de ejecutarse el workflow.
Action: son los comandos de ejecución del proceso, ejecutados en un step para crear un job. Se pueden utilizar los actions creados o crear personalizados. Para usar un action en un workflow, se debe incluir en un step.

¿Cómo se crea el workflow?

Para crear nuestro workflow podemos realizar los siguientes pasos:

Primero vamos a crear en nuestro proyecto, en la raíz una carpeta llamada: “.github”.
Dentro de la carpeta “.github”, vamos a crear otra carpeta llamada: “workflows”.
Dentro de la carpeta “workflows”, crearemos un archivo con la extensión, como por ejemplo: build-deploy.yml. Este archivo tiene sintaxis YAML.

El YAML, es un archivo que en su estructura, se basa en espacios y/o tabulaciones, donde se define el flujo de CI/CD. Este archivo puede tener cualquier nombre acompañado de la extensión .yml.

En el archivo se añade la configuración, los pasos que se deben seguir para hacer el despliegue de nuestra aplicación.

Desde la página de Github, es posible crear el archivo con la extensión .yml. En la pestaña de GitHub Actions en nuestro repositorio de GitHub, podemos ver varias plantillas para hacer el despliegue. Para crear una se da clic en el link: “set up a workflow yourself ”.

Se creará un archivo en el cual se puede añadir la configuración y luego se realiza el commit.

¿Qué encontramos en el archivo .yml?

“name: Example”: Es el nombre opcional que se le asigna al workflow.

name: [workflow name]

“on”: Especifica el evento que ejecuta el fichero del workflow. Cómo el push de git sobre nuestro repositorio. Para especificar la rama o ramas, sobre las que nos gustaría que se inicie, sería la siguiente:

on: [push]
Branches: [master o main]

«jobs»: Se especifica uno o más jobs.
«build»: Es el nombre que le hemos dado a nuestro primer y único job. En este caso el nombre sí es obligatorio.
«runs on: ubuntu-latest»: Configura el workflow para que se ejecute en una instancia de la última versión de ubuntu. Se puede cambiar por otro sistema operativo: windows-latest, macos-11.0, etc.
«steps»: Sección donde se especifican uno o más steps de un único job.
«uses: actions/checkout@v2»: uses le dice al job de obtener v2 (versión 2, antiguamente se usaba la v1) de la acción de la comunidad de Github llamada actions/checkout. Éste es un action que comprueba nuestro repositorio y lo descarga en nuestro runner o instancia, permitiendo que sobre el código podamos ejecutar el resto de acciones. Es obligatorio añadir este action de checkout las veces que nuestro workflow ejecute sobre nuestro código o se haga uso de un action que hemos definido en otro fichero del repositorio.
«name: Checkout»: Un nombre opcional que se le ha dado al action.
«uses: actions/setup-node@v1»: Este action se encarga de descargar e instalar una versión específica, en este caso de node.
«run: npm install»: La palabra run le dice al job de ejecutar un comando en el runner. En este caso estamos utilizando npm.

¿Cómo se ejecuta el Workflow?

Para ejecutar el workflow y ver los resultados, es necesario hacer push del proyecto a la rama que especificamos en el archivo de workflow.

En pestaña “Actions”, de Github empezará el despliegue.

Cuando todo el despliegue no ha presentado ningún problema, vamos a ver que todos los checks de los jobs son exitosos.

Conclusiones

Realizar el despliegue de nuestra aplicación es una acción necesaria, además de otros pasos que nos ayudan con la confiabilidad y calidad de nuestro código, y la de nuestro proyecto, a través de las prácticas de CI/CD.

Github nos brinda una herramienta gratuita, para la integración y entrega continua de nuestros proyectos en nuestros repositorios, de manera automatizada, como son los Github actions, que nos brinda un workflow que podemos configurar para que el flujo se ejecute exitosamente en nuestros proyectos.

Github actions, no es la única herramienta que nos permite realizar la práctica de CI/CD, pero es una herramienta fácil de usar para los desarrolladores que tenemos muchos de nuestros proyectos personales en Github, y nos da una gran visibilidad del flujo de trabajo que se realiza en estas prácticas.

Espero este artículo sea de ayuda a los lectores, para que con él comprendan cómo funciona el flujo de trabajo de Github Actions y puedan aplicar estas prácticas en sus proyectos.

Te invito a seguirme en twitter con el handle: @vanessamarely

Recurso para ampliar la información

github actions

workflow syntax for github actions

events that trigger workflows

context and expression syntax for github actions