Wiki de EGC - Contribuciones del usuario [es]

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

2018-02-06T10:40:18Z

Danmarsua1: /* Gestión de despliegue */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron tres milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.1 v1.1.1]:''' es la tercera versión del plugin, que incorpora mejoras en la seguridad de los formularios de configuración y corrección de errores menores.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit. Estos se ejecutarán automáticamente a través de Travis CI. Sin embargo, PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la API de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script.

'''.travis.yml''': '''la clave de toda la construcción e integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica que el proyecto se desarrolló en el lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción e integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis CI aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis CI ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis CI comienza a descargar el repositorio de GitHub a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis CI.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis CI, el repositorio oficial de GitHub de WordPress (mirror).
* A continuación, se crea la base de datos de MySQL que servirá para llevar a cabo las pruebas con WordPress, editándose también el fichero de configuración de la base de datos (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de WordPress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', a qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis CI.

Dicha parte de despliegue del script se explicará más detalladamente en el siguiente bloque.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste estaba asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual estaba asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

Como se comentaba en el bloque anterior, el despliegue se automatizó a través de [https://travis-ci.org/ Travis CI], en la parte final del script que se mostraba en dicho bloque. La consecución de tareas que lleva a cabo Travis CI en esta parte del código, es la que sigue:

# Con el ''skip_cleanup: true'' evitamos que Travis CI restablezca su directorio de trabajo y elimine todos los cambios realizados durante la compilación del script.
# La instrucción ''provider'' y los valores ''script'' y ''release'', hacen referencia a que el código de despliegue va a ejecutar un script propio (proporcionado) y además va a construir una ''release'' del proyecto.
# ''api_key'', ''secure'', hace referencia a la clave de api que requiere Github para automatizar el despliegue de la release requerida, donde ''"secure_key"'' no es la cadena que habría que poner, sino una clave de api válida para la automatización. Por cuestiones de integridad no se muestra en el ejemplo.
# A continuación de la instrucción ''script'' se llama al paquete ''SSH'', cuya herramienta ofrece un medio de conexión segura hacia otro servidor SSH de una máquina remota, un servidor construido por el equipo de integración con su configuración por cada submódulo del proyecto organizado de la asignatura, en nuestro caso el subsistema Redes Sociales.
# Posteriormente a la instrucción ''on'', el script se encarga de establecer varios parametros:
* Nombre del repositorio del que se va a llevar a cabo la release.
* Rama del repositorio que sirve como disparador de la release a la hora de hacer un commit en ella.
* Con que versión del lenguaje va a ser compatible (versión de php en nuestro caso).
* Si la release va a generar tag o no.
* Y el nombre de la propia release.

Ejecutando este fragmento de código, Travis esta configurado para llevar a cabo tanto el despliegue como la release simultáneamente.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron tres versiones del producto software: v1.0.0, v1.1.0. y v1.1.1. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T10:40:00Z

Danmarsua1: /* Gestión de despliegue */

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

2018-02-06T10:39:28Z

Danmarsua1: /* Gestión de despliegue */

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

2018-02-06T10:33:15Z

Danmarsua1: /* Gestión de despliegue */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron tres milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.1 v1.1.1]:''' es la tercera versión del plugin, que incorpora mejoras en la seguridad de los formularios de configuración y corrección de errores menores.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit. Estos se ejecutarán automáticamente a través de Travis CI. Sin embargo, PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la API de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script.

'''.travis.yml''': '''la clave de toda la construcción e integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica que el proyecto se desarrolló en el lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción e integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis CI aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis CI ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis CI comienza a descargar el repositorio de GitHub a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis CI.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis CI, el repositorio oficial de GitHub de WordPress (mirror).
* A continuación, se crea la base de datos de MySQL que servirá para llevar a cabo las pruebas con WordPress, editándose también el fichero de configuración de la base de datos (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de WordPress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', a qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis CI.

Dicha parte de despliegue del script se explicará más detalladamente en el siguiente bloque.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste estaba asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual estaba asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

Como se comentaba en el bloque anterior, el despliegue se automatizó a través de [https://travis-ci.org/ Travis CI], en la parte final del script que se mostraba en dicho bloque. La consecución de tareas que lleva a cabo Travis CI en esta parte del código, es la que sigue:

# Con el ''skip_cleanup: true'' evitamos que Travis CI restablezca su directorio de trabajo y elimine todos los cambios realizados durante la compilación del script.
# La instrucción ''provider'' y los valores ''script'' y ''release'', hacen referencia a que el código de despliegue va a ejecutar un script propio (proporcionado) y además va a construir una release del proyecto.
# ''api_key'', ''secure'', hace referencia a la clave de api que requiere Github para automatizar el despliegue de la ''release'' requerida, donde ''"secure_key"'' no es la cadena que habría que poner, sino una clave de api válida para la automatización. Por cuestiones de integridad no se muestra en el ejemplo.
# A continuación de la instrucción ''script'' se llama al paquete ''SSH'', cuya herramienta ofrece un medio de conexión segura hacia otro servidor SSH de una máquina remota, un servidor construido por el equipo de integración con su configuración por cada submódulo del proyecto organizado de la asignatura, en nuestro caso el subsistema Redes Sociales.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron tres versiones del producto software: v1.0.0, v1.1.0. y v1.1.1. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T10:18:05Z

Danmarsua1: /* Gestión de despliegue */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron tres milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.1 v1.1.1]:''' es la tercera versión del plugin, que incorpora mejoras en la seguridad de los formularios de configuración y corrección de errores menores.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit. Estos se ejecutarán automáticamente a través de Travis CI. Sin embargo, PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la API de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script.

'''.travis.yml''': '''la clave de toda la construcción e integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica que el proyecto se desarrolló en el lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción e integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis CI aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis CI ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis CI comienza a descargar el repositorio de GitHub a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis CI.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis CI, el repositorio oficial de GitHub de WordPress (mirror).
* A continuación, se crea la base de datos de MySQL que servirá para llevar a cabo las pruebas con WordPress, editándose también el fichero de configuración de la base de datos (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de WordPress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', a qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis CI.

Dicha parte de despliegue del script se explicará más detalladamente en el siguiente bloque.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

Como se comentaba en el bloque anterior, el despliegue se automatizó a través de [https://travis-ci.org/ Travis CI], en la parte final del script que se mostraba en dicho bloque. La consecución de tareas que lleva a cabo Travis CI en esta parte del código, es la que sigue:

# Con el ''skip_cleanup: true'' evitamos que Travis CI restablezca su directorio de trabajo y elimine todos los cambios realizados durante la compilación.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron tres versiones del producto software: v1.0.0, v1.1.0. y v1.1.1. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T10:02:14Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron tres milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.1 v1.1.1]:''' es la tercera versión del plugin, que incorpora mejoras en la seguridad de los formularios de configuración y corrección de errores menores.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit. Estos se ejecutarán automáticamente a través de Travis CI. Sin embargo, PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la API de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script.

'''.travis.yml''': '''la clave de toda la construcción e integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica que el proyecto se desarrolló en el lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción e integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis CI aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis CI ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis CI comienza a descargar el repositorio de GitHub a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis CI.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis CI, el repositorio oficial de GitHub de WordPress (mirror).
* A continuación, se crea la base de datos de MySQL que servirá para llevar a cabo las pruebas con WordPress, editándose también el fichero de configuración de la base de datos (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de WordPress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', a qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis CI.

Dicha parte de despliegue del script se explicará más detalladamente en el siguiente bloque.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron tres versiones del producto software: v1.0.0, v1.1.0. y v1.1.1. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:17:33Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': '''la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del script está en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', a qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:16:11Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': '''la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del script está en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX para navegar dentro de los directorios de la máquina de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:12:48Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': '''la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del script está en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica qué versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:12:24Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': '''la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del script está en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:11:31Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': '''la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:10:37Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre tests, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:10:00Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usarán posteriormente para el despliegue, al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:09:09Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa nuestro plugin para que pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:07:36Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:02:39Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarla a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T08:01:36Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia, con la instrucción ''before_deploy'', qué se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones del despliegue final dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarlo a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:55:48Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

'''líneas 31-final''': esta parte controla el despliegue del proyecto, en la que se hace referencia con la instrucción ''before_deploy'' que se quiere hacer justo antes de llevar a cabo dicho despliegue, seguida de la instrucción ''deploy'', que precede la instrucciones realizadas en la ejecución del despliegue dentro de Travis.

Comentar también, que existe una parte de código entre las '''líneas 39,40,41,43-48''' que se encargan del despliegue automatizado de una release del proyecto cada vez que se lleva a cabo un pull-request en master, o lo que es lo mismo, cada vez que se quiere integrar en el proyecto una mejora significativa para posteriormente llevarlo a producción.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:46:51Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se gestionan todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:45:31Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''PHPUnit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se encuentran todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:44:23Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a '''comenzar la construcción del proyecto'''. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''phpunit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se encuentran todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:44:03Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''': ''script'' es la instrucción que verdaderamente da pie a Travis CI a comenzar la construcción del proyecto. En esta instrucción se llama a la herramienta de integración de pruebas unitarias ''phpunit'', que se encuentra orquestada por el fichero al que se hacía referencia anteriormente, ''phpunit.xml'', en el que se encuentran todas las rutas a los ficheros de prueba (tests) y el orden en el que se quiere que se ejecuten.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:40:01Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y configuración de las pruebas unitarias: ''phpunit.xml''.

'''línea 29''':

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:38:50Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
* Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
* A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
* Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
* Para terminar, se volverá a la ruta raíz del repositorio, donde se encuentra el archivo esencial para la ejecución y confihuración de las pruebas unitarias: ''phpunit.xml''.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:36:22Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que Travis aún no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

'''línea 13''': esta instrucción, ''before_script'', hace referencia al instante en el que Travis ha terminado de importar todas las librerías y paquetes de herramientas que hicieran falta para la correcta ejecución y despliegue del proyecto, pero sigue sin comenzar la construcción del mismo. A partir de dicha instrucción, el servicio de Travis comienza a descargar el repositorio de Github a su imagen virtual de UNIX.

'''líneas 14-27''': estas instrucciones son propias de la shell de UNIX y se usan para navegar dentro de los directorios de la máquina UNIX de Travis.
- Priméramente se clona, en una carpeta temporal dentro de la máquina de Travis, el repositorio oficial de Github de Wordpress (mirror).
- A continuación, se crea la base de datos de mysql que servirá para llevar a cabo las pruebas con wordpress, editándose también el fichero de configuración de la BD de wordpress (''wp-tests-config.php'').
- Después, tomamos la carpeta de nuestro plugin, ''socialhub-egc'', y la movemos a la ruta de instalación de los plugins de wordpress, por defecto: ''.../wordpress/src/wp-content/plugins/''.
- Para terminar,

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:18:16Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo '''es la clave de toda la construcción/integración''', es el script de configuración que ejecuta Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que aún travis no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:15:11Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el script que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10''': esta instrucción, ''before_install'', hace referencia al momento en el que aún travis no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

'''línea 11''': esta línea de código es una llamada al paquete de herramientas de criptografía ''openssl'' instalado por defecto en UNIX. Dicha herramienta, entre otras funciones, tiene la finalidad de desencriptar el archivo de claves que se citaba anteriormente en este apartado, ''deploy.enc'', para poder llevar a cabo el despliegue cuando se requiera durante la ejecución del script.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:09:34Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 2''': en esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

'''líneas 5-8''': aquí se especifica que versiones de PHP se van a probar concretamente, con lo que Travis CI, lo primero que haría, sería descargarse dichas versiones del lenguaje antes de comenzar la construcción/integración.

'''línea 10-11''': esta instrucción, ''before_install'', hace referencia al momento en el que aún travis no ha comenzado la construcción del proyecto. Hasta este instante, Travis CI únicamente ha instalado las versiones que le hemos especificado en la instrucción anterior.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T07:01:33Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

'''línea 1''': En esta línea de código se especifica a Travis que el contenido del despliegue esta en lenguaje ''PHP''.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:58:11Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="php" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:57:41Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight lang="python" line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:57:08Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight start="1">
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:56:53Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight line start="1">
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:56:18Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

<syntaxhighlight line>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:55:31Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:
<syntaxhighlight>
# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC
</syntaxhighlight>

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:54:54Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "secure_key"
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:53:58Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "jflQViUjpvG86h8XCd5lSVYmKnJ7/gcpmCGkmT4xjHpkltF5DAvNuLPHSg1hdL0m3jBHZWrzV4dXIEvwLYLb2eUcmhh879T6i46sU/FqRmilb+vB8u/acL3mH56st+6FzKPo+/akctz5gtO/DZrG0X5fq/NptWfhzxKDLtbTI5TVcgmhl0h6bvYRY39cdhZ6Sg6xkD0KO5lc5WDSQbe+FAYHchkkAJT9mRZfPG7AB7EI/pRM73+6b8bqiL5XMTmzhiKOVA3ina+82ploDtD6/NLXMq4fkY3wgh+mkXCGyafGDBQ53w4eYx8PlxwS64X3/S0YVnYaChpfD69lgfCTCDXxXvUfZE9Cv3LfL8Hoinlvzyyrp7kT2VCxez733Q/S2L0xhrg3nYWavPV9FCLKMP1BgcUTXwwtZtwnhFuNo3cY25nZps0bW1t6kX7xNxmuC/xn3kgT2F1tQroOUU/glD1G/9tMhImgBk1Xwphlz/tjNxwxVYCrSfcZKJgTZ1s5R/sWF+bQmhSBEdYItt+lQ1ShYUQOFrpAYBAvsUllNL0Uk3ywXDuo8femkVrveRkLXLM1Ji6slUexTpyTrGBedffkh3WdNgw2Bz8FReFI9kAsLxttMXbWS33OKYMNDHzALh1hH+satFFOBR92AbLe4AfTfi+xPjCCitmLKrz1h8I="
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-06T06:53:17Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio.

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raíz del plugin de WordPress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los tests que se llevan a cabo a través de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de WordPress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de WordPress, también se activa el plugin para que éste pueda ser probado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test, que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua de software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

# Tell Travis CI we're using PHP
language: php

# PHP version used in first build configuration.
matrix:
include:
- php: "5.5"
- php: "5.4"

before_install:
- openssl aes-256-cbc -K $encrypted_cb20ac550795_key -iv $encrypted_cb20ac550795_iv -in deploy.enc -out deploy -d

before_script:
- export PLUGIN_SLUG=$(basename $(pwd))
- git clone https://github.com/tierra/wordpress.git /tmp/wordpress
- cd ..
- mv $PLUGIN_SLUG "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cd /tmp/wordpress
- mysql -e "CREATE DATABASE wordpress_tests;" -uroot
- cp wp-tests-config-sample.php wp-tests-config.php
- sed -i "s/youremptytestdbnamehere/wordpress_tests/" wp-tests-config.php
- sed -i "s/yourusernamehere/travis/" wp-tests-config.php
- sed -i "s/yourpasswordhere//" wp-tests-config.php
- cd "/tmp/wordpress/src/wp-content/plugins/$PLUGIN_SLUG"
- cp -r ./socialhub-egc ..
- cd ..
- cd "$PLUGIN_SLUG"

script: phpunit --colors="always"

before_deploy:
- chmod 600 deploy && mv deploy ~/.ssh/id_rsa
- curl -O https://raw.githubusercontent.com/EGC-G2-Trabajo-1718/integracion/master/tools/deploy-wordpress-subsistemas.sh

deploy:
skip_cleanup: true
provider:
- script
- releases
api_key:
secure: "jflQViUjpvG86h8XCd5lSVYmKnJ7/gcpmCGkmT4xjHpkltF5DAvNuLPHSg1hdL0m3jBHZWrzV4dXIEvwLYLb2eUcmhh879T6i46sU/FqRmilb+vB8u/acL3mH56st+6FzKPo+/akctz5gtO/DZrG0X5fq/NptWfhzxKDLtbTI5TVcgmhl0h6bvYRY39cdhZ6Sg6xkD0KO5lc5WDSQbe+FAYHchkkAJT9mRZfPG7AB7EI/pRM73+6b8bqiL5XMTmzhiKOVA3ina+82ploDtD6/NLXMq4fkY3wgh+mkXCGyafGDBQ53w4eYx8PlxwS64X3/S0YVnYaChpfD69lgfCTCDXxXvUfZE9Cv3LfL8Hoinlvzyyrp7kT2VCxez733Q/S2L0xhrg3nYWavPV9FCLKMP1BgcUTXwwtZtwnhFuNo3cY25nZps0bW1t6kX7xNxmuC/xn3kgT2F1tQroOUU/glD1G/9tMhImgBk1Xwphlz/tjNxwxVYCrSfcZKJgTZ1s5R/sWF+bQmhSBEdYItt+lQ1ShYUQOFrpAYBAvsUllNL0Uk3ywXDuo8femkVrveRkLXLM1Ji6slUexTpyTrGBedffkh3WdNgw2Bz8FReFI9kAsLxttMXbWS33OKYMNDHzALh1hH+satFFOBR92AbLe4AfTfi+xPjCCitmLKrz1h8I="
script: ssh -o StrictHostKeyChecking=no deploy@egc.duckdns.org 'bash -s' < deploy-wordpress-subsistemas.sh RedesSociales
on:
repo: EGC-G2-Trabajo-1718/RedesSociales
branch: master
php: '5.5'
tags: true
name: Versión v1.1.1 del plugin SocialHub by EGC

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:36:35Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de Wordpress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:27:10Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de Wordpress. Esto se hace mediante este archivo ''bootstrap.php''. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:26:43Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no se reduce únicamente a usar PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:26:12Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas que nos proporciona la api de Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:25:27Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración ''.travis.yml'', que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas (testeo) que nos proporciona Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración ''.travis.yml'' mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:24:37Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒deploy.enc
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas (testeo) que nos proporciona Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''deploy.enc''': este fichero es el que contiene las claves encriptadas que se usaran posteriormente para el despliegue continuo al final de todo el proceso, como se detallará al explicar el fichero de configuración ''.travis.yml''.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:22:12Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas (testeo) que nos proporciona Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''': este archivo es el que controla toda la construcción, que se hace a través de Travis CI (servicio distribuido de integración continua del software). Se adjunta a continuación, el contenido de dicho archivo y las lineas de código claves para que, construcción y automatización de pruebas, se lleven a cabo con éxito:

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:16:15Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas (testeo) que nos proporciona Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''':

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:15:58Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''bootstrap.php''': nuestra automatización de pruebas no es únicamente trabajo de PHPUnit, necesitamos la integración de pruebas (testeo) que nos proporciona Wordpress. Esto se hace mediante este archivo bootstrap.php. En él, además de hacer referencia al fichero bootstrap fuente de la propia instalación de wordpress, también se activa el plugin dentro de wordpress para que este pueda ser testeado.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona dicho archivo y que finalidad tiene.

'''.travis.yml''':

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:06:16Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc''': carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests''': directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''phpunit.xml.dist''': este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-02-05T13:05:06Z

Danmarsua1: /* Gestión de la construcción e integración continua */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== 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. 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 ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒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
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo 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. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

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

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI], junto con la herramienta de PHP para la integración de pruebas unitarias (tests): [https://phpunit.de/index.html PHPUnit].

Primero de todo, ha sido necesario disponer de, varios recursos entre directorios y archivos, dentro de nuestro repositorio. Se detalla la arquitectura a continuación:

📁socialhub-egc
📁tests
🗒bootstrap.php
🗒phpunit.xml.dist
🗒.travis.yml

'''socialhub-egc'''
Carpeta donde se encuentra el directorio raiz del plugin de wrodpress, esencial para la construcción e integración.

'''tests'''
Directorio que contiene todos los test que se llevan a cabo a traves de la herramienta PHPUnit, cuyo fichero, phpunit.xml.dist, permite ejecutar varios grupos de test de una sola ejecución. Esto respondería a la '''automatización de pruebas'''. Pero PHPUnit no se ejecuta solo, necesita ser llamado a través de una instrucción contenida en el fichero de configuración de travis (.travis.yml), que será descrito con detalle más adelante.

'''phpunit.xml.dist'''
Este fichero es el encargado de organizar la ejecución entre test que hace el propio PHPUnit, el orden y el fichero en sí, si queremos ejecutar archivos de uno en uno en determinado orden o si queremos programar la ejecución de pruebas de un directorio en concreto. Este archivo es al que se llama desde el fichero de configuración de travis (.travis.yml) mediante una instrucción especifica dentro del script. A continuación se especificará con detalle como funciona.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio. Para ello se realizan los siguientes pasos:

# Travis CI para que utilice lenguaje PHP a la hora de realizar los test.
# Descargamos WordPress de un repositorio oficial y lo introducimos a una carpeta temporal.
# Creamos una base de datos de MySQL ya que es necesario para la utilización de WordPress.
# Se renombra el fichero wp-tests-config-sample.php a wp-tests-config.php.
# Accedemos al repositorio de Redes Sociales, copiamos los plugins realizados y los introducimos en la carpeta de WordPress descargado anteriormente.

Con estos pasos llevados a cabo, Travis esta configurado para ejecutar los test realizados.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
Por un lado, se encuentran las herramientas que forman parte del entorno de desarrollo. Para ello, se dispone de Oracle VM VirtualBox, un software de virtualización, en los equipos de los desarrolladores. Éste tiene una máquina virtual de Debian con el contenedor de software Docker instalado, que tiene a su vez varias imágenes instaladas:
#WordPress: el sistema de gestión de contenido web que contiene el sistema SPLC. Aquí se integran con el resto del sistema y se prueban los widgets del proyecto.
#MySQL: el sistema de gestión de la base de datos del sistema.
#HTTP Apache: el servidor necesario para ejecutar WordPress.

Estas herramientas permiten desplegar de manera local el sistema. Además, se ha trabajado con el lenguaje de programación PHP, empleando como herramientas de desarrollo los editores de código fuente Notepad++ y Sublime Text. Por último, para gestionar el código fuente se ha utilizado un repositorio alojado en GitHub, el cual integra un sistema de control de versiones de Git.

Por otro lado, para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI, la cual está sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== 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 [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

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

2018-01-14T20:23:23Z

Danmarsua1: /* Mapa de herramientas */