En octubre, GitHub anunció que su última gran característica, GitHub Actions, iba a ser beta pública. En ese momento no tenía muy en claro de qué consistía, pero después de leer la publicación en su publicación de blog me pareció bastante simple. GitHub Actions es la respuesta a las principales características de su competidor: La función Auto DevOps de Gitlab.
Hace poco creé mi propia cuenta personal en Gitlab solo por el hecho que GitLab me ofrecía una forma muy fácil de automatizar mi proceso de compilación y despliegue de una aplicación simple de una página en React usando tan solo un archivo .gitlab-ci.yml
Sin embargo, cuando obtuve acceso al beta de GitHub Actions tenía que darle un intento. Así que decidí construir algo similar.
¡Muéstrame el código!
Si ya tienes una idea de qué acciones son y solo quieres ver el código relacionado, siéntete libre de explorar el repositorio para este artículo en el siguiente enlace: https://github.com/pedsm/tryGithubAction
Un breve descargo
Toda mi experiencia con GitHub Action hasta el momento está basada en su versión beta, así tenlo en consideración. Pueda que muchas de las cosas de las que hablo aquí no sean liberadas en versión final, además ignoraré los errores y comportamientos raros que he ido encontrando.
¿Qué es?
GitHub Actions te permite automatizar tareas a ser completadas cuando algo sucede en tus repositorios (como pushes, issues, versión y demás). Esto significa que puedes configurar tu repositorio de manera tal que pueda ser automáticamente probado y desplegado cada vez hay un nuevo commit, que es exactamente lo que yo hice.
Como ya mencioné, la única razón por la que decidí crear una cuenta en GitLab fue la posibilidad de tener un flujo de trabajo en el cual todo nuevo código agregado al Master sea desplegado directamente al sitio web, entonces decidí recrear esto exactamente.
La Configuración
Una vez que tienes acceso a GitHub Action, verás una nueva pestaña con el nombre de Actions en tus repositorios. En ella podrás crear tu primer flujo de trabajo. Un flujo de trabajo es un archivo de flujo de trabajo que vive dentro del .github que ya se usa para otras cosas, como plantillas de relaciones públicas y otras configuraciones de GitHub específicas del repositorio.
GitHub Actions viene con un editor gráfico completamente equipado para tus flujos de trabajo. Esto es un soplo de aire fresco si pensaste que ibas a tener que aprender un nuevo esquema YAML or algún lenguaje específico a la tecnología como en el caso de Jenkinsfile. Por otro lado, si no quieres usar ninguna de estas alucinantes herramientas gráficas siempre puedes editar el archivo .workflow a tu gusto.
Los archivos de Workflow usan el lenguaje de configuración HashiCorp(conocido también como HCL). Si conoces de Terraform, este lenguaje se te hará familiar.
Las diferencias
Si has implementado algún tipo de prueba automatizada, todo esto se te hará muy familiar. Quizá aparte de tener acceso a un editor gráfico. De todas maneras, encontraremos menos similitudes a medida que avancemos.
GitHub Actions, como el nombre lo sugiere, es una serie de actions que son ejecuciones de comandos individuales, lo cual es bastante inusual. Si le prestas atención al archivo de flujo de trabajo, habrás notado que la definición de las acciones tiene un parámetro uses. Si usas una acción npm podrías crear una solo tarea NPM como npm install y luego otra acción para hacer la prueba npm test. Esto es inusual, ya que algunas tareas lógicas como "instalar dependencias" podrían requerir más de un comando y usualmente están agrupadas en "Etapas" en otras soluciones de integración continua.
Al usar el editor gráfico y agregas una nueva acción, lo primero que se te muestra es una lista de acciones disponibles. Luego aparece un formulario simple en el cual solo debes ingresar texto en los campos label, args y run.
El campo label, como podrías inferir, es solo un nombre amigable para lo que hace tu acción, como por ejemplo "Testing". La acción luego realizas un ‘runs args’ en la terminal considerando que runs no está siendo sobreescrito. Esto significa que para ejecutar npm install en una acción que use npm, tendrías que dejar el campo runs con el texto por defecto (vacío) y en el campo args escribir install
A este momento me provoca un poco de decepción, porque al parecer GitHub quiere restringir la funcionalidad de esta característica a solo las cosas que la plataforma determine. Npm está disponible por el momento, pero si usas pip para tu proyecto en Python entonces tendrás que implementar una acción propia o buscar una alternativa de código abierto. Ya es posible crear tus propias acciones personalizadas, pero dado que aún está en su versión beta es poco probable que encuentres gran variedad. Mirando el lado positivo, si tenían las dos cosas que necesitaba, NMP y Heroku.
El Proyecto
La idea del proyecto es bastante simple: Quería construir una aplicación en Vue(ya que es lo que estoy aprendiendo actualmente) y tener un despliegue automático a un servicio de alojamiento.
Después quería crearlo de manera que el contenido del sitio web refleje un archivo json con una serie de nombres de usuario de GitHub. De esta manera cualquier podría crear un PR con su nombre de usuario de GitHub y yo podría darle clic a un botón y tener todo desplegado mágicamente.
Omitiré todo el contenido en Vue.js e iré directamente a los Actions. Luego de construir esta simple aplicación, sólo tenía que hacer las siguientes acciones:
- Instalar las dependencias
- Ejecutar los linters (muy importante para prevenir cualquier mala estructura en el archivo json)
- Construir el código listo para ir a producción
- Desplegar en algún sitio web. (Decidí usar Heroku ya que parece ser el menos complicado en términos de servidores y que hay acciones disponible para esta plataforma).
Con los 3 primeros pasos tuve la experiencia más intuitiva automatizando cualquier cosa. Me recordó mucho a la plataforma IFTT. Solo tienes que darle clic a la acción NPM y luego escoger que quieres que NPM haga. Sé que mencioné que me sentí un poco restringido al solo tener una par de acciones, pero la realidad es que en ningún momento tuve que preocuparme sobre la distribución de Linux que estaba usando, si NPM estaba empaquetado con la instalación Node.js, y lo más importante cero preocupación si es que la sintaxis HCL estaba correcta. Un par de clic en la interfaz gráfica y listo. El proceso completo tomó 4 acciones y menos de 5 minutos.
Luego pasé a la fase de despliegue. Sabía que esta iba a ser un poco más complicada, porque a pesar de saber cómo funciona Heroku, nunca antes lo había utilizado. Sin embargo, en el repositorio actions/heroku encontré instrucciones claras que me ayudaron a hacer exactamente lo que quería hacer. Al final, fue un tema de más clics y listo.
Secretos
Creo que esté el momento perfecto para hablar sobre mi funcionalidad favorita de GitHub Actions, los secretos. Como podrás suponer, Heroku requiere una API Key para poder permitirle a alguien desplegar la aplicación. De lo contrario, cualquiera leyendo este artículo podría reemplazar mi aplicación con lo que le plazca. Usualmente, esto es algo molesto al encargarse de un proyecto de código abierto, ya que no puedes almacenarlo dentro del mismo repositorio. AWS tiene incluso un servicio dedicado a esta clase de problema. A pesar de ellos, GitHub ha implementado una elegante solución a este problema.
Los secretos son valores que puedes almacenar al mismo nivel del repositorio y que será automáticamente encriptados y luego enviados como variables de entorno a las acciones que definas que tengan acceso a estos valores.
Si le has pegado una mirada al repositorio de la acción de Heroku, te habrás dado cuenta de que HEROKU_API_KEY está listado como un secreto requerido. El proceso para hacer esto en el editor es tan simple como darle clic a *new secret*, y luego darle un nombre y valor. A partir de ellos, puedes marcar el checkbox para cualquier acción que quieras que tenga acceso a esta información.
Ya que estos secretos se convierten en variable de entorno, no te quedas limitado a las acciones. Por ejemplo, tu framework de pruebas podría recibir las credenciales para un base de datos ya existente para guardar los resultados de tus pruebas, entonces podrías enviar estos secretos mediante una acción npm test.
Env
Env es otra opción dentro del editor gráfico que básicamente hace lo mismo que Secrets, pero omite todos los malabares de encriptar tu información. No es un gran problema, ya que la información no sensible podría ser almacenada en un archivo .env dentro del mismo repositorio.
Mis reflexiones sobre GitHub Actions
GitHub Actions no está haciendo nada novedoso. Hay docenas si no cientos de soluciones disponibles ya sea comerciales o gratuitas que hacen lo mismo que hace Actions. Incluso GitHub tiene toda una categoría de marketplace para la automatización de tareas para tu repositorio.
Sin embargo, personalmente nunca he tenido tan buena experiencia de usuarios configurando una canalización de CI/CD. GitHub actions no está reinventando la rueda, solo la está haciendo más económica.
Como desarrolladores, siempre tenemos que encontrar el balance entre simplicidad de uso y cuántas funcionalidades queremos agregarle a algo. El eternos dilema entre usar la terminal de Git o su interfaz gráfica. Por otra parte, GitHub está súper consciente de lo que el mercado tiene disponible y que ellos no están tratando de ser competidores de los grandes. No, no te vas a deshacer de Jenkins, Circle o cualquier otra solución que tu organización esté ya usando. Pero si tienes un pequeño proyecto propio, definitivamente vale la pena darle una chance con GitHub Actions.
Contribuye
Todo el código para éste artículo es abierto y disponible en https://github.com/pedsm/tryGithubActions. Si deseas registrar algún issue y agregar tu usuario de GitHub al proyecto, siéntete libre de crear un PR.
Traducido del artículo de Pedro Mendonça - A first look at GitHub Actions with Heroku de Pedro Mendonça