Desarrollo de una Tarea
Guía paso a paso del ciclo de vida de una tarea, desde el Sprint Planning hasta el despliegue en producción.
Entornos
Ramas
Herramientas
Arquitectura de microservicios: cada funcionalidad core tiene su propio repositorio con sus ramas
main y pre independientes. Ten siempre claro en qué repo estás trabajando.
1
Planificación
Sprint Planning
La PM y los Team Leads refinan los requisitos y los presentan al equipo el último día del sprint actual. Cada sprint dura 2 semanas.
To Do→ In Progress→ Code Review→ QA→ Done
Mueve tu ticket a In Progress en Jira en cuanto empieces a trabajar en él. Mantén los estados actualizados siempre.
2
Análisis
Entender la Tarea
Antes de escribir una sola línea de código, lee el ticket completo. Identifica los criterios de aceptación, las dependencias y las dudas.
- ¿Entiendo QUÉ debe hacer el desarrollo?
- ¿Entiendo POR QUÉ se necesita?
- ¿Hay dependencias con otros tickets o equipos?
- ¿Tengo toda la info o necesito preguntar algo?
Si hay dudas, pregunta antes de empezar. No bloquees tu progreso ni asumas cosas. Una duda no resuelta ahora es un bug en producción después.
3
Inicio
Crear Rama desde main
Trabajamos con trunk-based development. Crea una rama corta desde
main con un nombre descriptivo usando el ID del ticket MBN. # Asegúrate de estar actualizado
git checkout main
git pull origin main
# Crea tu rama con el ID del ticket
git checkout -b feature/MBN-1234-descripcion-corta
git checkout main
git pull origin main
# Crea tu rama con el ID del ticket
git checkout -b feature/MBN-1234-descripcion-corta
Las ramas deben vivir máximo 1 semana. Si tu rama dura más de semana y media, algo va mal: la tarea es demasiado grande o no estás avanzando.
4
Desarrollo
Escribir Código + Commits Frecuentes
Desarrolla la funcionalidad haciendo commits pequeños y frecuentes. Cada commit debe representar un cambio lógico y funcional.
feat: Nueva funcionalidadfix: Corrección de bugdocs: Documentaciónrefactor: Mejora internatest: Testschore: Mantenimiento # Ejemplo de commit bien hecho
git add .
git commit -m "feat(MBN-1234): add user validation endpoint"
# Haz push regularmente para no perder trabajo
git push origin feature/MBN-1234-descripcion-corta
git add .
git commit -m "feat(MBN-1234): add user validation endpoint"
# Haz push regularmente para no perder trabajo
git push origin feature/MBN-1234-descripcion-corta
NO hagas un solo commit gigante al final del día. Si pierdes el trabajo o necesitas revertir algo, un solo commit te obliga a perder todo. Commitea cada cambio lógico.
5
Documentación
Documentar mientras desarrollas
La documentación es obligatoria, no opcional. No la dejes para después porque no la harás.
Siempre
- Actualiza el
README.mddel servicio con los cambios realizados - Docstrings en funciones públicas y lógica compleja
- Comentarios en decisiones no obvias
Si desarrollas procesos o scripts
- Elabora documentación adicional en Notion
- Describe el propósito, ejecución, parámetros y ejemplos de uso
Código sin documentar es deuda técnica desde el minuto uno. Si otro dev no puede entender tu código sin preguntarte, falta documentación.
6
Validación
Probar en DEV
Despliega tu rama en el entorno DEV mediante Jenkins. Valida que la funcionalidad cumple con los criterios de aceptación del ticket.
- ¿Funciona el caso principal (happy path)?
- ¿Has probado los casos límite y errores?
- ¿No has roto funcionalidad existente?
- ¿Los logs son claros y útiles?
Deja evidencias en el ticket de Jira de las pruebas realizadas y los resultados obtenidos (capturas, logs, respuestas de API…). Sin evidencias, la prueba no cuenta.
DEV es tu campo de pruebas. Despliega tantas veces como necesites. Es mejor detectar errores aquí que en PRE o PRO.
7
Code Review
Crear Pull Request
Crea una PR en GitHub de tu feature hacia
pre. La PR debe ser revisada y aprobada por 2 personas: un Mid/Senior con contexto funcional y un Junior para aprendizaje.Mid / SeniorRevisa calidad, diseño, impacto funcional y buenas prácticas
JuniorRevisa legibilidad, entiende los cambios y aprende del proceso
Algunas recomendaciones para la revisión (no exhaustivas):
- El código es legible y tiene nombres descriptivos
- No hay lógica duplicada ni código muerto
- Los cambios están alineados con el ticket de Jira
- Hay documentación en funciones públicas y lógica compleja
- No se han subido secrets, contraseñas ni datos sensibles
- El manejo de errores es adecuado (no se tragan excepciones)
- Los cambios no rompen la funcionalidad existente
Incluye una descripción clara en la PR: qué hace, por qué, y cómo probarlo. Enlaza el ticket de Jira. Tu futuro yo te lo agradecerá.
Mueve el ticket a Code Review en Jira al crear la PR. El equipo necesita visibilidad del estado real de cada tarea.
8
QA
Merge a pre + Despliegue en PRE
Con las 2 aprobaciones, haz merge de tu feature contra
pre. Despliega la rama pre en el entorno PRE mediante Jenkins para que QA valide la funcionalidad.Flujo de ramas
feature/MBN-1234 ── merge → pre ── deploy → Entorno PRE (QA valida)
pre ── ✕ ── main Solo el día hábil anterior al despliegue
Mueve el ticket a QA en Jira. La rama
pre es la que se despliega, no tu feature branch.9
Correcciones
Si QA detecta errores
Nunca modifiques directamente la rama feature original. Crea una nueva rama
fix/ que corrija el error, siguiendo el mismo procedimiento de PR.Flujo de corrección
feature/MBN-1234 ← se crea desde aquí
fix/MBN-1234-correccion ── PR + 2 approvals → feature/MBN-1234
feature/MBN-1234 ── merge → pre QA re-valida
Cada corrección queda encapsulada en su propia rama fix/. Esto mantiene el historial limpio y permite rastrear exactamente qué se cambió y por qué.
# Desde la rama feature original
git checkout feature/MBN-1234-descripcion-corta
git checkout -b fix/MBN-1234-correccion-validacion
# Corrige, commitea, crea PR contra la feature
git commit -m "fix(MBN-1234): handle null response in validation"
git checkout feature/MBN-1234-descripcion-corta
git checkout -b fix/MBN-1234-correccion-validacion
# Corrige, commitea, crea PR contra la feature
git commit -m "fix(MBN-1234): handle null response in validation"
10
Producción
Merge a main + Despliegue en PRO
Con fecha de despliegue confirmada, el merge de la feature contra
main se realiza el día hábil anterior a la fecha de despliegue. El equipo de TI gestiona el despliegue con soporte de los desarrolladores implicados.Merge final
feature/MBN-1234 ── merge → main ── deploy → PRO (TI + Devs)
- QA ha validado en PRE ✓
- Hay fecha de despliegue confirmada y el merge se hace el día hábil anterior
- Documentación actualizada (README + Notion si aplica)
- TI está informado y coordinado
- Hay plan de rollback si algo falla
No hagas merge a main sin fecha de despliegue. Además, el merge solo se realiza el día hábil anterior al despliegue. La rama main debe reflejar únicamente código que está a punto de desplegarse.
Mueve el ticket a Done en Jira tras confirmar que el despliegue en PRO es estable. Cierra el ciclo.