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

De Wiki de EGC
Revisión del 13:59 8 ene 2018 de Albgomceb (discusión | contribuciones) (→‎Gestión de liberaciones, despliegue y entregas)
Saltar a: navegación, buscar


Gestión de integración con redes sociales


Grupo 2


ID de Opera:


Miembros

  • Galán Blanco, Cristian
  • García Rodríguez, Luis Miguel (coordinador)
  • Gómez Ceballos, Alberto
  • Huerta Cebolla, Juan
  • Martínez Suarez, Daniel Jesús
  • Ruano Enríquez, Carlos


Enlaces de interés


Resumen

La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

Introducción y contexto

Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final: 

📁socialhub-egc (carpeta principal)
   🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
   📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
      🗒class-share-button-widget.php
      🗒class-comment-box-widget.php
      🗒class-follow-button-widget.php
      🗒class-timeline-widget.php
      🗒class-RSS-widget.php
      🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

Descripción del sistema

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes. De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

Cambios que se han desarrollado para el proyecto

        POR HACER

Planificación del proyecto

Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar cada uno todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol. Se usó Trello como administrador de tareas y de horas. Este sistema no funcionó muy bien y tras el milestone 3 se cambió, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados.

La nueva planificación, ha sido la planificación usado durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente: 

Widget para timelines                               ->   Ruano Enríquez, Carlos
Widget para contactar a través de Twitter           ->   García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS                        ->   Gómez Ceballos, Alberto
Widget para comentarios                             ->   Galán Blanco, Cristian
Widget para compartir contenido en redes sociales   ->   Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales   ->   Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

Reuniones

A continuación se mencionan las reuniones que han sido necesarias por el grupo para la realización correcta del proyecto. Estas han podido ser tanto físicas como por vídeo llamada. Se menciona pues solo el nombre de cada asistente. 

         POR HACER

Entorno de desarrollo

Gestión del cambio, incidencias y depuración

Procedimiento para registrar una incidencia interna

Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:

  1. Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
  2. Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
  3. El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

Nota: se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

Formato

Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

Plantilla para issues

Etiquetas (labels)

Existen diferentes tipos:

  1. Etiquetas de estado:
    1. pending: aún no ha sido atendida por el encargado de gestionar las incidencias.
    2. in progress: se ha asignado a un responsable para solucionar la incidencia.
    3. finished: ya ha sido resuelta.
  2. Etiquetas de tipo:
    1. enhancement: propuesta de mejora.
    2. bug: fallos encontrados en el sistema.
    3. help wanted: issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
    4. question: a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
    5. new functionality request: para solicitar formalmente una nueva funcionalidad en el sistema.
    6. duplicate: cuando el issue está duplicado. Se debe referenciar al issue original.
    7. invalid: cuando el issue no cumple con el formato propuesto.
    8. wontfix: cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

Tareas

Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

Nota: se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

Gestión del código fuente

Commits

Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones. 

<tipo>: <título del commit>
(espacio)
<cuerpo del commit>
(espacio)
Issue #<número de la incidencia/tarea en GitHub>

Ejemplo: 

fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

Ramas (branches)

Disponemos de nueve ramas:

  1. Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
  2. Una rama develop que integre todas las funcionalidades implementadas.
  3. Una rama principal o master para los entregables.
  4. Una rama hotfix para errores detectados en producción.
Ramas

Gestión de la construcción e integración continua

Gestión de liberaciones, despliegue y entregas

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

  1. Descomponer el .zip en la carpeta compartida.
  2. Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
  3. Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
  4. Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
  5. Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
  6. Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.


FALTA: Política de nombrado e identificación de los entregables.

Mapa de herramientas

Ejercicio de propuesta de cambio

Conclusiones y trabajo futuro

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Gestión_de_integración_con_redes_sociales_-_17_18_-_G2&oldid=7173»