Configuración y despliegue web con GitHub Actions y Pages

Automatizar el despliegue de un sitio web ya no es exclusivo de equipos DevOps. Con GitHub Actions puedes publicar un portafolio web en internet cada vez que actualizas tu código, sin tocar servidores ni pagar hosting. Esta guía es para quien quiere entender cómo funciona el flujo completo: desde clonar un repositorio hasta ver el sitio publicado en GitHub Pages.

¿Cómo preparar el repositorio antes de usar GitHub Actions?

El punto de partida es un proyecto base que vive en el repositorio de Platzi. La acción inicial es hacer fork, que significa clonar un repositorio de otra cuenta hacia la tuya para tener control total sobre los archivos [2:30].

Al crear el fork, el nombre del repositorio importa. Debes nombrarlo con el formato tuusuario.github.io, porque ese patrón es el que GitHub Pages reconoce para servir tu sitio en un dominio público y gratuito.

Después del fork, el flujo continúa así:

1. Copiar la URL SSH desde el botón de código.
2. Ejecutar git clone en tu terminal para bajar el proyecto.
3. Abrir la carpeta con Cursor para explorar el código.

¿Qué es un fork en GitHub? Es una copia de un repositorio ajeno hacia tu propia cuenta. Te permite modificar el código sin afectar el original y mantener tu propia historia de cambios.

¿Cómo entender un proyecto desconocido con Cursor?

Si no dominas desarrollo web, Cursor te ayuda a leer el proyecto. En el panel derecho puedes activar el modo pregunta, elegir un modelo como Claude 4 Sonnet u O3, o dejarlo en auto [4:45]. La IA lee el contexto completo y te explica las características del proyecto, qué archivos editar y qué comandos correr.

En este portafolio, la configuración principal vive en config/portafolio.ts, un archivo de TypeScript donde defines idioma, contenido y datos personales del sitio.

¿Cómo correr el proyecto localmente antes del despliegue?

Antes de automatizar nada, conviene ver el sitio funcionando en tu máquina. Como el proyecto tiene un package.json, sabes que es un proyecto de JavaScript que corre sobre Node.

Los comandos básicos son:

• npm install instala todas las dependencias en la carpeta node_modules. Estas dependencias son código de terceros como React o Tailwind que no necesitas escribir tú.
• npm run dev levanta un servidor de desarrollo local para previsualizar el sitio.
• npm run build genera la versión optimizada del código.

El resultado del build aparece en una carpeta llamada dist, que viene de distribution. Ahí queda todo el código minificado, los assets y el index.html listos para producción [11:20].

¿Qué significa hacer build de un proyecto? Es el proceso de optimizar el código fuente: minificar archivos, dar compatibilidad con navegadores y empaquetar todo en una versión lista para distribuir.

¿Qué es un GitHub Action y cómo configurarlo?

Un GitHub Action es un script que se ejecuta dentro de un repositorio de GitHub cuando ocurre un evento específico. Sirve para correr pruebas, validar código o desplegar tu proyecto a internet de forma automática [8:15].

El evento más común es un push a la rama main. Cada vez que subes cambios, GitHub escucha ese evento y lanza el workflow que tú definas.

¿Dónde se guardan los GitHub Actions?

Todos los actions viven en una ruta específica del repositorio: .github/workflows/. Dentro de esa carpeta creas un archivo con extensión .yml, por ejemplo build.yml. La extensión YAML es una notación sencilla que se usa en archivos de configuración para despliegues e infraestructura.

Un workflow típico para desplegar en GitHub Pages contiene estos elementos:

• Name: nombre descriptivo del action.
• On: el evento que dispara el workflow, en este caso push a main.
• Permissions: lecturas del repositorio, publicación en Pages e interacción con el token.
• Jobs: el script principal con los pasos a ejecutar.

¿Qué pasos ejecuta el workflow de despliegue?

Dentro del job de deploy se encadenan varios steps, cada uno apoyado en acciones reutilizables que otras personas ya escribieron:

1. Checkout de la rama para acceder al código.
2. Setup de Node con caché de npm para acelerar builds futuros.
3. Instalación de dependencias con npm install.
4. Build del proyecto que genera la carpeta dist.
5. Setup de Pages y publicación del artefacto al entorno de GitHub Pages.

El sistema operativo donde corre todo esto se define con runs-on: ubuntu-latest, una máquina virtual que GitHub levanta solo para ejecutar tu workflow [13:40].

¿Cómo activar GitHub Pages y publicar el sitio?

Antes de subir el workflow, hay que activar Pages desde la interfaz. En Settings del repositorio, dentro de la sección Pages, en Build and deployment seleccionas GitHub Actions como fuente. Esto le dice a GitHub que el contenido vendrá de un workflow y no de una rama estática.

Después, el flujo completo se reduce a tres acciones:

• Hacer commit del archivo build.yml con un mensaje descriptivo.
• Ejecutar git push origin main para subir los cambios.
• Entrar a la pestaña Actions del repositorio para ver el workflow corriendo.

Dentro del job verás cómo se ejecuta cada step, cómo se sube el artefacto (el paquete con el build) y cómo, al terminar, GitHub te entrega la URL pública de tu portafolio [16:50].

¿Para qué sirve GitHub Pages? Es un servicio de hosting gratuito incluido en GitHub. Sirve sitios estáticos directamente desde un repositorio y funciona perfecto para portafolios, documentación o landings.

Explorar GitHub Actions abre la puerta a entender cómo se conecta tu código con entornos en la nube y cómo Linux, scripts y automatización conviven en el ciclo de desarrollo moderno. Si quieres profundizar, cuéntame en los comentarios qué proyecto te gustaría automatizar primero.