Gestión de visualización del programa - 17 18 - G1

Miembros

• Andrés Soto Valdés
• Pablo Luna Dominguez
• Andrés Fernández Alés
• Adam Cienfuegos Izquierdo
• José María Prieto Gallardo

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace

Gestión de Código

Para la gestión del Codigo vamos a usar Github y el repositorio que tenemos en la organización. Para cada commit se colocara un titulo breve , un comentario al respecto a la subida y la issue a la que esta vinculada.

Entorno de trabajo

Lenguaje de desarrollo: PHP 5.6

Base de datos: mysql 5.7.20

IDE: PHPStorm 2017.3

Librerias:

• Sass para la edición de hojas de estilo.
• Twig 1.31.* for php para las plantillas de visualización.
• Angularjs 1.6.6 para el filtrado de programa.

Gestión de Incidencias

El formato de cada indicencia es temática, prioridad, estado y tipo. La prioridad, estado y tipo tenemos los que el Equipo de Integración nos dice. La temática que hemos escogido para nuestras incidencias son Vistas, AdaptadorWordpress , Hoja de estilos , Acceso a Datos , Lógica de vistas.

Todas las Issues vendran a la columna "ToDo" y ahi se etiquetarán los tags que se vean necesarios y se le asignará a una persona.

Pasarán hacia "En Progreso" hasta su finalización para después pasar a "En Revisión" y si todo esta correcto cerrar la incidencia y moverla a la columna "Hecho".

Formateo de commits

Título: #NúmeroIssue Descripción breve y concisa del commit.
            Linea en blanco
Descripción del commit: Descripción del commit más detallado y intentando ser directos y escuetos.
            Linea en blanco 
Pie del commit: Usar la tag correspondiente para identificar rápidamente si es un bugfix, correción de formato, nuevas funcionalidades con las siguientes tag: Fix, Formato, Nuevo y otros.

Organización de las ramas

- Master: La versión estable de la aplicación estará en esta rama, solo se hará merge con otras ramas si las otras ramas están testeadas y verificadas. - Test: En esta rama estará la versión de test de la aplicación previa a ser estable. - Documentación: Toda la documentación referente a la aplicación estará en esta rama.

Cada vez que una persona trabaja en una nueva incidencia se creará una nueva rama, una vez el desarrollador haya terminado ese trabajo unirá la rama de Test con esta y borrará la creada para la incidencia. Para borrar ramas git branch -d nombreBranch

El formato para el nombre de incidencias es: iss<Número Incidencia>.

Por ejemplo *iss1 es el branch que se dedica a resolver la incidencia 1.