GITHUB ACTIONS

FIS. Grupo 2. Proyecto Coffaine.

Contenido

• Github actions
  • Conceptos
  • Uso específico para Node.js
• Github actions en Coffaine
  • Visualización del estado de workflows
    • Frontend común
    • Microservicios
  • Configuración
    • Repositorio
    • Dockerfile
    • Variables de entorno
    • Github actions for Testing
    • Despliegue

Github actions

Fuente principal: https://docs.github.com/en/actions

Conceptos

Actualmente, se muestra como estándar el uso de una plataforma intermedia entre el servidor y el sistema de control de versiones para manejar el proceso de despliegue continuo. En nuestro caso para explicarlo, vamos a dar por hecho que se utilizarán Heroku y Github respectivamente. De esta manera, si lo configurásemos de la “manera tradicional”, Github suministraría el código desde los repositorios, donde podría a disposición de Travis CI los ficheros de configuración para el despliegue, a partir de ellos, Travis CI automatizará el proceso hasta desplegar nuestra aplicación en Heroku.

Figura 1. Travis como método tradicional al uso de Github actions

Frente a ello, surge por parte de github, Github actions , una herramienta que nos permiten realizar el mismo proceso ahorrándonos el paso intermedio de Travis, además de ofrecer funcionalidades adicionales. Y especificando todos los pasos con un simple fichero de configuración en formato. yaml.

Figura 2. Github actions

La automatización es la clave para agilizar los procesos de trabajo y Github actions es la mejor manera de potenciar un flujo de trabajo en github, ya que le permite crear flujos de trabajo para ciclos de vida de desarrollo software personalizados, además de poder realizarlo directamente dentro del repositorio de github.

Github actions está totalmente integrado en github. Está construido integrando desde el Merge box hasta las pruebas de verificación. Y desde la interfaz de usuario a la API, como se puede ver en la siguiente figura.

Figura 3. Integración de funcionalidades de github

Github actions funciona de la misma manera que github, y como sirve de apoyo a todos los flujos de trabajo de desarrollo de software, además de automatizarlos, almacena el código y da soporte para la colaboración en pull requests e issues dentro de la misma plataforma.

Este permite descubrir, crear y compartir actions o acciones a través de su marketplace, para realizar, esencialmente, cualquier trabajo que quieras. Incluyendo CI y CD y acciones combinadas tanto propias como del Marketplace, se puede personalizar completamente el flujo de trabajo.

Así que, para visualizar cómo esto puede ser útil. Vamos a echar un vistazo rápido a la metodología para el flujo básico de Github: Github Flow.

Este es un flujo de trabajo ligero y eficaz basado en ramas, comúnmente utilizado en github, que después nos servirá para ver cómo las acciones de github encajan en él.

Figura 4. Github flow (1)

El primer paso para cuando queremos hacer cambios en el código en nuestro repositorio de github es crear una “feature Branch” de la rama principal o la rama de producción, es decir, bifurcar la rama principal y crear una copia de ella teniendo como título el de la feature que queremos desarrollar, para posteriormente realizar los commits pertinentes asociados a dicha funcionalidad.

Cuando terminamos de desarrollar y por tanto finalizamos esta feature, abrimos un pull request en github para compartir nuestros cambios.

Figura 5. Github flow ( 2 )

Una vez revisada y aprobada la pull request, fusionamos esta rama en la rama principal, y luego eliminamos nuestra feature branch.

Figura 6. Github flow ( 3 )

Teniendo claro la metodología a seguir a la hora de desarrollar dentro del proyecto, ¿en qué punto Github actions entra en juego?

Figura 7. Github flow + actions (1)

La ventaja de las acciones de github es que en cualquier etapa de Github Flow se pueden aplicar las acciones de github existentes o incluso crear tus propias acciones de github.

En este documento vamos a tratar específicamente la inclusión del CI/CD a través de Github actions, ya que será lo que posteriormente apliquemos al proyecto de Coffaine.

Existen tantas alternativas de configuración en github actions, que permite automatizar cualquier parte del proceso. Por ejemplo, si se quiere ejecutar un automatizado específico cuando una issue abierta, etiquetada de una forma concreta, se cierra.

Figura 8. Github flow + actions ( 2 )

Otro ejemplo sería para una pull request que está abierta y se quiere que se creen recordatorios automatizados, basados en etiquetas o en revisores específicos. Con esto se pretende ilustrar que las acciones son capaces de automatizar workflows personalizados en cualquier punto del ciclo de vida del desarrollo del software, de manera directa desde el repositorio de github.

Figura 9. Github flow + actions ( 4 )

Las acciones de Github son impulsadas por eventos, lo que significa que se puede ejecutar una serie de comandos después de que un evento específico haya ocurrido. Por ejemplo, cada vez que alguien crea un pull request para un repositorio, se puede ejecutar automáticamente un comando que ejecute un script de pruebas de software. En lugar de utilizar integraciones CI o CD, como es el caso de Travis, con github actions puedes hacer los build entre otras funcionalidad, directamente en el repositorio github.

Figura 10. Github events (1)

Esto da máxima libertad para personalizar, ya que las acciones trabajan sobre una tarea automatizada a lo largo del ciclo de vida de desarrollo de software.

Ahora se muestra dónde podemos aplicar la automatización utilizando acciones de github dentro del workflow de desarrollo de software. Se exponen de una manera más cercana cómo las acciones de github funcionan.

Figura 11. Github events ( 2 )

Las acciones de Github utilizan la sintaxis yaml para definir los eventos, trabajos (jobs) y pasos (steps). Estos archivos yaml se almacenan en el repositorio de código, en el directorio llamado .github/workflows.

