Skip to content

Diario del Equipo

Jump to bottom
Ismael Herrera edited this page Dec 17, 2023 · 5 revisions

decide-part-camaron-3

  • Grupo 3, Mañana
  • Curso escolar: 2023/2024
  • Asignatura: Evolución y Gestión de la Configuración (EGC)

Miembros del grupo:

Resumen de total de reuniones empleadas en el equipo

  • Total de reuniones: 7
  • Total de reuniones presenciales: 2
  • Total de reuniones virtuales: 5
  • Total de tiempo empleado en reuniones presenciales: 4 horas
  • Total de tiempo empleado en reuniones virtuales: 8 horas y media

Actas de acuerdos de las reuniones en las que se tomaron decisiones importantes

ACTA 2023-01

  • Asistentes: TODOS
  • Fecha: 19/10/2023
  • Acuerdos tomados:
    • Acuerdo 2023-01-01: Redacción del acta fundacional
    • Acuerdo 2023-01-02: Elección de incrementos

ACTA 2023-02

  • Asistentes: TODOS
  • Fecha: 06/11/2023
  • Acuerdos tomados:
    • Acuerdo 2023-02-01: repartir tareas y redacción de formulario de inscripción de los integrantes de cada grupo al formulario

ACTA 2023-03

  • Asistentes: Ismael y Marcos
  • Fecha: 28/11/2022
  • Acuerdos tomados:
    • Acuerdo 2023-03-01: Configuración de CODACY.

ACTA 2023-04

  • Asistentes: FERNANDO(Jefe del grupo camaron-2) + MARIO
  • Fecha: 30/11/2023
  • Acuerdos tomados:
    • Acuerdo 2023-04-01: Estrategia de resolución de conflictos
    • Acuerdo 2023-04-02: Avance de los incrementos por los 2 equipos

ACTA 2023-05

  • Asistentes: TODOS
  • Fecha: 30/11/2023
  • Acuerdos tomados:
    • Acuerdo 2022-05-01: Definición de la política de incidencias.
    • Acuerdo 2022-05-02: Definición de la política de commits.

ACTA 2023-06

  • Asistentes: Ismael y Mario
  • Fecha: 10/12/2023
  • Acuerdos tomados:
    • Acuerdo 2023-06-01: Hacer el despliegue Docker y Vagrant 16/12/2023 a las 23:00.

ACTA 2023-07

  • Asistentes: TODOS
  • Fecha: 17/12/2023
  • Acuerdos tomados:
    • Acuerdo 2023-07-01: Acuerdo para defensa y cierre

Políticas

Gestión de Incidencias

Todas las incidencias deberán estar en inglés y etiquetadas respecto a su tipo(bug,enhancement,testing,documentation), con su milestone definido y su estado(Todo, In Progress, In Review o Done).

Para añadir funcionalidades o documentación, en la descripción de la incidencia deberá describirse detalladamente en qué consiste la incidencia y se deberá especificar los módulos a los que afecta la incidencia. La plantilla quedará de la siguiente forma:

Description: *Descripción de la incidencia*.

Affected modules:
	-Module X.
	-Module Y.
	-Module Z.

Los errores se reportarán con una descripción, además de indicar tanto las versiones del software y hardware(entorno) en los que se produce el error. También se indicarán los pasos para conseguir el error. De forma totalmente opcional se podrá añadir una sugerencia de como solucionarlo o dónde está el problema. La plantilla quedará de la siguiente forma:

Description: *Título y descripción del error*.

    Environment used: *Descripción del entorno (software y hardware)*.

    Steps to follow to get the error:
        -Paso X
        -Paso Y
        -Paso Z

    Suggestion: *Sugerencia de como solucionarlo o de dónde está el problema*.

Gestion del código

Política de commits

Se seguirá las políticas de commits que define Conventional Commits.

    <Tipo de commit>: <Título del commit>

    <Descripción commit>

