Guía práctica del workflow en GitHub: desde crear issues y ramas, aplicar protección y revisiones, configurar CI/CD con Actions, hasta desplegar a Render y monitorizar.

Presentación y bienvenida al directo

Explicación del proyecto API de chiquito

Flujo completo de desarrollo que se va a mostrar

Creación de issues y plantillas

Configuración de plantillas en .github

Creación de issue: añadir categorías

Labels y asignación de issues

Configuración de ramas protegidas

Reglas de protección para rama main

Requerir pull requests y revisiones

Prueba de protección de rama

GitHub Actions y CI/CD

Explicación de workflows y actions

Análisis del workflow de testing

Marketplace de GitHub Actions

Ejecución manual de workflows

Estrategias de ramas y desarrollo

Feature branches y convenciones de naming

Uso de la IA para desarrollar funcionalidad

Creación de rama feature/1

Configuración de status checks obligatorios

Creación de Pull Request

Process de code review

Sugerencias de cambios en PR

Aprobación y merge de pull request

Manejo de tests fallidos

Pull request con tests en rojo

Corrección de errores y push a PR

Review automática con Copilot

Configuración de despliegue automático

Creación de workflow de deploy

Configuración de secretos en GitHub

Ejecución del deploy automatizado

Monitoreo con Dependabot

Configuración de dependabot.yaml

Pull requests automáticas de dependencias

Monitoreo de salud de la aplicación

Workflow de health check y notificaciones

Configuración de alertas por email

Cierre y resumen del flujo completo

