Gestión de integración con redes sociales - 17 18 - G1

Miembros

• David Dominguez Vázquez
• Eusebio García Plasencia
• Hanna Cheikh Malaaynine
• Jorge García García
• Miguel Caraballo de la Rosa

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace Cualquier cambio o documentación importante añadida a él se notificará a los coordinadores en el momento.

Opera

El portal del proyecto en Opera será accesible en este enlace

Entorno

Para el desarrollo del plugin de redes sociales del Wordpress del congreso, usaremos:

Para la etapa de pruebas e integración, montaremos en un contenedor Docker la pagina web del congreso junto con su base de datos. De esta forma, podremos probar en un entorno simulado el funcionamiento del plugin desarrollado a fin de obtener el mejor resultado posible.

Protocolos

Pasarán a definirse todos los protocolos, procedimientos y formatos que se seguirán a lo largo del proyecto. Estos protocolos pasarán a ser efectivos y obligatorios a partir de su definición en las fechas preestablecidas a continuación, siendo por tanto optativa su aplicación en fechas anteriores a las mismas.

• Gestión de incidencias - 10/12/2017
• Gestión de código fuente - 11/12/2017
• Gestión de equipo - 11/12/2017
• Gestión de integración continua - Proximamente

Formato y procedimientos de gestión de incidencias

El repositorio distribuido utilizado será GitHub, en el realizaremos toda la gestión de las incidencias. Se entiende por incidencia tanto incidencias, como cambios, como tareas que sean necesarias para llevar una correcta gestión de la planificación.

Formato

A continuación detallaremos el formato que se ha de seguir para la creación de issues:

1. Título

• Deberá aportar una información clara y concisa sobre el issue, sin exceder los 100 carácteres.

1. Para tareas:

• Incluir información detallada sobre lo que debe hacerse para la finalización de la tarea.
• Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma.

• Incluir información detallada sobre la modificación que debe hacerse.
• Nombrar mediante el @xxxxx a la persona que le afecte dicha modificación.
• Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma.

• Incluir información detallada sobre el bug encontrado.
• Incluir los pasos para la reproducción del problema.
• Incluir qué se debería esperar y qué se ha obtenido.
• Incluir la versión del producto que se ha usado.
• Incluir información adicional que pueda resultar relevante para la identificación y corrección del error (Opcional).

• Asignar un responsable por incidencia. En caso de que se considere necesario asignar varios responsables a una misma por su complejidad, deberá dividirse la incidencia en tantas incidencias como se consideren necesarias

1. Para tareas:

• Incluir etiqueta que defina la temática de la tarea que se esta realizando. Entre las etiquetas disponibles se encuentran:

• Documentation - Indica que la incidencia lleva asociada la generación de un documento.
• Configurations - Indica que la incidencia lleva asociada una tarea de configuración de entorno.
• Investigation - Indica que la incidencia lleva asociada una tarea de investigación
• ...

• Low - Nivel de prioridad mímino, no es necesario dedicar recursos extra en finalizar la incidencia.
• Medium - Nivel de prioridad medio, no es necesario finalizar la incidencia ya, pero tampoco debe prolongarse en el tiempo.
• High - Nivel de prioridad alto, deben destinarse bastantes recursos para finalizar la incidencia pronto.
• Critical - Nivel de prioridad máximo, deben destinarse todos los recursos posibles para finalizar la incidencia de forma inminente.

• New - Indica que se acaba de crear la incidencia.
• Accepted - Indica que ha sido aceptada la incidencia.
• Started - Indica que se ha comenzado a trabajar en la incidencia.
• Fixed - Indica que se ha corregido la incidencia.
• Verified - Indica que se ha comprobado que la incidencia este correcta.
• Wontfix
• Duplicate - Indica que la incidencia es igual que otra ya creada.

• Incluir alguna de las siguientes etiquetas para indicar que se trata de un cambio o mejora.

• Change - Indica que la incidencia ha sido creada para realizar un cambio.
• Enhancement - Indica que la incidencia ha sido creada para realizar una mejora.

• Documentation - Indica que la incidencia lleva asociada la mejora o cambio de un documento.
• Configurations - Indica que la incidencia lleva asociada mejora o cambio de la configuración de entorno.
• Investigation - Indica que la incidencia lleva asociada una mejora o cambio en investigación
• ...

• Low - Nivel de prioridad mímino, no es necesario dedicar recursos extra en finalizar la incidencia.
• Medium - Nivel de prioridad medio, no es necesario finalizar la incidencia ya, pero tampoco debe prolongarse en el tiempo.
• High - Nivel de prioridad alto, deben destinarse bastantes recursos para finalizar la incidencia pronto.
• Critical - Nivel de prioridad máximo, deben destinarse todos los recursos posibles para finalizar la incidencia de forma inminente.

• New - Indica que se acaba de crear la incidencia.
• Accepted - Indica que ha sido aceptada la incidencia.
• Started - Indica que se ha comenzado a trabajar en la incidencia.
• Fixed - Indica que se ha corregido la incidencia.
• Verified - Indica que se ha comprobado que la incidencia este correcta.
• Wontfix
• Duplicate - Indica que la incidencia es igual que otra ya creada.

