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

De Wiki de EGC
Saltar a: navegación, buscar

Miembros

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

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:

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 y Test.

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.

Para cerrar issues automaticamente con commit se pueden usar las diferentes keywords close closes closed fix fixes fixed resolve resolves resolved

justo al hashtag del número de incidencia, por ejemplo: close #2

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.

- Oldrepository: Repositorio original en caso de emergencia y necesitar algunos ficheros antiguos


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.


Diario de Equipo

Tarea Descripción Fecha Tiempo Dedicado(min)
Creación grupo En clase creamos el grupo 10/10/2017 20
Entorno desarrollo Preparación entorno desarrollo 10/10/2017 40
1º Reunión Primera reunión 18/10/2017 30
Repartir Tareas Se gestionaron las tareas que había 19/10/2017 30
2º Reunión Segunda reunión 01/11/2017 30
Creación Wiki Creación de la página de la Wiki 05/12/2017 60
Cambios Wiki Arreglos de la página de la Wiki 18/12/2017 60
Preparación presentación Preparación de la presentación del grupo 20/11/2017 60
Milestone 1 Defensa Milestone 1 23/11/2017 30
3º Reunión Tercera reunión 04/12/2017 30
#1 Subida del repositorio 12/12/2017 10
Milestone 2 Defensa Milestone 2 14/12/2017 30
#2 Añadir Twig como dependencia 15/12/2017 10
#3 Refactorizar el adaptador para integrar el sistema a Wordpress 15/12/2017 20
#4 Pulgar el plugin con archivos innecesarios 15/12/2017 20
#5 Crear las entidades de programa 15/12/2017 60
#6 Crear clase para transformar html a PDF 15/12/2017 75
#7 Crear un adaptador de la base de datos 15/12/2017 30
#8 Añadir una accion que descargue el programa en PDF 15/12/2017 40
#9 Crear la plantilla del programa 15/12/2017 20
#10 Crear script sql de pruebas 16/12/2017 20
#11 Crear entorno de pruebas automatizado 17/12/2017 30
#12 Crear mecanismo de automatización de la integración 17/12/2017 60
#13 Elaboración documento de cambio del esquema proporcionado por integración del programa 17/12/2017 60
Milestone 3 Defensa Milestone 3 18/12/2017 30
#14 Crear automatización del despliegue 26/12/2017 60
#15 Arreglar entidades de Programa 04/01/2018 60
4º Reunión Cuarta reunión 10/01/2018 60
Preparación Documento Se prepara el documento que hay entregar 10/01/2018 120
#16 Rehacer las entidades acorde a Eloquent 10/01/2018 75
#17 Crear filtros y funciones para Twig y las plantillas 10/01/2018 85
#18 Crear hoja de estilo de la vistas 10/01/2018 35
#19 Implementar Eloquent en el plugin para el accesso a la Base de datos 10/01/2018 35
#20 Crear Transformador de HTML a PDF para la mejora funcional 10/01/2018 60
#21 Test funcional Model Day 11/01/2018 20
#22 Test funcional Model Program 11/01/2018 20
#23 Test conexión BD Eloquent 11/01/2018 20
#24 Test Adaptador Wordpress 11/01/2018 20
#25 Recrear entidad Program 11/01/2018 15
#26 Recrear entidad Day 11/01/2018 10
#27 Error pruebas automatizadas y CI con travis 11/01/2018 25
#28 Crear el script js para cambiar de dias 11/01/2018 15
#29 Recrear entidad Slot 11/01/2018 20
#30 Test funcional Model Day 11/01/2018 20
#31 Test funcional Model Slot 11/01/2018 20
#33 Crear hoja de estilo PDF exportado 11/01/2018 35
#34 Crear template twig específico para la descarga en pdf de dias 11/01/2018 35
#35 Recrear entidad TalkGroup 12/01/2018 60
#36 Test funcional Model TalkGroup 12/01/2018 20
#37 Implementar el conector Eloquent de base de datos a una clase 12/01/2018 35
#38 Recrear entidad Talk 12/01/2018 60
#39 Test funcional Model Talk 12/01/2018 20
#40 Test de la clase convertidora a PDF 12/01/2018 20
#41 Error en las variables de entorno de la conexion a base de datos y error en filtros 12/01/2018 25
Milestone 4 Defensa Milestone 4 18/01/2018 30
Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Gestión_de_visualización_del_programa_-_17_18_-_G1&oldid=7262»