<h3>5 lecciones que aprenderás en de esta masterclass</h3>
<ul>
<li>Cómo configurar un repositorio GitHub profesional con protecciones y automatizaciones</li>
<li>Implementar flujo de trabajo con ramas, pull requests y revisiones obligatorias</li>
<li>Crear GitHub Actions para testing automático, validación y despliegue continuo</li>
<li>Establecer sistema de monitoreo y alertas para detectar fallos en producción</li>
<li>Integrar el ecosistema GitHub para documentación</li>
</ul>
<h3>La ilusión de simplicidad</h3>
<p>Cuando empiezas a programar, GitHub parece simple. Subes código, haces commits, tal vez colaboras con alguien. Pero la verdad es que estás apenas arañando la superficie de lo que realmente es un flujo profesional de desarrollo.</p>
<p>La mayoría de desarrolladores nunca aprenden el flujo completo. Trabajan años sin saber que existe toda una infraestructura diseñada para proteger el código, automatizar procesos y mantener la calidad. Es como conducir sin conocer las señales de tráfico: funciona hasta que no funciona.</p>
<p><img src="https://raw.githubusercontent.com/free-whiteboard-online/Free-Erasorio-Alternative-for-Collaborative-Design/1443dec5040a56563cbcc66de0d1a5ea3f5993bd/uploads/2025-06-15T16-51-48-034Z-3b0krvlmc.jpg" alt="Flujo de Github" /></p>
<h3>El problema del desarrollador solitario</h3>
<p>Hay una tendencia peligrosa entre los que programan solos: pensar que las herramientas de colaboración no les aplican. “¿Para qué voy a crear una pull request si soy yo solo?” se preguntan. Es como preguntarse para qué necesitas un cinturón de seguridad si conduces despacio.</p>
<p>El problema no es la velocidad, es la inevitabilidad del error humano. Cuando trabajas directamente en la rama principal, cada commit es una apuesta. Y en el desarrollo de software, las apuestas siempre terminan mal.</p>
<h3>La anatomía de un flujo real</h3>
<p>Un flujo de GitHub profesional no es una línea recta del problema a la solución. Es un sistema de checks y balances que se parece más a los protocolos de seguridad de un avión que a escribir en un cuaderno.</p>
<p>El proceso real se ve así:</p>
<ul>
<li><strong>Issue tracking</strong>: Cada cambio nace de un problema documentado</li>
<li><strong>Branch protection</strong>: La rama principal se vuelve sagrada</li>
<li><strong>Feature branches</strong>: El trabajo se aísla hasta estar listo</li>
<li><strong>Continuous integration</strong>: Las máquinas verifican antes que los humanos</li>
<li><strong>Code review</strong>: Otro par de ojos examina cada línea</li>
<li><strong>Automated deployment</strong>: El código bueno se despliega solo</li>
<li><strong>Monitoring</strong>: Los sistemas vigilan que todo funcione</li>
</ul>
<p>Cada paso parece innecesario hasta que previene un desastre.</p>
<h3>Las plantillas que nadie usa</h3>
<p>GitHub permite crear plantillas para issues y pull requests. La mayoría de desarrolladores las ignoran, pensando que es burocracia innecesaria. Pero las plantillas son como los formularios de emergencia: cuando las necesitas, realmente las necesitas.</p>
<p>Una plantilla de issue bien diseñada no es para impresionar; es para forzar el pensamiento estructurado. Te obliga a explicar qué problema resuelves, cómo lo vas a resolver, y qué criterios definen el éxito. Sin esto, es fácil perderse en implementaciones que no resuelven el problema real.</p>
<p>Lo mismo pasa con las plantillas de pull request. Te hacen documentar no solo qué cambiaste, sino por qué lo cambiaste y cómo probaste que funciona.</p>
<h3>La protección de ramas como filosofía</h3>
<p>Proteger la rama principal es probablemente la decisión más importante que puedes tomar en un proyecto. No es solo una configuración técnica; es una declaración filosófica sobre cómo valoras la estabilidad.</p>
<p>Cuando proteges main, estás diciendo que esa rama representa la verdad. Que el código ahí debe funcionar siempre. Que cada cambio debe ganarse el derecho a entrar.</p>
<p>Esta protección se implementa con reglas específicas:</p>
<ul>
<li><strong>Require pull requests</strong>: No se puede pushear directamente</li>
<li><strong>Require reviews</strong>: Al menos una persona debe aprobar</li>
<li><strong>Require status checks</strong>: Los tests deben pasar</li>
<li><strong>Restrict pushes</strong>: Solo ciertos usuarios pueden hacer bypass</li>
</ul>
<p>Estas reglas parecen obstáculos hasta que previenen que alguien suba código roto un viernes a las 6 PM.</p>
<h3>GitHub Actions: la automatización que importa</h3>
<p>Las GitHub Actions son lo más parecido a tener un asistente robot que nunca se cansa ni comete errores de distracción. Cada vez que alguien propone un cambio, las Actions ejecutan una serie de verificaciones automáticas.</p>
<p>Un pipeline típico incluye:</p>
<ul>
<li><strong>Instalación de dependencias</strong>: npm ci, no npm install</li>
<li><strong>Ejecución de tests</strong>: Si fallan, se detiene todo</li>
<li><strong>Verificación de sintaxis</strong>: Linters y formatters</li>
<li><strong>Auditoría de seguridad</strong>: npm audit para vulnerabilidades</li>
<li><strong>Build del proyecto</strong>: Confirmar que compila</li>
</ul>
<p>Lo brillante de esto es que sucede antes de que un humano dedique tiempo a revisar. Las máquinas atrapan los errores obvios, liberando a las personas para encontrar problemas más sutiles.</p>
<h2>Las pull requests como conversaciones</h2>
<h3>El arte de la revisión de código</h3>
<p>Una pull request no es solo una propuesta de cambio; es el inicio de una conversación sobre el código. Pero como toda conversación, puede salir terriblemente mal si no entiendes las reglas implícitas.</p>
<p>El problema con muchas code reviews es que se enfocan en lo superficial: naming, indentación, pequeños detalles de estilo. Estas cosas importan, pero son las menos importantes. Una buena review examina:</p>
<ul>
<li><strong>Lógica</strong>: ¿El código hace lo que dice que hace?</li>
<li><strong>Edge cases</strong>: ¿Qué pasa con inputs inesperados?</li>
<li><strong>Performance</strong>: ¿Hay bottlenecks obvios?</li>
<li><strong>Mantenibilidad</strong>: ¿Será fácil cambiar esto en 6 meses?</li>
<li><strong>Seguridad</strong>: ¿Hay vulnerabilidades potenciales?</li>
</ul>
<h3>La psicología de las sugerencias</h3>
<p>GitHub permite hacer sugerencias directas de código en las reviews. Esto parece una mejora puramente técnica, pero cambia fundamentalmente la psicología de la colaboración.</p>
<p>Cuando sugieres un cambio específico en lugar de solo comentar que algo está mal, reduces la fricción mental. La persona que revisa puede ver exactamente qué propones, y quien recibe la review puede aplicar el cambio con un click.</p>
<p>Esto elimina el ciclo de “necesitas cambiar X” → “¿cómo?” → “así” → “ah, entiendo” → implementar. La sugerencia directa convierte la crítica en colaboración.</p>
<h3>El poder del número de issue</h3>
<p>Hay un detalle que la mayoría pasa por alto: relacionar commits con issues usando el número precedido por #. Esto no es solo documentación; es creación de contexto histórico.</p>
<p>Cuando escribes <code>fixes #1</code> en un commit, GitHub automáticamente:</p>
<ul>
<li>Enlaza el commit con la issue</li>
<li>Cierra la issue cuando se hace merge</li>
<li>Crea un trail navegable del problema a la solución</li>
</ul>
<p>Meses después, cuando te preguntes por qué existe cierto código, puedes rastrear desde el commit hasta la issue original y entender el contexto completo.</p>
<h2>La integración continua como red de seguridad</h2>
<h3>Tests que valen la pena</h3>
<p>Los tests en CI/CD no son para demostrar que tu código funciona; son para demostrar que no rompiste el código de otros. Esta distinción es crucial.</p>
<p>Un buen pipeline de testing ejecuta:</p>
<pre><code class="language-yaml"># Tests unitarios: Verifican piezas aisladas
npm run test:unit