Tipos de commits:

  • build: Para actualizar configuración de build
  • ci: Cambios a archivos y scripts de Integración Continua
  • chore: Cambios que no modifican código fuente o pruebas
  • dependencies: Actualizar dependencias
  • docs: Para cambios en la documentación
  • feat: Para una nueva funcionalidad para el usuario, no para funcionalidad en archivos de build
  • fix: Para arreglos en funcionalidad para el usuario, no para arreglos en funcionalidad de archivos de build
  • initial: Primer commit
  • refactor: Para refactorizar código para producción
  • revert: Revertir cambios
  • style: Para formatear cambios
  • test: Para añadir pruebas faltantes, refactorizar pruebas; no cambia el código de producción

Además de seguir la política de commits seguiremos las 7 normas de buenos commits:

  1. Separe el asunto del cuerpo con una línea en blanco
  2. Limite la línea de asunto a 50 caracteres
  3. Poner en mayúscula la línea de asunto
  4. No termine la línea de asunto con un punto
  5. Use el estado de ánimo imperativo en la línea de asunto
  6. Envuelva el cuerpo en 72 caracteres
  7. Usa el cuerpo para explicar qué y por qué vs. cómo

Política de ramas

Cada feature tendrá asignada su propia rama derivada de develop. Para las features que compartan funcionalidades(tipos de votaciones), se crearán diferentes ramas para cada una. Una vez terminada la issue, antes de hacer pull request, se hará merge en la rama de la feature con develop. Todos los conflictos han de ser tratados en la rama de la issue. Una vez resuelto, se procede a hacer pull request. Para aceptar una pull request hacia la rama develop hecha por una persona, otro desarrollador debe aprobar los cambios hechos. Solo cuando se compruebe que los cambios son funcionales deberán aceptarse.

Cómo arreglar bugs en producción

Cuando se detecte un bug en una release publicada, se llevará la rama main dónde está ese tag a una rama “hotfixes” una vez que se arreglen los errores, se volverá a llevar a través de un merge tanto a main como a develop: Merge a main para hacer una nueva release. La versión será actualizada sumando 1 al campo de bugfixes. Por ejemplo, la release 0.1.0 pasará a ser 0.1.1 Merge a develop para que los cambios se guarden para la siguiente release.

Releases

La estrategia de ramas seguida es la de GitFlow y consta de dos ramas por defecto:”master”, “develop” y “develop-merge-total”.

La rama “master” solo será actualizada cuando se tenga una versión lista para producción tras un Sprint. Las ramas que podrán actualizar la “master” serán únicamente “release” y “hotfix”.

La rama “develop” será actualizada por los desarrolladores desde la familia de ramas “feature” una vez se tenga una funcionalidad totalmente implementada y revisada. Además, en caso de encontrar algún fallo o se quiera realizar una modificación de la funcionalidad que se acaba de actualizar en “develop”; el cambio será realizado desde la rama “feature” correspondiente a esa funcionalidad.

En cuanto a los documentos, la ruta en la cual se añadirán todos los documentos desarrollados será “doc”. Todos los documentos serán añadidos directamente a la rama “develop-merge-total” cuando se tenga la versión final de todos los documentos en el Sprint.

Política de versionado

Para la política de versiones vamos usar Semantic Versioning Aunque el proyecto ya estaba creado, debido a que no encontramos ninguna versión de referencia pensamos en empezar desde 1.0.0 cuando incluimos todos los miembros del grupo en el proyecto.

  • X (Mayor): Aumenta cuando se realizan cambios incompatibles con versiones anteriores o grandes modificaciones que pueden afectar significativamente la funcionalidad existente.

  • Y (Menor): Aumenta cuando se agregan nuevas características de una manera compatible con versiones anteriores. También se incrementa si se realizan mejoras significativas.

  • Z (Parche): Aumenta para correcciones de errores menores o cambios que son totalmente compatibles con versiones anteriores.

Un ejemplo de aplicación de versiones según Semantic Versioning sería:

    1.0.0: Primera versión estable del proyecto
    1.1.0: Se añaden nuevas características o mejoras que son compatibles con la versión 1.0.0.
    1.1.1: Corrección de errores menores en la versión 1.1.0.
    2.0.0: Se realizan cambios incompatibles con versiones anteriores, lo que significa que es posible que algunas funcionalidades existentes no sean compatibles con esta versión.
Clone this wiki locally