5 Limitaciones de GitHub Free que debes tener en cuenta

1. Límites de ejecución

GitHub Free presenta varios límites mensuales al uso que se puede realizar de forma gratuita. Estos son:

• 2000 minutos de ejecución de Actions
• 1GB de almacenamiento de Packages
• 0.5GB de almacenamiento compartido de artefactos de Actions y Packages
• 1GB de almacenamiento y ancho de banda de Git LFS (versionado de archivos de gran tamaño)

Naturalmente, los límites relevantes a cada organización dependerán del uso que hagan de GitHub, pero hay uno que destacamos por ser el más universal: el tiempo de ejecución. 2000 minutos al mes, incluso si tenemos en cuenta únicamente 20 días laborables, resultarían en aproximadamente 100 minutos al día. Este es un límite razonable para pequeñas pruebas de concepto, pero en cuanto se empiece a dar un uso real a la plataforma, se convierte en un límite fácilmente alcanzable. Si tenemos en cuenta un tiempo de ejecución medio de un workflow de 5-10 minutos, bastaría con tan solo 10 o 20 ejecuciones al día.

Consideramos que estos límites son los más relevantes ya que, al alcanzarlos, empezaríamos a pagar o, en caso de no haber introducido todavía métodos de pago, el aspecto correspondiente de la plataforma quedaría inutilizado, y esto podría bloquear a los equipos de desarrollo o incluso a las operaciones, si gestionamos nuestra Infraestructura como Código.

2. Protecciones de rama

Mediante GitHub Free, no es posible establecer protecciones de rama, como requerir que cualquier cambio a la rama principal se realice mediante una Pull Request con aprobación de otro miembro del equipo. Estas revisiones de código son esenciales para la calidad de los desarrollos y también son muy útiles para la transferencia de conocimiento entre miembros del equipo.

Además, en el caso de la Infraestructura como Código con integración continua, no podemos impedir cambios en la infraestructura por un cambio realizado directamente sobre la rama relevante.

3. Environments

El concepto de Environments de GitHub ofrece varias funcionalidades útiles, que no podemos aprovechar en GitHub Free. Las más destacables son las reglas de protección de entornos, que nos permiten establecer ciertas condiciones que deben darse antes de permitir cualquier despliegue al entorno mediante GitHub.

Entre las distintas condiciones que podemos establecer, existe una de uso muy frecuente, que es la de requerir la aprobación por parte de una persona u equipo antes de permitir el despliegue. Esta funcionalidad permite establecer una pausa en la ejecución del flujo relevante, que espera hasta la aprobación para continuar con el despliegue. Este paso de aprobación puede ser muy útil para permitir al equipo de desarrollo realizar sus cambios sin impedimentos, al tiempo que se da la responsabilidad final del despliegue a otra persona u equipo. También es muy importante en los flujos de despliegue de Infraestructura como Código mediante Terraform, ya que permite previsualizar los cambios en el plan antes de confirmar su ejecución.

4. Secretos y variables a nivel de organización

En GitHub Free, no podemos configurar secretos y variables a nivel de organización. Esto es muy útil para compartir parámetros, ya sea sensibles o no, que sean relevantes a varios repositorios, como podrían ser las credenciales de acceso al entorno. Sin esta funcionalidad, es necesario configurarlos en cada repositorio que los utilice, requiriendo una intervención constante e incrementando el riesgo de errores y filtraciones.

5. Code Owners

Finalmente, en GitHub Free no podemos establecer Code Owners. Esta funcionalidad permite configurar permisos distintos para partes sensibles del repositorio, requiriendo la intervención de un equipo distinto para la aprobación de modificaciones. Por ejemplo, esto permite establecer que sólo el equipo de DevOps pueda modificar los workflows del repositorio, evitando que el equipo de desarrollo pueda ejecutar código no permitido o incluso malicioso mediante los mismos.

¿Cuáles son mis opciones?

Si crees que alguna de estas limitaciones puede afectar a vuestro proyecto, deberías tener en cuenta las distintas opciones de pago disponibles:

A corto plazo, existe una opción de prueba de la versión Enterprise, que podéis aprovechar durante un mes, preferiblemente al alcanzar uno de los límites mencionados, antes de tomar una decisión definitiva.

Naturalmente, existen alternativas a GitHub. Podríais disponer de otro sistema de control de versiones, así como de CI/CD, alojado en vuestra propia infraestructura, o proporcionada por otro proveedor, como Azure DevOps o GitLab. Pero, en la decisión final, deberíais incluir el coste completo de todas las opciones, incluyendo el coste de la infraestructura, el licenciamiento de las soluciones utilizadas, y el coste de desarrollo o configuración de pipelines, especialmente si ya hay trabajo realizado sobre GitHub. También deberíais valorar si la alternativa dispone de algunas de las características de GitHub que podáis estar utilizando.

Conclusión

En definitiva, el uso de GitHub Free puede ser muy recomendable para las primeras etapas de un proyecto, ya que permite centrarse en el desarrollo del producto, reduciendo la inversión en tiempo y coste necesaria para lanzarlo. Pero, al apostar por esta opción, debemos hacerlo siempre con pleno conocimiento de sus limitaciones, para poder anticiparnos a ellas y evitar que nos causen problemas en el futuro.

Autor: David Lecina, Specialist Lead