Hay cuatro niveles de ramas: la de trabajo (feature/, fix/, docs/, chore/), dev para pruebas, stage para preproducción y main para producción. Nada llega a dev, stage ni main sin pasar el CI, y las correcciones urgentes siguen el mismo camino.
Paso a paso
- PersonaHace un commit en su rama de trabajo
Ejemplo:
feature/back-incidents-crud, creada desdedev. - Hooks locales¿Pasan los hooks de Lefthook?
Antes del commit, sobre lo que cambió: Pint (dentro del contenedor), ESLint y Prettier, Stylelint y búsqueda de secretos con Gitleaks. Al escribir el mensaje: Conventional Commits (tipo y ámbito en inglés, descripción en español, máximo 100 caracteres).
- GitHubAbre un PR hacia dev
Con la plantilla de PR, que incluye la casilla de documentación.
- CI¿Pasan todos los trabajos?
Título del PR, enlaces entre documentación y código, documentación de funciones (TypeDoc y phpDocumentor), frontend (tipos, lint, estilos, formato, pruebas con cobertura y build), backend (Pint, Larastan nivel 8 y Pest con cobertura dentro del stack de Docker), E2E con Playwright y axe en 4 vistas, imágenes de producción y seguridad (Gitleaks y auditoría de dependencias). Acciones fijadas por hash y permisos de solo lectura.
- RamasSquash a dev
El título del PR se vuelve el mensaje del commit.
- RamasMerge de dev a stage
Con merge commit, después de que el CI de
devpase. - RamasMerge de stage a main
- PersonaActualiza el servidor
Ver "Despliegue y actualización". La versión de
mainsigue SemVer.
Dependabot propone actualizaciones cada semana hacia dev; en las imágenes de Docker solo propone parches dentro de la versión fijada.
Dónde está en el código
ci.yml: los trabajos del CI.lefthook.yml,check-commit-msg.mjsyscan-secrets.mjs: hooks locales.check-links.mjs: enlaces entre documentación y código.- Explicación: Flujo de trabajo e Integración continua.