Diferencia entre revisiones de «Gestión de visualización del programa - 17 18 - G1»
(→Formateo de commits) |
(→Organización de las ramas) |
||
| Línea 66: | Línea 66: | ||
- Test: En esta rama estará la versión de test de la aplicación previa a ser estable. | - 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. | - 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 ''' | 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 ''' | ||
Revisión del 15:19 17 dic 2017
Contenido
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.
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.