# Tests de integración: Verifican que las piezas funcionan juntas
npm run test:integration  

# Tests de lint: Verifican consistencia de estilo
npm run lint

# Tests de seguridad: Verifican vulnerabilidades conocidas
npm audit
</code></pre>
<p>Cada categoría atrapa diferentes tipos de errores. Los unitarios atrapan lógica rota. Los de integración atrapan interfaces incompatibles. Los de lint atrapan inconsistencias. Los de seguridad atrapan dependencias vulnerables.</p>
<h3>El deployment continuo como destino</h3>
<p>El verdadero poder del CI/CD aparece cuando confías lo suficiente en tu pipeline para automatizar el deployment. Cuando los tests pasan, el código se despliega automáticamente a producción.</p>
<p>Esto suena aterrador al principio. ¿Qué pasa si algo sale mal? Pero la realidad es opuesta: los deployments automáticos son más seguros que los manuales porque eliminan el error humano.</p>
<p>Los deployments manuales fallan por:</p>
<ul>
<li>Olvidar pasos</li>
<li>Ejecutar comandos en el ambiente equivocado</li>
<li>Fatiga después de largas sesiones</li>
<li>Presión de tiempo que lleva a atajos</li>
</ul>
<p>Los deployments automáticos ejecutan exactamente los mismos pasos cada vez, en el mismo orden, con las mismas verificaciones.</p>
<h2>El monitoreo como retroalimentación</h2>
<h3>Dependabot: el asistente que nunca duerme</h3>
<p>Una de las características más subestimadas de GitHub es Dependabot. Automáticamente crea pull requests para actualizar dependencias obsoletas o vulnerables.</p>
<p>Esto parece menor hasta que entiendes que las vulnerabilidades de seguridad aparecen constantemente. Sin Dependabot, tendrías que verificar manualmente cada dependencia, leer changelogs, evaluar riesgos. Con Dependabot, el proceso se reduce a revisar y aprobar.</p>
<h3>Health checks automatizados</h3>
<p>El monitoreo real va más allá de verificar que tu servidor responde. Necesitas verificar que tu aplicación funciona correctamente. Esto requiere endpoints específicos de health check:</p>
<pre><code class="language-javascript">app.get('/health', (req, res) =&gt; {
  // Verificar conexión a base de datos
  // Verificar servicios externos
  // Verificar estado de memoria/CPU
  res.status(200).json({ status: 'healthy' });
});
</code></pre>
<p>Un pipeline de monitoreo puede ejecutar estos checks periódicamente y alertarte cuando algo falla. La clave es fallar rápido y fallar ruidosamente.</p>
<h2>Los nombres que importan</h2>
<h3>Convenciones de branches</h3>
<p>El naming de branches no es cosmético; es comunicación asíncrona con tu equipo futuro. Una buena convención incluye:</p>
<ul>
<li><strong>Tipo</strong>: feature/, bugfix/, hotfix/</li>
<li><strong>Número de issue</strong>: Para trackear el propósito</li>
<li><strong>Descripción breve</strong>: Para entender sin contexto</li>
</ul>
<p>Ejemplos:</p>
<ul>
<li><code>feature/42-add-user-authentication</code></li>
<li><code>bugfix/18-fix-memory-leak</code></li>
<li><code>hotfix/critical-security-patch</code></li>
</ul>
<p>Esta estructura permite que cualquiera entienda qué hace la branch, por qué existe, y dónde encontrar más contexto.</p>
<h3>Conventional commits</h3>
<p>Los mensajes de commit también siguen convenciones que permiten automatización. El formato estándar es:</p>
<pre><code>type(scope): description

