sprint1 cierre devops
- Backend
https://github.com/andergcp2/backend-proyecto-final/commits/main
- Frontend
https://github.com/andergcp2/frontend-proyecto-final/commits/main
- Repositorios
| Nombre | URL | Propósito |
|---|---|---|
| Frontend-Equipo18 | https://github.com/andergcp2/frontend-proyecto-final | Código del frontend de la aplicación ABC Jobs |
| Backend-Equipo18 | https://github.com/andergcp2/backend-proyecto-final | Código del backend de la aplicación ABC Jobs |
- Ramas
| Nombre | Propósito |
|---|---|
| Main | Esta rama contiene el paquete de funcionalidades de la aplicación ABC Jobs |
| Develop | En esta rama se integran los cambios desarrollados en cada feature |
| Feature | En estas ramas se implementan cada una de las nuevas funcionalidades de ABC Jobs |
| Hotfix | En esta rama se corrigen los bugs detectados en la aplicación en productivo |
- Flujo: GitFlow
- Acuerdos
| Acción | Quién | Cuándo | Dónde |
|---|---|---|---|
| Clonar los repositorios de Backend y Frontend en su máquina local | Todos los desarrolladores | Al empezar a trabajar en el proyecto | Repositorios |
| Crear Rama develop a partir de main | Anderson Castiblanco | Crear la rama develop para el trabajo de desarrollo | Rama develop |
| Crear un PR al mezclar cambios de develop a main | Todos los desarrolladores | Cuando los cambios estén aprobados en develop y se requiera hacer una entrega de valor al cliente | Rama main |
| Ejecutar los tests creados antes de mezclar de develop a main | Github Actions | Cuando se cree un PR para fusionar cambios de develop a main | Rama main |
| Ejecutar los tests creados antes de mezclar de una rama feature a develop | Github Actions | Cuando se cree un PR para fusionar cambios de feature/* a develop | Rama develop |
| Mezclar cambios de ramas feature a rama develop | Todos los desarrolladores | Cuando se tenga listo y probado el código de una nueva funcionalidad o HU y se quiera fusionar los cambios a develop | Rama develop |
| Crear ramas para trabajar en nuevas funcionalidades o HUs con el formato feature/<< nombre funcionalidad o HU >> | Todos los desarrolladores | Cuando se empiece a trabajar en una nueva funcionalidad o HU | Ramas feature/* |
- Estrategia de versionamiento
El equipo decide manejar para el proyecto estrategia de versionamiento mediante 3 números: X.Y.Z:
El tercero (Z) se le conoce como revisión y nos indica que se hizo una revisión del código por algun fallo. Ejemplo: 1.2.2, 3.3.4 Ahora que conocemos el significado de cada número, viene una pregunta importante: ¿cómo sabemos cuando cambiarlos y cuál cambiar?
Versión menor o Y, cuando hacemos correcciones menores, cuando arreglamos un error y se agregan funcionalidades que no son cruciales para el proyecto. Revisión o Z, cada vez que entregamos el proyecto.
| Número | Definición |
|---|---|
| Primero (X) | Indica la versión principal de la aplicación |
| Segundo (Y) | Indica la versión menor de la aplicación |
| Tercero (Z) | Indica las correcciones menores de la versión |
Durante el primer sprint ejecutan, dentro del pipeline CI/CD, pruebas unitarias sobre los micros del backend, con un coverage superior al 80%:
Adicionalmente se ejecutan pruebas de sistema E2E para verificar, desde el front, el correcto funcionamiento de las funcionalidades implementadas.
Se utiliza la herramienta Cypress, se implementa el patrón Given-When-Then:
y el patrón Command:
y se ejecutan las pruebas E2E:
