- GitHub es el eje donde se versiona y coordina tanto el código de aplicación como la infraestructura como código.
- Herramientas como Terraform, Ansible, Chef, Vagrant y GitHub Actions permiten automatizar aprovisionamiento y despliegues.
- GitHub Pages y el agente de modernización de Copilot amplían el uso de GitHub para sitios estáticos y migraciones a Azure.
- En la formación universitaria, GitHub se usa para proyectos DevOps que integran virtualización, CI/CD y despliegues en la nube.
Cuando empiezas a trabajar con infraestructura como código e integración con GitHub enseguida aparecen las dudas: ¿mezclo Terraform o CloudFormation con el código de la app? ¿Creo repositorios separados? ¿Cómo encajo todo eso con GitHub Actions, GitHub Pages o herramientas como Ansible, Chef o Vagrant? La realidad es que detrás de GitHub y su ecosistema hay todo un mundo de prácticas, tecnologías y flujos de trabajo que merece la pena conocer con calma.
En este artículo vamos a recorrer, con bastante detalle, cómo se suele organizar la infraestructura en GitHub, qué herramientas se usan alrededor (Terraform, Ansible, Chef, Vagrant, contenedores, Azure, etc.), cómo se relacionan con GitHub Pages o GitHub Copilot, y qué está haciendo la propia GitHub y el mundo académico para enseñar estas prácticas en proyectos reales y en la nube.
Qué es GitHub y por qué es clave para la infraestructura
GitHub es una plataforma de alojamiento de repositorios Git que se ha convertido en el estándar de facto para proyectos de código abierto y privados. Permite trabajar con cualquier lenguaje, integrar herramientas de CI/CD, gestionar issues, revisiones de código y, sobre todo, centralizar el ciclo de vida de aplicaciones e infraestructura.
A nivel profesional, muchos desarrolladores ven GitHub como el heredero natural de SourceForge. Durante los años 2000, SourceForge fue el gran repositorio de proyectos open source, pero la popularidad de Git frente a sistemas como SVN o CVS, sumada a la mejora de experiencia de uso, hizo que la mayoría de proyectos acabase migrando a GitHub. Hoy en día, tanto grandes empresas como proyectos personales se alojan aquí.
En 2018, Microsoft adquirió GitHub. Hubo cierto recelo inicial en parte de la comunidad, pero en la práctica la plataforma ha seguido creciendo sin cambios traumáticos en su funcionamiento. La integración con el ecosistema de Microsoft (especialmente con Azure y herramientas de desarrollo) se ha reforzado, pero sin dejar de ser un lugar central para proyectos open source de todo tipo.
Dentro de GitHub se alojan repositorios de plataformas que se usan a diario para gestionar infraestructura: Ansible, Terraform, integraciones con Microsoft Azure, Amazon Web Services, Nutanix, Netflix y un larguísimo etcétera. Explorar esos repositorios es una forma muy eficaz de ver cómo abordan otros la automatización, la observabilidad o la resiliencia.
Infraestructura como servicio e infra como código: el contexto
Cuando hablamos de infraestructura de GitHub en entornos profesionales, normalmente nos referimos a cómo describimos y gestionamos la infraestructura de nube con código versionado en repositorios Git. Esto encaja con el modelo de Infraestructura como Servicio (IaaS) y capas superiores como PaaS.
En la capa más baja de la nube, IaaS consiste básicamente en máquinas virtuales, almacenamiento y redes virtuales. Servicios como Amazon EC2, S3 y EBS marcaron el inicio de este modelo: instancias elásticas que pueden crecer o decrecer según demanda, muy distinto del clásico VPS rígido. Competidores como Microsoft Azure o Google Compute Engine ofrecen propuestas similares.
En el otro extremo, existen plataformas para montar nubes privadas sobre tus propios centros de datos, como OpenStack u OpenNebula. Ambas son soluciones de código abierto que permiten gestionar instancias, redes, imágenes y almacenamiento sin depender de un proveedor público.
Sobre esta capa de infraestructura, entran en juego las herramientas de gestión de configuración y orquestación: Chef, Puppet, Ansible, Salt, Rex, Docker, Vagrant… Todas ellas se apoyan muy bien en GitHub, donde se versionan recetas, playbooks, manifests, Vagrantfiles o Dockerfiles que describen cómo debe quedar un sistema, y se combinan con CI/CD para aplicar cambios de forma repetible.
Infraestructura como código en la práctica: Terraform, Ansible y compañía
Uno de los proyectos estrella en GitHub es Terraform (hashicorp/terraform). Terraform permite definir toda la infraestructura (redes, máquinas, bases de datos, balanceadores, etc.) en archivos de configuración declarativa. Esos ficheros se tratan como código: se revisan, se versionan, se prueban y se despliegan mediante pipelines.
Por otro lado, herramientas como Ansible (ansible/ansible) permiten automatizar la configuración de servidores (instalar paquetes, editar ficheros, crear usuarios, desplegar servicios) usando YAML y SSH, sin necesidad de agentes en la máquina remota. Los playbooks de Ansible se guardan también en repositorios Git y se ejecutan desde CI/CD o desde máquinas de orquestación.
Chef, Salt, Puppet o Rex cubren necesidades parecidas con distintos enfoques. Chef define recetas y recetarios (cookbooks) escritos en Ruby; Salt se centra especialmente en el concepto de estado y escalado masivo; Puppet tiene su propio lenguaje declarativo; Rex se basa en Perl y es útil para ejecuciones remotas sencillas. Todos ellos se integran bien con GitHub como punto central de versiones.
Por encima de la configuración, herramientas como Vagrant ayudan a gestionar el ciclo de vida de máquinas virtuales para desarrollo o pruebas. Un Vagrantfile, también versionado en GitHub, define qué box usar, qué hipervisor (VirtualBox, VMware, Docker, etc.), qué provisionador (shell, Ansible, Chef, Puppet, Salt) y qué configuraciones se aplican. Así todo el equipo puede levantar entornos idénticos con un simple comando.
Cómo organiza GitHub su propia infraestructura: Actions, Projects, Security y Copilot
La propia GitHub utiliza GitHub para construir GitHub. En sus charlas y documentación explican cómo combinan GitHub Actions, GitHub Projects, GitHub Advanced Security y GitHub Copilot para desarrollar y operar la plataforma.
GitHub Projects se utiliza para gestionar el trabajo: planificación, seguimiento de issues, priorización. Les permite coordinar múltiples equipos y repositorios manteniendo visibilidad sobre lo que se despliega en la plataforma.
GitHub Advanced Security aporta escaneo de código, detección de secretos y análisis de dependencias para prevenir vulnerabilidades antes de llegar a producción. De esta forma, la propia infraestructura que define y despliega GitHub se somete a controles de seguridad automáticos.
GitHub Copilot y modernización de infraestructura en Azure
Un caso especialmente interesante es el agente de modernización de GitHub Copilot, orientado a aplicaciones que se van a migrar o modernizar en Azure. Este agente soporta el aprovisionamiento de infraestructura, la contenedorización y la implementación en dos fases bien diferenciadas.
La primera fase es la preparación de la infraestructura. A partir de entradas como el código fuente de la aplicación, informes de evaluación (Azure Migrate, modernize assess, herramientas de migración), diagramas de arquitectura o requisitos de seguridad y cumplimiento, el agente genera un plan para crear una zona de aterrizaje en Azure (seguridad, identidad, redes, gobernanza, etc.).
El flujo suele arrancar con un comando como modernize plan create, indicando en lenguaje natural qué se necesita (por ejemplo, “crear infraestructura Azure para mi aplicación”) y un nombre de plan. El resultado incluye un documento con la estrategia de arquitectura y una lista detallada de tareas que se van a ejecutar.
Antes de ejecutar, el equipo revisa y ajusta el plan y las tareas. Después, un modernize plan execute se encarga de desplegar los recursos y generar el código de infraestructura asociado. Todo ello, por supuesto, se puede y se debe versionar en GitHub para tener trazabilidad de cambios.
La segunda fase cubre la contenerización e implementación. Se crea un nuevo plan para generar el Dockerfile, validar la construcción de la imagen, producir manifiestos de despliegue (por ejemplo, para Kubernetes o servicios de Azure) y scripts reutilizables. De nuevo, se revisa el plan y se ejecuta, comprobando los cambios con comandos como git status o git diff, y validando la aplicación en la URL final.
GitHub Pages: infraestructura estática y publicación desde repositorios
Otra pieza relevante de la “infraestructura de GitHub” es GitHub Pages, el servicio para publicar sitios estáticos directamente desde un repositorio. Aunque parezca algo sencillo, también implica decisiones sobre cómo estructurar el código de la web, el contenido, los flujos de compilación y las ramas.
Para crear un sitio con GitHub Pages necesitas primero un repositorio para el sitio. Puedes crear uno nuevo o reaprovechar uno existente. Si se trata de un sitio de usuario u organización, el nombre del repositorio debe seguir el patrón usuario.github.io u organizacion.github.io, siempre en minúsculas. Para cuentas con plan GitHub Free, el repositorio deberá ser público.
Una vez listo el repositorio, tienes que decidir el origen de publicación. GitHub permite usar una rama (por ejemplo, main o gh-pages) y opcionalmente una carpeta dentro de ella (como /docs), o bien un flujo de trabajo personalizado de GitHub Actions que genere y publique el sitio.
El sitio se construye a partir de un archivo de entrada: normalmente un index.html, index.md o README.md. Debe estar en el nivel superior de la ruta que se haya declarado como fuente (por ejemplo, dentro de /docs si se ha elegido esa carpeta). Cuando se usa un workflow de Actions, el artefacto que se publica debe incluir ese archivo en su raíz.
Por defecto, si el origen de publicación es una rama, GitHub Pages compila el sitio con Jekyll. Si prefieres otro generador estático o un proceso de compilación propio, puedes desactivar Jekyll creando un archivo vacío llamado .nojekyll en la raíz de la fuente de publicación, y encargarte tú de generar los archivos estáticos localmente o con Actions.
GitHub Pages publica cualquier archivo estático que subas al repositorio: HTML, CSS, JavaScript, imágenes, PDFs, etc. El servicio gestiona más de 750 tipos MIME, basándose en el proyecto mime-db. No puedes configurar tipos MIME personalizados por repositorio, pero sí puedes contribuir a mime-db si necesitas ampliar la lista global.
Para consultar el sitio publicado, basta con ir a la pestaña Settings → Pages del repositorio y seguir el enlace Visit site. Si has creado, por ejemplo, un fichero /about/contact-us.md en la rama de publicación, se servirá como /about/contact-us.html en la URL final del proyecto.
Organizar código de infraestructura y código de aplicación en GitHub
Una cuestión muy habitual es cómo organizar el repositorio o repositorios cuando trabajas con Terraform, CloudFormation u otras herramientas de IaC junto con el código de la aplicación. Aquí entran en juego decisiones de arquitectura de repos (monorepo vs multirepo) y estrategias de despliegue.
Algunos equipos optan por un repositorio monolítico (monorepo) donde conviven el código de la aplicación y la infraestructura. Ventajas: todo está junto, los cambios coordinados de app e infraestructura se revisan en el mismo pull request y se pueden disparar pipelines que validen ambas cosas a la vez. Es habitual que las ramas de desarrollo desencadenen despliegues automáticos a entornos de pruebas.
Otros prefieren separar infraestructura y aplicación en repositorios distintos. En este modelo, el repositorio de IaC se centra en redes, bases de datos, colas, permisos, etc., mientras que el de la aplicación gestiona el código de negocio. Los despliegues también se orquestan por separado, lo que puede facilitar el versionado de la infraestructura, la reutilización entre múltiples servicios o incluso delegar la gestión de infra en un equipo diferente.
La elección depende mucho de la cultura DevOps del equipo, la escala del sistema y el nivel de automatización del pipeline. Cuando se busca que cada cambio en la rama de desarrollo desencadene un despliegue completo (infra + app), suele favorecerse el monorepo con pipelines bien afinados. Cuando la infraestructura es compleja, compartida por muchas aplicaciones o gestionada por un equipo de plataforma, suele imponerse la separación.
Sea cual sea el enfoque, GitHub aporta las piezas para controlar la calidad y la seguridad de la infraestructura: revisiones de código, validación automatizada de Terraform o CloudFormation en Actions, escaneos de seguridad, integración con herramientas externas, etc. Lo importante es que la infraestructura esté tratada siempre como código, bajo control de versiones y con procesos de revisión claros.
Formación universitaria: proyectos DevOps con GitHub como eje
En el ámbito académico, hay asignaturas de infraestructura virtual e ingeniería de la nube que emplean GitHub como pieza central para enseñar DevOps. Un ejemplo típico es una materia obligatoria en el último curso de Ingeniería Informática (rama de Tecnologías de la Información) y optativa en otras ramas y dobles grados.
Esta asignatura se imparte en aulas de laboratorio, con clases eminentemente prácticas donde el alumnado debe acudir con portátil para trabajar en el proyecto. Muchas sesiones están grabadas en vídeo y disponibles en listas de reproducción, pero se recomienda usarlas sobre todo para conceptos, no para aspectos administrativos que cambian cada curso.
El proyecto de la asignatura se gestiona íntegramente con repositorios de GitHub. Cada estudiante proporciona su usuario para que el profesorado pueda evaluar las entregas. Cada entrega se denomina “objetivo” y representa un resultado de aprendizaje alcanzado: uso de herramientas de desarrollo, historias de usuario y planificación, modelado, automatización de tareas, tests unitarios, contenedores para pruebas, integración continua, servicios esenciales, REST, etc.
Los objetivos tienen plazos de entrega y superación claramente establecidos por semanas, con columnas que indican el límite obligatorio y la fecha aconsejada para maximizar la nota. El incumplimiento de determinados plazos implica no superar el objetivo en la convocatoria ordinaria. La evaluación se estructura en función de qué objetivos se han completado, con tablas de sustitución en caso de faltar algunos, y normas específicas para convocatoria extraordinaria.
El objetivo global de la asignatura es que el estudiante sea capaz de definir un problema y su entorno de pruebas, desplegarlo en un PaaS, configurar integración continua, crear entornos virtuales, comprender el soporte físico de la virtualización, automatizar configuraciones y usar todo ello para despliegues masivos en la nube. GitHub se usa como lugar natural para alojar tanto el código de la aplicación como los archivos de infraestructura y documentación.
Contenidos teóricos y prácticos: de la virtualización a DevOps
El programa de esta asignatura combina temas teóricos y prácticas guiadas. En la parte de IaaS se introduce la historia de la virtualización, el aislamiento de recursos, el almacenamiento virtual, la gestión de configuraciones y la computación serverless, siempre con vistas a su aplicación en proyectos reales.
Se recomienda consultar materiales adicionales como minicursos de Markdown, introducciones ligeras a Git o al lenguaje Ruby, todo ello para facilitar el trabajo con repositorios GitHub y con herramientas de configuración escritas en Ruby o que usan YAML. Las tutorías se apoyan en canales como Telegram o Google Meet, buscando un entorno de aprendizaje cercano a la realidad profesional distribuida.
En la parte de prácticas, el alumnado desarrolla un proyecto a lo largo del curso siguiendo un enfoque DevOps. Se trabaja con máquinas virtuales (locales o en la nube), provisionamiento y automatización, integración continua, microservicios, REST y despliegue en PaaS. Se realizan actividades específicas como juegos de rol para empatizar con el cliente, ejercicios de autoevaluación, pruebas con contenedores y servicios cloud de demostración.
Los proyectos previos incluyen ejercicios de virtualización de aplicaciones, sistemas serverless, creación de microservicios y despliegue en la nube con varias versiones de Platform as a Service. Muchos materiales están disponibles bajo licencias libres y alojados en GitHub, invitando a que el propio alumnado contribuya con pull requests para mejorarlos.
En definitiva, GitHub se convierte no solo en un repositorio de código, sino en el eje de la infraestructura formativa: proyectos, documentación, scripts de despliegue, playbooks de Ansible, recetarios de Chef, Vagrantfiles, pipelines de CI y todo lo necesario para simular el trabajo en entornos profesionales.
La infraestructura de GitHub, entendida en sentido amplio, abarca desde cómo se organizan los repositorios de aplicaciones e infraestructura (juntos o separados), hasta cómo se automatizan despliegues con Actions, se publican sitios con GitHub Pages, se modernizan aplicaciones en Azure con el agente de Copilot o se enseña todo esto en la universidad. Al tratar la infraestructura como código, centralizarla en GitHub y apoyarse en herramientas como Terraform, Ansible, Chef, Vagrant o los propios servicios de la plataforma, es posible construir sistemas más reproducibles, seguros y escalables, tanto en proyectos reales como en entornos de aprendizaje.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.