feat(auth): add user login endpoint
fix(api): handle null responses correctly  
docs(readme): update installation instructions
</code></pre>
<p>Estas convenciones permiten generar changelogs automáticamente, determinar versioning semántico, y filtrar commits por tipo.</p>
<h2>La curva de aprendizaje inevitable</h2>
<h3>Por qué es difícil al principio</h3>
<p>El flujo completo de GitHub es cognitivamente pesado porque requiere mantener múltiples modelos mentales simultáneamente:</p>
<ul>
<li><strong>El estado del código</strong>: ¿Qué branch tiene qué cambios?</li>
<li><strong>El estado de los tests</strong>: ¿Qué está rojo, qué está verde?</li>
<li><strong>El estado de las reviews</strong>: ¿Qué necesita aprobación?</li>
<li><strong>El estado del deployment</strong>: ¿Qué versión está en producción?</li>
</ul>
<p>Para desarrolladores acostumbrados a trabajar linealmente, esto se siente como sobrecarga innecesaria. Pero esta complejidad no es accidental; es el costo de mantener sistemas estables a escala.</p>
<h3>La transición mental necesaria</h3>
<p>La transición más difícil es mental: pasar de pensar en código como texto que escribes a pensar en código como sistema que mantienes. Esta transición cambia todo:</p>
<ul>
<li>Los commits dejan de ser checkpoints personales y se vuelven comunicación pública</li>
<li>Las branches dejan de ser experimentos y se vuelven propuestas formales</li>
<li>Los tests dejan de ser verificación personal y se vuelven contratos públicos</li>
<li>El deployment deja de ser una tarea y se vuelve un evento automatizado</li>
</ul>
<h3>Por qué vale la pena</h3>
<p>Una vez que internalizas el flujo completo, programar se vuelve menos estresante. Sabes que:</p>
<ul>
<li>No puedes romper main accidentalmente</li>
<li>Los tests atraparán errores antes que los usuarios</li>
<li>Cada cambio será revisado por alguien más</li>
<li>El deployment sucederá consistentemente</li>
<li>Los problemas serán detectados rápidamente</li>
</ul>
<p>Esta infraestructura te libera para enfocarte en resolver problemas en lugar de manejar procesos.</p>
<h2>La evolución desde simplicidad</h2>
<h3>Cómo empezar gradualmente</h3>
<p>No necesitas implementar todo de una vez. Una progresión natural es:</p>
<ol>
<li><strong>Proteger main</strong>: Require pull requests</li>
<li><strong>Agregar tests básicos</strong>: Al menos smoke tests</li>
<li><strong>Configurar CI</strong>: Tests automáticos en PRs</li>
<li><strong>Agregar code review</strong>: Una aprobación requerida</li>
<li><strong>Automatizar deployment</strong>: CD para staging primero</li>
<li><strong>Agregar monitoreo</strong>: Health checks y alertas</li>
</ol>
<p>Cada paso agrega valor incremental sin sobrecargar el proceso.</p>
<h3>Señales de que necesitas más proceso</h3>
<p>Sabes que necesitas más proceso cuando:</p>
<ul>
<li>Encuentras bugs en producción que los tests deberían haber atrapado</li>
<li>Pasas más tiempo debuggeando deployments que desarrollando features</li>
<li>Los cambios de una persona rompen el trabajo de otra</li>
<li>No puedes identificar cuándo se introdujo un bug específico</li>
<li>El deployment requiere documentación especial o conocimiento tribal</li>
</ul>
<p>Estas son señales de que el proceso actual no escala con la complejidad del proyecto.</p>
<h2>La mentalidad del flujo completo</h2>
<h3>Pensar en sistemas, no en código</h3>
<p>El flujo completo de GitHub te fuerza a pensar sistémicamente. Cada cambio se evalúa no solo por lo que hace, sino por cómo interactúa con:</p>
<ul>
<li>El código existente</li>
<li>Los tests existentes</li>
<li>Los usuarios actuales</li>
<li>Los deployments futuros</li>
<li>El mantenimiento a largo plazo</li>
</ul>
<p>Esta perspectiva sistémica es lo que separa a los desarrolladores senior de los junior. No es experiencia técnica; es capacidad de ver las conexiones.</p>
<h3>La documentación automática</h3>
<p>Cuando usas el flujo completo correctamente, la documentación se genera automáticamente:</p>
<ul>
<li>Las issues documentan problemas y decisiones</li>
<li>Las pull requests documentan cambios y razonamiento</li>
<li>Los commits documentan progreso incremental</li>
<li>Los tests documentan comportamiento esperado</li>
<li>Los deployments documentan qué está en producción</li>
</ul>
<p>Esta documentación es más valiosa que cualquier wiki porque está directamente conectada al código que describe.</p>
<h3>El costo real de no usarlo</h3>
<p>El costo de no usar un flujo completo no es evidente al principio. Se acumula gradualmente:</p>
<ul>
<li>Time perdido en bugs que se pudieron prevenir</li>
<li>Estrés de deployments manuales</li>
<li>Dificultad para onboardear nuevos desarrolladores</li>
<li>Imposibilidad de rastrear cuándo y por qué se introdujeron cambios</li>
<li>Miedo a tocar código legacy porque no hay tests</li>
</ul>
<p>Estos costos se vuelven exponenciales conforme el proyecto crece.</p>
<h2>Conclusión: la infraestructura invisible</h2>
<p>La mayoría de desarrolladores ven GitHub como un repositorio de código. Pero realmente es una plataforma para construir infraestructura de desarrollo. El flujo completo crea un sistema donde:</p>
<ul>
<li>Los errores se detectan antes de llegar a usuarios</li>
<li>Los cambios se documentan automáticamente</li>
<li>El código se despliega consistentemente</li>
<li>Los problemas se rastrean hasta su origen</li>
<li>La colaboración sucede de forma estructurada</li>
</ul>
<p>Esta infraestructura es invisible cuando funciona bien. Solo notas su ausencia cuando algo sale mal.</p>
<p>El tiempo que inviertes configurando este flujo no es overhead; es inversión en estabilidad futura. Cada hora que dedicas a configurar protecciones, tests, y automatización te ahorra días de debugging manual más adelante.</p>
<p>En desarrollo de software, como en aviación, los procedimientos parecen innecesarios hasta que previenen un desastre. El flujo completo de GitHub no es burocracia; es el cinturón de seguridad que te permite ir más rápido de forma segura.</p>


Duración

Capítulos

Workflow completo de trabajo con Github: desde la issue hasta el despliegue continuo

Workflow completo de trabajo con Github: desde la issue hasta el despliegue continuo

Qué vas a aprender

Explora los capítulos

1. Presentación y bienvenida al directo [04:10]

2. Creación de issues y plantillas [06:51]

3. Configuración de ramas protegidas [08:19]

4. GitHub Actions y CI/CD [07:12]

5. Estrategias de ramas y desarrollo [10:30]

6. Creación de Pull Request [11:15]

7. Manejo de tests fallidos [10:12]

8. Configuración de despliegue automático [09:47]

9. Monitoreo con Dependabot [04:16]

10. Monitoreo de salud de la aplicación [08:06]