Gestión de integración con redes sociales

Grupo 2

ID de Opera: Grupo 4 (2017-2018)

Miembros

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 por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama SocialHub by EGC y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... 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, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

Introducción y contexto

La página web SPLC 2017 de la que dispone la asignatura está montada con WordPress un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales. Las funcionalidades elegidas son las siguientes:

Botones de compartir, se trata de un widget que permite compartir en cada red social (si esta dispone de ello) el contenido deseado de la web. Caja de comentarios de Facebook, haciendo uso de la API de Facebook, esta caja nos permitirá comentar en cualquier página de nuestra web, permitiendo incluso reflejar esos comentarios en nuestro tablón. Botón de seguir, botones de las diferentes redes sociales de la web para poder seguirlas con nuestras cuentas personales. Linea de tiempo (timeline) de redes sociales, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter, Facebook, Instagram y Google+. RSS, botón que genera un archivo RSS para poder seguir las publicaciones de la web. Mensajes directo en Twitter, botón que permite crear y enviar un mensaje directo a una cuenta concreta de Twwiter.

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 (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

Descripción del sistema

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.

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 el lugar deseado de nuestra página web. Esto quiere decir que podemos añadir el widget x sin tan siquiera tener que introducir los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en el lugar deseado 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.

Cambios que se han desarrollado para el proyecto

Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, 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, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió. De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación mencionada brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

Planificación del proyecto

Se describe a continuación la planificación usada 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. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

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 principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

Noviembre 15

             Orden del día:
             1. Establecer flujo de comunicación.
             2. Decidir entorno de desarrollo.
             3. Acordar una fecha para la siguiente reunión.
             Descripciones:
             1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
             2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la 
             instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
             3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

Noviembre 27

             Orden del día:
             1. Hacer una retrospectiva del Milestone 1.
             2. Crear repositorio de código en GitHub.
             3. Establecer un protocolo para la gestión de código.
             4. Establecer un protocolo para la creación de incidencias.
             5. Establecer un protocolo para la gestión de tareas.
             6. Asignación de tareas.
             7. Acordar una fecha para la siguiente reunión.

             Descripciones:
             1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
             2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
             3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
             4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
             5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
             6. Se han asignado a cada desarrollador una red social.
             7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

Diciembre 22

             Orden del día:
             1. Hacer una retrospectiva del Milestone 3.
             2. Cambiar sistema de gestión de tareas.
             3. Modificar el Git Workflow acordado hasta la fecha.
             4. Redistribución de las tareas
             5. Acordar una fecha para la siguiente reunión.

             Descripciones:
             1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el 
             Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro               
             del equipo.
             2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las 
             tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
             3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master 
             siguen igual.
             4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
             5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

Enero 8

             Orden del día:
             1. Acordar fecha de publicación de la primera versión.
             2. Aprobación de las tareas de documentación.
             3. Nuevas asignaciones de tareas para la siguiente versión.

             Descripciones:
             1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
             2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
             3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

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:

Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
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.

Procedimiento para registrar una incidencia externa

Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

Formato

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

Plantilla para issues

Etiquetas (labels)

Existen diferentes tipos:

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.
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:

Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
Una rama develop que integre todas las funcionalidades implementadas.
Una rama principal o master para los entregables.
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:

Descomponer el .zip en la carpeta compartida.
Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
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
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.
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.
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

La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin SocialHub by EGC cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
Integrar más redes sociales como Pinterest o Flickr.
Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
Publicar el plugin en el repositorio de WordPress.

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

Contenido