Un evento desencadena automáticamente el workflow que contiene un trabajo.

Figura 12. Github events ( 3 )

Los jobs utilizan los steps para controlar el orden de ejecución de las acciones. Estas acciones son los comandos que automatizan aquello que deseamos, como el caso de las pruebas de software.

Por lo tanto, en este flujo de trabajo de ejemplo, se activa automáticamente una serie de comandos, cada vez que el código es pusheado. Github actions “checkea” el código pucheado , e instala las dependencias de software y ejecuta "bats -v", para dar salida a la nueva versión del software.

Figura 13. Github events ( 4 )

Con github actions, también puedes construir, probar y publicar a través de múltiples plataformas de sistemas operativos y lenguajes, todo dentro del mismo flujo de trabajo. Por ejemplo en este se hace uso de la última versión de Ubuntu, tal y como se especifica en el “runs- on”.

Figura 14. Github actions cross-platfom

y luego ver las comprobaciones de estado mostradas dentro de tu solicitud de extracción.

Figura 15. Github pull request actions state

Con las acciones de github, se tiene la posibilidad de crear acciones propias o aprovechar acciones pre-construidas por la comunidad que se encuentran en el marketplace de github. Por lo tanto, es la solución perfecta si se desea personalizar y automatizar un workflow para llevarlo desde una idea a producción.

Uso específico para Node.js

Para la aplicación de github actions en nuestro proyecto, que se basa en node, hay que seguir una plantilla específica para node.js.

# This workflow will do a clean install of node dependencies, build
the source code and run tests across different versions of node

name: Node.js CI

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  build:

  runs-on: ubuntu-latest

  strategy:
    matrix:
      node-version: [10.x, 12.x, 14.x, 15.x]

  steps:
    - uses: actions/checkout@v
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v
        with:
          node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Para elegir la versión exacta de Node.js para construir y realizar los test utilizaremos:

strategy:
  matrix:
    node-version: [8.16.2, 10.17.0]

Para instalar las dependencias utilizaremos npm install , que instalará las dependencias especificadas en el archivo package.json definido en la raíz del proyecto.

steps:
- uses: actions/checkout@v
- name: Use Node.js
  uses: actions/setup-node@v
    with:
      node-version: '12.x'
- name: Install dependencies
  run: npm install

A continuación vemos el ejemplo concreto que aplicación de Github actions en el proyecto Coffaine.

Github actions en Coffaine

Visualización del estado de workflows

Figura 16. Estructura de Coffaine

Frontend común

Debido a la estructura de este proyecto, como se puede ver en la Figura 16 , tendremos que tener en cuenta las acciones para un repositorio de frontend, que será el que se comunique con el API GATEWAY para acceder a los recursos proporcionados por cada microservicio. Por lo que se podrá ver es estado de los workflows asociado al repositorio de frontend.

Figura 17. Workflows en repositorio de frontend

Microservicios

Para cada uno de los cuatro microservicios, gracias a la coherencia entre tecnologías y estructura entre los diversos grupos de trabajo, se ha configurado las actions de github de manera análoga, por lo tanto el estado de sus workflows son análogos a los de la siguiente figura.

Figura 18. Workflow en repositorio de cada microservicio

Configuración

Repositorio

Crear directorio .github/workflows donde añadiremos los ficheros de configuración para cada una de las acciones.

Dockerfile

Github podría encargarse de la build directamente, sin embrago, en nuestro caso hacemos uso de la definición de Dockerfile para que se realice el despliegue en Heroku utilizando Docker.

Figura 19. Definición del Dockerfile

Variables de entorno

Este paso es muy importante para la correcta ejecución de github actions. Añadiremos dos variables de entorno como secretos de github para utilizarlas desde los scripts:

• HEROKU_API_KEY
• HEROKU_EMAIL

Figura 20. Secretos de github

Figura 21. Procedencia del secreto: Heroku

Github actions for Testing

Figura 22. Yaml configuration file to test app

En este script especificamos que para cada pull request que se realice, se ejecutarán los test en un entorno con sistema operativo Ubuntu en la última versión disponible. Con el “strategy: matrix” especificamos la versión concreta de node con la que queremos que se ejecuten los test. Y posteriormente detallamos los pasos a seguir en el job, en los que hacemos uso de las actions del Marketplace: “checkout” y “setup-node” con las versiones 2 y 1 respectivamente.

Figura 23. Github Marketplace

Vemos que en caso de “setup-node”, dentro del with especificamos la versión concreta de node con la que queremos que se ejecute, previamente definida en el “strategy: matrix”.

Finalmente ejecutamos el comando necesario para instalar las dependencias y correr los test especificando en el “env:” las variables de entorno necesarias para su ejecución, las cuales se tomarán del settings de github, definido como se indica en el apartado Variables de entorno.

Despliegue

Figura 24. Yaml configuration file to deploy app

En este caso, se define el script de despliegue, que se ejecutará cada vez que se realice un push a la rama main , como se indica en las líneas [3-5] de la Figura 24.

Análogamente al caso anterior con el fichero de configuración para las pruebas, se define en el “steps”, los pasos a seguir cuando se ejecute el job. Aquí, primero se llama a la acción “checkout” que fija el código del repositorio para que se confirme el acceso del github actions al mismo. Y la acción de “heroku-deploy” que es una acción de GitHub muy sencilla que permite desplegar en Heroku. La acción funciona ejecutando los comandos asociados al despliegue de heroku en el shell a través de NodeJS. Para el correcto funcionamiento de esta acción es necesario indicar los valores que se recogen en el “with” en la configuración de los secretos del repositorio, como se indica en el apartado Variables de entorno.