• Incluir la siguiente etiqueta para indicar que se trata de un fallo encontrado.

• bug - Indica que la incidencia hace referencia a un bug o fallo

• Documentation - Indica que la incidencia lleva asociada un bug/fallo en un documento.
• Configurations - Indica que la incidencia lleva asociada un bug/fallo en configuración de entorno.
• Investigation - Indica que la incidencia lleva asociada un bug/fallo de investigación
• ...

• Low - Nivel de prioridad mímino, no es necesario dedicar recursos extra en finalizar la incidencia.
• Medium - Nivel de prioridad medio, no es necesario finalizar la incidencia ya, pero tampoco debe prolongarse en el tiempo.
• High - Nivel de prioridad alto, deben destinarse bastantes recursos para finalizar la incidencia pronto.
• Critical - Nivel de prioridad máximo, deben destinarse todos los recursos posibles para finalizar la incidencia de forma inminente.

• New - Indica que se acaba de crear la incidencia.
• Accepted - Indica que ha sido aceptada la incidencia.
• Started - Indica que se ha comenzado a trabajar en la incidencia.
• Fixed - Indica que se ha corregido la incidencia.
• Verified - Indica que se ha comprobado que la incidencia este correcta.
• Wontfix
• Duplicate - Indica que la incidencia es igual que otra ya creada.

• Asignar a la incidencia el proyecto al que corresponda. Por defecto las incidencias creadas se colocarán automáticamente en la columna TODO del proyecto seleccionado. Existen los siguientes proyectos disponibles en función del estado del desarrollo.

• Desarrollo individual de funcionalidades
• Integración de funcionalidades
• Integración y configuración del plugin en la página oficial del congreso

• Asignar el milestone al que corresponda la incidencia. Debe asignarsele a la incidencia el milestone para el que deberá estar finalizada. Entre los milestone asignables se encuentran:

• Milestone 1
• Milestone 2
• Milestone 3
• Milestone 4

Información adicional

1. Uso de los comentarios

• Para contactar con el creador responsable de la incidencia en referencia al algún aspecto o duda de la misma.
• Para indicar avances en el desarrollo de la incidencia.
• Para justificar el cierre de la incidencia.

• Se podrán cerrar manualmente incidencias que no estén asociadas a un commit. En caso de que si estén asociadas a un commit deberán ser cerradas a la hora de realizar el commit.

Procedimientos

Las incidencias creadas deberán ser actualizadas conforme avance el trabajo sobre las mismas. Por tanto se deberán actualizar tanto las etiquetas, como la ubicación de la incidencia en el tablero kanban.

1. Evolución de las etiquetas

• New
• Accepted
• Started
• Verified
• Opcionalmente si procede - Duplicate, Fixed o WontFinx

• TODO
• InProgress
• Done
• Opcionalmente si procede - ToCheck o Buged|OnHole

Con todas las pautas definidas podemos asegurar una correcta creación y gestión de incidencias.

Formato y procedimientos de gestión de código fuente

Para realizar la gestión del código fuente utilizaremos las herramientas Git y GitHub. Utilizaremos Git para la creación de repositorios locales que nos permitirá mantener un control de versiones sobre nuestros archivos. Además Git nos facilitará la tarea de subir los avances al repositorio remoto. Precisamente como repositorio remoto actuará GitHub, permitiendo alojar el contenido de forma que sea accesible para todos los integrantes del equipo.

Formato

<type>: <subject>

<body>

<footer>

1. type

• Indica la temática del commit a realizar

• Documentation
• Feature
• Configuration
• ...

• Indica el título que llevará el commit. Debe ser breve y conciso.

• Indica la descripción del commit. Debe aportar información suficiente y detallada para conocer el motivo de la realización del commit.

• Indica la etiqueta de cierre en caso de que el commit lleve asociado una incidencia.Las etiquetas disponibles son

• Para hacer mención a una issue
• ref #NúmeroDeIncidencia
• ref #NúmeroDeIncidencia1, #NúmeroDeIncidencia2, #NúmeroDeIncidenciaN
• Para indicar cierre de forma general
• Closed #NúmeroDeIncidencia
• Closes #NúmeroDeIncidencia1, #NúmeroDeIncidencia2, #NúmeroDeIncidenciaN
• Para indicar cierre por que ha sido arreglado un bug/fallo
• Fixed #NúmeroDeIncidencia
• Fixes #NúmeroDeIncidencia1, #NúmeroDeIncidencia2, #NúmeroDeIncidenciaN
• Para indicar cierre por que ha sido resuelto un cambio
• Resolved #NúmeroDeIncidencia
• Resolves #NúmeroDeIncidencia1, #NúmeroDeIncidencia2, #NúmeroDeIncidenciaN

Procedimientos

Los commits(push) al repositorio remoto serán realizados desde la consola de comandos de Git llamada Git Bash. Para la correcta realización de los push será necesario seguir los siguientes pasos:

