# **Universidad de Sevilla** - Escuela Técnica Superior de Ingeniería Informática
**Configuración de la gestión de la metodología**
=
# **Historial del proyecto**

| Fecha | Versión
| -------- | --------
| 12/02/2023 | v1.0

| Miembro del equipo | uvus |
| ------------------------- | -------- |
| Cabrera Gómez, Tadeo | tadcabgom |
| Hidalgo Rodríguez, Álvaro | alvhidrod |
| Mera Gómez, Pablo | pabmergom |
| Oliva Alonso, Virgilio | virolialo |
| Oria Arenas, Jesús | jesoriare |
| Pérez Vázquez, Alejandro | alepervaz |

# **Control de versiones**

| Fecha | Versión | Descripción |
| -------- | -------- | -------- |
| 12/02/2023 | v1.0 | Creación del documento|
|22/02/2023| v1.1| Edición del documento

# **Indice**
1. [Introducción](#1.Introducción)
2. [Estándares de código](#2.Estándares-de-código)
3. [Estándares de commits](#3.Estándares-de-commits)
4. [Estructura del repositorio](#4.Estructura-del-repostorio)
5. [Estrategia de ramas](#5.Estrategia-de-ramas)
6. [Revisiones](#6.Revisiones)
7. [Políticas de versionado](#6.Políticas-de-versionado)

1.Introducción
--
Se pretende documentar la gestión de la configuración que se va a seguir para el desarrollo de la aplicación PetClinic. Comenzamos describiendo los estándares de código y de commits a seguir para las buenas prácticas, siguiendo por cómo se estructura el repositorio, para conocer la jerarquía de carpetas y archivos y qué funciones tienen. Finalmente, conoceremos la estrategia de ramas a aplicar y cómo funciona y las políticas de versionado para el proyecto.

2.Estándares de código
--
Con la aplicación de estándares de código tenemos como objetivo inculcar en el proyecto prácticas de programación la cuales conduzcan a un código seguro, comprobable y mantenible. Partiendo de ello destacamos los siguientes estándares de código:

- Los nombres de clases deben ser mezclas de mayúsculas y minúsculas, con la primera letra de cada palabra interna en mayúscula (camelCase), asimismo los nombres serán claros y descriptivos.
- La longitud de la línea de código no debe superar los 80 caracteres para obtener una mejor visualización del código.
- Las declaraciones que se realicen dentro de un método deberán de situarse siempre al comienzo de este, jamás en el momento de su uso.
- Cada línea de código debe contener máximo una sentencia, es decir, una línea de código solo podrá realizar una acción.
- Las sentencias de codigo pertenecientes a un bloque deberán ser tabuladas un nivel más a derecha con respecto a la sentencia del bloque que las contiene.
- Todos los nombres de constantes deberán de escribirse en mayusculas en su totalidad.
- Se internarán en paréntesis las expresiones que incluyan distintos tipos de operadores para evitar problemas de precedencia de operadores.
- Todo el código que no aporte ninguna funcionalidad debe ser borrado.

3.Estándares de commits
--
Primero de todo, el mensaje empezará con la palabra “fix” si el commit tiene la intención de arreglar un error en el código base, “feat” si realmente lo que busca el commit es añadir una nueva funcionalidad al proyecto o “doc” si simplemente queríamos añadir nueva documentación.

El mensaje de commit empezará con un título de no más de 30 caracteres donde el usuario explicará la funcionalidad principal del código que ha implementado. Esta frase estará escrita en mayúsculas, será imperativa y estará separada del resto del mensaje por una línea en blanco, dando así una idea general del valor que ha tenido ese commit para el desarrollo del proyecto.

Luego, el cuerpo del mensaje explicará de manerá más esclarecedora el motivo del commit, dando una explicación breve de qué funcionalidad se ha añadido y por qué era necesaria, sin usar más de 75 caracteres.

Finalmente añadiremos el mensaje “Fixes #x“, donde x es el número asociado a la issue en GitHub. Esto hará que cualquier usuario que acceda a los commits puedan navegar directamente a la issue asociada al código implementado, haciendo más fácil la comprensión y la estructura de los commits del proyecto.

4.Estructura del repositorio
--
- src: contiene los módulos del proyecto (main) y los respectivos test (test). Dentro de la carpeta podemos encontrar:
- main:
* java/org/springframework/samples/petclinic: contiene las entidades, controladores, repositorios y servicios de las respectivas clases. Por cada clase implementada, se tiene una carpeta con el contenido mencionado anteriormente.
* less: contiene archivos de configuración de estilos del framework de spring.
* resources: contiene los recursos utilizados para la aplicación, así como una incialización de la base de datos, imágenes o fuentes de letra.
* webapp: contiene las pantallas, estructuradas por clases y los tags utilizados en la aplicación.
- test: están estructurados por las clases, y por cada una de estas se tienen pruebas de la entidad, el repositorio, el controlador y los servicios.
- info.yml: contiene información del equipo de trabajo.
- pom.xml: contiene información del framework y de nuevo del equipo de trabajo.
- docs: contiene los documentos que se van a ir generando a lo largo del proyecto a medida que sean necesarios.
La única rama predeterminada era la main la cual contenía las carpetas y archivos mencionados arriba sin modificar, esta será nuestra rama release que solo se modificará al final con un commit de todo el proyecto ya modificado. Posteriormente se crearon las ramas feature, cada una con el nombre específico de su tarea (ej. “eliminacion-objeto”) y la rama develop para trabajar sobre ella.
## 5.Estrategia de ramas:
Debido a los problemas causados por la estrategia usada en la implementación de los requisitos anteriores en forma de varios conflictos que han ocasionado tener que restaurar versiones anteriores del repositorio de GitHub, hemos optado por seguir a partir de ahora la estrategia Git Flow. Desde entonces, los participantes deberán implementar futuros requisitos siguiendo la siguiente serie de normas:
- Se creará una nueva rama por cada requisito a implementar.
- La validación de un requisito debe ser realizada por un participante que no participó en la implementación de dicho requisito, siempre y cuando sea posible, usando la sección de comentarios que GitHub proporciona en el commit final.
- Si se encuentran fallos o inconsistencias, se deberá volver a realizar una nueva validación una vez los problemas estén subsanados.
- Solo se unirá la rama de cada requisito con la principal una vez el requisito esté terminado y validado.
- Si se descubren errores en el requisito una vez la rama de este se encuentra combinada con la principal, este se subsanará en la rama de este, y no en la principal.
Al seguir esta estrategia, esperamos mejorar el trabajo en grupo y reducir problemas a la hora de implementar más requisitos, consiguiendo aumentar la productividad y calidad del producto final.
Como rama de release usaremos la rama main, donde estarán alojadas las versiones finales de cada entregable. Luego, como rama prinicipal en la que iremos añadiendo todas las funcionalidades haremos uso de la rama develop, donde recaerán las ramas features, que en nuestro proyecto tendrán el nombre de la funcionalidad que estemos implementando en esa mejora, usando palabras en minúscula separadas por guión, por ejemplo: funcionalidad-pet-hotel. Sin embargo, la rama hot-fix no la hemos usado debido a que la considerábamos redundante debido a que no había grandes cambios que hacer.

## 6.Revisiones
Para realizar las revisiones haremos uso del peer revisions, que consiste en que un miembro del grupo realiza una tarea, mientras que el otro es el encargado de revisar que es correcto todo lo realizado y que cumple con los requisitos estimados.

Estas revisiones se llevarán a cabo una vez que el encargado de la tarea considere que ha finalizado de la manera correcta, haciendo así un pull request que será validado por la pareja asignada, dejando un comentario positivo y haciendo el merge a la rama develop si considera que la tarea cumple con lo estimado o un comentario mencionando los puntos a mejorar y rechazando esa pull request si cree que aún no es suficiente para ser parte de la rama de develop. Sin embargo, si un miembro está realizando una tarea y cree que está terminada pero no está seguro, puede pedir a su pareja que revise la rama en la que está realizando la tarea y le deje un comentario en GitHub para ayudar a la finalización de la entrega, para así poder continuar teniendo la certeza de que el trabajo hecho hasta ahora va por buen camino.
## 7.Políticas de versionado
Para mejorar el control del versionado, hemos decidido seguir un estándar a la hora de publicar nuevas versiones del proyecto.
El versionado será de la siguiente forma X.Y.Z, donde cada letra tendrá un número asociado según la versión

Para cada commit que arregle un error del código base que mejore un comportamiento incorrecto del sistema pero que no añada versionado aumentará en 1.

En el caso de que haya cambios que puedan aportar mejoras o nuevas funcionalidades sustanciales, que pueden incluir también pequeñas correcciones pero que no rompen la compatibilidad de la API se aumentará en 1 el numero asignado a Y en el versionado.

Si por el contrario hay un commit que incluya nueva funcionalidad, que sean cambios mayores y que, además, rompa la compatibilidad de la API, la letra que sufrirá un aumento de 1 en el versionado es la X.
Por ejemplo, si la aplicación ya está completada (1.0.0) y arreglamos un bug la nueva versión será 1.0.1. En el caso en el que corrijamos una nueva funcionalidad (otro requisito, por ejemplo) y a la vez se arregle otro bug el nuevo versionado sería 1.1.2.