1. Añadir el archivo o archivos al repositorio local

• $git add nombreDelArchivo/s

• $git commit
• Editar el type, subject, body y footer conforme a las reglas anteriores.

• $git push

Organización de las ramas

El repositorio definido para el desarrollo del proyecto constará con 10 ramas. A continuación de muestra el significado de cada rama junto con un esquema en el que se ven las interacciones de las diferentes ramas entre sí.

1. Ramas de desarrollo de cada usuario

• Con el fin de que cada integrante del equipo pueda desarrollar una funcionalidad sin necesidad de depender del uso del repositorio por parte de otro usuario, se ha establecido una rama de desarrollo por usuario. En esta rama cada usuario podrá implementar la funcionalidad que se le haya asignado sin preocuparse por el resto del equipo. Estas ramas son las siguientes.

• Davdomvaz
• Eusgarpla
• Hanchemal
• Jorgargar
• Migcardel

• Conforme los integrantes del equipo concluyan la implementación de sus funcionalidades, deberán fusionar de forma que se aglutinen todas las funcionalidades en una única rama. Esta rama es la siguiente.

• Development

• Además de las ramas principales, se han definido tres ramas adicionales. Una se utilizará para almacenar toda la documentación generada a lo largo del desarrollo del proyecto. En otra tendremos la copia del repositorio del plugin sobre la que vamos ha realizar la mejora. Y la es meramente un soporte de información, ya que contendrá el repositorio de otro plugin que nos puede ayudar al desarrollo del nuestro, pero no tendrá ninguna relación con el proyecto. Estas ramas es la siguientes.

• Documentation
• SSABRepository
• SMFRepository

• Una vez se obtenga una versión estable y funcional utilizaremos esta rama para albergarla. Esta rama es la siguiente.

• Master

Formato y procedimientos de gestión del equipo

En esta sección se definen los puntos siguientes:

1. Herramientas de comunicación:

• Se usará WhatsApp para comunicarse con el equipo, ello incluye dudas puntuales y avisos, también se utilizará discord para ello al poder crearse canales específicos para cada tema del proyecto, junto con la posibilidad de realizar llamadas de voz para consultas a tiempo real y compartir archivos de forma organizada.
• Se utilizará Skype para reuniones no presenciales en la que se tenga que discutir algún tema importante.
• A la hora de compartir documentos se usará la rama Documentación creada en GitHub para que todo el equipo tenga acceso. Para ello el documento tiene que tener un título que explique de forma breve de lo que trata su contenido.
• Todo documento compartido ha de llevar un comentario que explique el contenido del documento.

• Se realizará una reunión presencial justo después de cada milestone, es decir, todos los jueves a las 12:30.
• El día anterior al milestione se realizará una reunion (puede ser presencial o no) en el que se revisará el contenido del milestione y se discutirán los problemas encontrados.
• Todas las reuniones han de estar formadas por al menos el 50% del equipo, incluyendo a un PM.
• Todas las reuniones tienen que establecer los puntos a discutir y documentarlos posteriormente junto con las conclusiones sacadas.
• El encargado de documentar la reunión debe ser uno de los presentes en la misma.

• Una reunión extraordinaria puede ser presencial o no.
• Las reuniones extraordinarias solo se pueden organizar en el caso de que haya una issue que haya que resolver de forma urgente o el replanteamiento del milestone.
• En las reuniones extraordinarias se aplican las reglas tratadas en las reuniones oficiales.

• Las reuniones presenciales se realizarán en la Escuela Técnica Superior de Ingeniería Informática de Sevilla en alguna de las salas proporcionadas por la bilioteca o en alguna de las aulas del CRAI.
• Al final de cada reunión se realizará una issue para la documentación de la reunión en la que se detallan los puntos de la reunión y quien va a realizar la documentación.

Formato de gestión de integración continua

Automatización de pruebas

Para la realización de la gestión de integración continua usaremos Travis CI, que es un host que ofrece un servicio de integración continua. Para ello, hemos tenido que añadir los siguientes ficheros de actualización:

• .travis.yml: Este archivo contiene la configuración para que Travis funcione.
• composer.json: Con este archivo mantenemos las versiones tanto de php como de phpunit actualizadas.
• phpunit.xml: Aqui indicamos donde estan las pruebas para que Travis las ejecute.
• deploy/Tests(carpeta): Carpeta en la introduciremos todo los tests que queremos que Travis nos ejecute.

Automatización de despliegue

Para realizar el deploy utilizaremos Github Releases, que es un apartado en el repositorio donde se suben las versiones que se quieran lanzar. Para realizar una release, solo tendremos que cambiar el formato del commit y añadiremos un tag al commit para que Travis lo detecte y realice así el deploy.

El formato para el commit será el siguiente:

V - x.y.z

Donde:

Por último, crearemos un tag usando los siguientes comandos:

git tag x.y.z - Este comando crea el tag.
git push origin --tags - Así subimos el tag a Github.
git push origin master - Y con este último asignamos el tag anterior al push.