Documentación de Ortosia Cabina

Grupo: 1

Proyecto: Ortosia

Subsistema: Cabina

ID de opera: 130

• Mario Bizcocho González – Implicación: 5
• Alejandro Monteseirin Puig - Implicación: 5
• Camila Reyes Aroca - Implicación: 5
• Miguel Santos Batista - Implicación: 5
• Alex Volkov - Implicación: 0 (Abandono del grupo)

Enlaces de interés:

• Repositorio de cabina web en GitHub
• Repositorio del bot de Telegram en GitHub
• Repositorio de cabina en Unity en GitHub
• Aplicación de ortosia-prepro en Heroku
• Repositorio del bot de Slack en GitHub
• decide-ortosia en Travis
• Canal de Slack público
• Project Board en GitHub
• Aplicación de ortosia-cabina en Heroku
• Aplicación Unity en itch.io

Enlaces de documentación usados:

• https://docs.unity3d.com/es/2018.3/Manual/UnityManual.html
• https://api.slack.com/#read_the_docs
• https://docs.djangoproject.com/es/2.1/
• https://core.telegram.org/bots/api
• https://python-telegram-bot.readthedocs.io/en/stable/
• https://github.com/alesanmed/python-telegram-bot-seed
• https://github.com/ClaytonIndustries/HttpClient/wiki

Resumen

Decide es un sistema que originalmente sólo era interactivo mediante su interfaz gráfica hecha en Django. En Cabina, hemos querido diversificar las posibilidades de acceso al sistema de votación mediante la creación de un bot de Telegram, un bot de Slack y una aplicación hecha en Unity que se comunican con Decide mediante su API. Todos permiten iniciar sesión en el sistema y votar, y además los bots permiten crear una votación desde cero.

De esta forma, los usuarios pueden votar de la forma que prefieran, y ahorrando tiempo en el proceso (por ejemplo, votando desde Telegram en lugar de tener que abrir la página de Decide y votar ahí).

Además, hemos participado en la incorporación al sistema de votaciones con preguntas múltiples, pues antes sólo se permitía crear votaciones con una única pregunta, lo cual no era muy útil.

Introducción y contexto

La misión principal marcada por el equipo durante la vida del proyecto fue la de ampliar las posibilidades de un usuario a la hora de acceder a la cabina de una votación para permitir que las tecnologías usadas no fueran un impedimento para el usuario a la hora de ir a votar. Sin embargo no podíamos centrarnos solo en esto pues la iteración del resto de sistemas sobre decide produciría cambios a los que habría que adaptar la cabina ya existente (cabina web/booth) como por ejemplo las votaciones con preguntas múltiples.

"decide-ortosia" es el nombre del grupo de personas encargadas de iterar sobre el software decide. Decide-ortosia está dividido en subgrupos, uno por cada módulo de decide, salvo por el módulo cabina que tiene dos subgrupos de alumnos (ortosia-cabina y ortosia-cabina2)

Será importante también la comunicación entre los diferentes módulos de ortosia ya que el módulo de cabina depende directamente de otros dos módulos. El módulo principal del que depende es "Votación". Como ya se explica en el apartado Descripción del sistema, cabina recibe el id de una votación para posibilitar el voto a esta votación. Esto hace que con los cambios en el modelo de votación se afecte al módulo de cabina. Cabina también tiene dependencia con "Store", subsistema de "Mixnet" donde se almacenan los votos.

Descripción del sistema

Existen 4 subsistemas a contemplar dentro del sistema "cabina". 3 de ellos son completamente nuevos y desarrollados desde cero (bot de telegram, bot de slack, cabina de unity) mientras que el subsistema restante formaba ya parte del proyecto decide.

• Cabina-decide: Cabina web base de decide. Se trata de una interfaz web desarrollada en html y javascript con django. Carga una votación cuya id ha recibido en la url (ya que se encuentra en el sistema decide hace una consulta directa a base de datos para cargar la votación) y posteriormente envía el voto del usuario logeado mediante la llamada POST de la API de store. El cambio realizado ha sido una adaptación simple al nuevo modelo de votación, permitiendo votar en votaciones con múltiples preguntas
• Telegram-Bot: Se trata de un bot para Telegram que permite iniciar sesión, crear una votación y votar.Se despliega automáticamente en Heroku tras realizar cambios en el repositorio de GitHub del mismo. Su nombre es "Decide-Ortosia".
• Slack-Bot: Similar al bot de telegram, pero realizado en slack, permite crear votaciones loguearse en decide (obteniendo el token de autentificación) y permite realizar sus tests unitarios una vez desplegado desde el propio chat del bot. A su vez se auto-despliega en heroku a través de un repositorio de github tras realizar un push a su rama master.
• Cabina-Unity: Esta aplicación demuestra las posibilidades de integración de la plataforma Decide gracias a su API, y provee una interfaz de votación interactiva, tridimensional y en primera persona. Por cada votación se genera un pasillo en un edificio basado en la Escuela, y por cada pregunta dentro de esa votación, un aula. Dentro de la misma se genera una papeleta por cada opción, y se vota cogiendo esa papeleta y depositándola en la urna del aula. Una vez se ha votado en todas las preguntas, si se sale del pasillo de la votación, se envía el resultado. Si se sale sin haber votado en todas, se descartan los votos. Está desarrollado en Unity con C# y, al ser una aplicación de cliente, no tiene despliegue; es cuestión de descargar y ejecutar.

Planificación del proyecto

Puesto que se buscaba ampliar las posibilidades de los usuarios para votar sin dejar de darle soporte a la cabina web. Se asignó a cada participante del proyecto a una mejora sobre el sistema cabina completamente diferente.

Mario Bizcocho González: Encargado de la creación de la cabina Unity, también se encargará de la colaboración en la creación de documentación para el proyecto.

Alejandro Monteseirin Puig: Encargado de la creación de la cabina/bot en slack.

Camila Reyes Aroca: Encargada de la creación de la cabina/bot en telegram, también será la responsable de la definición de los procesos de gestión.

Miguel Santos Batista: Encargado de continuar con el soporte a la cabina web, también se encargará de la colaboración en la creación de documentación para el proyecto.

Alex Volkov: Encargado de la creación de una nueva cabina web usando la biblioteca React.1

En el caso de las mejoras que incluían la creación de nuevas cabinas, cada encargado sería responsable de llevar al menos una nueva iteración sobre su subsistema a cada milestone. En el caso del encargado de continuar con el soporte a la cabina web deberá controlar la evolución del resto de sistemas de decide y adaptar la rama de "ortosia-cabina" para que la cabina web sea compatible con las nuevas funcionalidades que añadan el resto de los grupos en todo momento.

Para planificar los hitos nos hemos reunido después de cada hito para planificar el contenido que debería estar disponible para el siguiente. Esta es la planificación resultante.

Milestone 1:

• Todos los miembros del grupo deberán tener montado el entorno de desarrollo con el proyecto base de manera completamente funcional.
• Debe existir un proceso de gestión de código definido.
• Debe existir un proceso de gestión de incidencias definido.
• Deben quedar descritos los cambios que se harán sobre el proyecto base.
• Se debe imprimir y rellenar el entregable del milestone de la wiki.

Milestone 2:

• Implementar gestión de integración continua con Travis CI (Camila)
• Implementar gestión de despliegue con Heroku (Camila)
• Adaptar el dockerfile a nuestra rama (Camila)
• Bot de telegram lanzable y respondiendo a comandos simples (Camila)
• Bot de slack lanzable y respondiendo a comandos simples (Alejandro)
• Cabina de Unity ejecutable e interactuable (Mario)
• Cabina web adaptada al nuevo modelo de voting con múltiples preguntas (Miguel)
• Cabina react configurada, sin ser necesario que cargue votaciones (Alex)

Milestone 3:

• Merge de ortosia-prepro hacía ortosia-cabina asegurando que se mantienen las funcionalidades de ortosia-prepro y las de ortosia-cabina (Miguel)
• Bot de telegram es capaz de votar (Camila)
• Bot de slack es capaz de votar (Alejandro)
• Cabina de unity es capaz de votar (Mario)
• Rama lanzable en heroku (Camila)
• Documentación entregada antes del día 13/01/19 (Mario y Miguel)

Milestone 4:

• Integración continua en el proyecto del bot de telegram (despliegue en Heroku mediante Travis) (Camila)

Cada miembro del grupo se hizo responsable de la división de las tareas asignadas en issues asignadas al Project de GitHub del grupo de trabajo y de tener dichas issues listas para cada milestone. Más información en Gestión de código fuente y Gestión de incidencias.

Entorno de desarrollo

Cada desarrollador implicado en el proyecto ha usado diferentes entornos de desarrollo ya que cada cabina se comunicaba mediante llamadas API. Aun así todos los entornos de desarrollo comparten el software necesario para la ejecución local de decide.

• IDE: VS Code
• Docker (No es imprescindible para el desarrollo)
• Python 3
• Git
• Postgres
• Dependencias descritas en requirements.txt : Django 2.0, pycryptodome 3.6.6, djangorestframework 3.7.7, django-cors-headers 2.1.0, requests 2.18.4, django-filter 1.1.0, psycopg2 2.7.4, django-rest-swagger 2.2.0, python-telegram-bot, inflection, datetime, slackclient 1.1.0 (o superior), django-heroku, gunicorn, coveralls.

Para instalar el entorno de desarrollo del sistema común se deben seguir los siguientes pasos:

1. Instalar el IDE, Docker, Python, postgres y git.
2. Clonar el repositorio de git
3. Configurar local_setting.py basándose en local_setting.example.py (se encuentra en el directorio decide/decide/local_setting.example.py
4. Instalar las dependencias de requirements.txt pip install -r requirements.txt
5. Crear la base de datos de postgres

sudo su – postgres
psql -c "create user decide with password 'decide'"
psql -c "create database decide owner decide";

1. Dentro del directorio decide/decide realizamos la primera migración

./manage.py migrate
./manage.py createsuperuser

1. Se ejecuta el servidor local ./manage.py runserver

A continuación se detallan las características de los entornos de desarrollo de cada una de las diferentes cabinas desarrolladas.

Slack-bot : Se ha utilizado Visual Studio Code con las siguientes extensiones,obtenidas directamente desde el Marketplace oficial, estas son opcionales pero facilitan enormemente el trabajo, se enumeran a continuación, junto a una breve explicación:

• Python: Permite formatear el código además de debugear los errores
• Indent-rainbow: Facilita la indentacion de una manera muy visual (usando hasta 4 colores para cada nivel de indentacion), especialmente útil en un proyecto de python

Para realizar los commits y push a git correspondientes al bot de slack se ha utilizado el motor visual SourceTree, por el simple hecho de que el encargado del bot de slack estaba más familiarizado con este motor, realmente se puede utilizar cualquiera.

También se ha utilizado Python para Windows mediante una consola cygwinpara realizar los despliegues en local y poder testear el bot sin necesidad de desplegar continuamente en Heroku.

Telegram-bot: Para el desarrollo de este bot se ha usado Visual Studio Code, nuevamente. Se han usado las mismas extensiones que en el caso del bot de Slack, es decir, la extensión oficial de Python además Indent-rainbox para facilitar la indentación.

Para subir los cambios al repositorio de GitHub, actualizar, etc., se ha usado siempre la línea de comandos de Git.

Unity-booth: El desarrollo de la aplicación en Unity se ha realizado con este motor gráfico y Visual Studio Community 2017. Se han usado los siguientes assets gratuitos de la tienda oficial de Unity:

• Http Client (Clayton Industries): añade herramientas para hacer peticiones a servidores web de forma sencilla.
• TextMesh Pro (Unity Technologies): Añade soporte para fuentes vectorizadas

También se han usado modelos 3D gratuitos para poblar la aplicación. La gestión de repositorio se ha hecho mediante Git en línea de comandos y GitKraken a partes iguales.

Gestión de incidencias

Para gestionar las tareas e incidencias se hará uso del Project Board que ofrece GitHub. Este Project Board es un tablero Kanban que dispone de 3 columnas: To do , In progress y Done. Hemos añadido una cuarta columna: In revision. En esta columna se situarán todas las issues que se considere que están terminadas por la persona destinada a ello. Otra persona distinta a la que ha realizado la issue, debe revisar que se ha cumplido correctamente. En caso afirmativo, cierra la issue y se sitúa en la columna Done. En caso negativo, se pone un comentario especificando el problema y vuelve a moverse a la columna To do.

Al crear una nueva issue, esta debe tener todas las etiquetas (labels) correspondientes, ser asociada a un Milestone y a las personas encargadas de realizarla y/o interesadas.

Sólo puede haber una issue en progreso (en la columna In progress ) por persona.

Es necesario asociar los commits a las issues como se explicará posteriormente en el apartado, gestión del código fuente.

Gestión de depuración

El sistema de gestión de depuración seguido en nuestro proyecto ha sido simple debido a la naturaleza de nuestra distribución de trabajo, según la cual más o menos cada persona ha trabajado en su propio subsistema y no debería haber conflictos que afectasen al trabajo de otras personas. Sin embargo, sí hemos definido un proceso consistente en la apertura de una issue cuando se detectara algún fallo. Esta issue iría vinculada al milestone correspondiente, tendría asignado al encargado o encargados de solucionarlo y en la descripción se comentaría el tipo de error y qué sistema se prevé que esté afectado. Se le asignaría mínimo la etiqueta “bug”, la “invalid” y una de prioridad dependiendo de cómo de urgente fuera. El resto del mantenimiento sería como una issue convencional.

Un ejemplo de gestión de depuración se puede ver en este issue, en el que los cambios hechos por el grupo de Store hicieron fallar nuestros tests. Se asignó a Camila Reyes y Miguel Santos como encargados de solucionar los errores por nuestro lado, además de etiquetas “bug”, “invalid” y “priority: medium”. Se asignó al M2 y se puso en To Do en el tablero. Cuando Miguel Santos empezó a trabajar en solucionarlo se pasó a In progress, luego hubo una serie de commits relacionados con la solución de este problema, se asignó a In revisión, se vio que seguía sin funcionar, se movió de nuevo a To do, y se solucionaron los errores durante un merge con la rama de preproducción, cerrando la issue.

Gestión del código fuente

Para gestionar el código, los miembros del grupo han seguido la siguiente serie de pautas:

• Se usará GitHub para la gestión de repositorios y código.

• Existirán cuatro repositorios, uno por cada funcionalidad implementada:

  • El primer repositorio es el que se comparte con los demás grupos que conforman Decide – Ortosia. En este repositorio, tenemos nuestra propia rama, llamada ortosia-cabina, en la que se integrarán todos los cambios de los demás subgrupos y se subirán nuestros propios cambios (aquellos relacionados exclusivamente con el sistema de Decide desarrollado en Django, en nuestro caso, la gestión de preguntas múltiples).
  • Un repositorio para el bot de Telegram, ya que realmente es un proyecto "externo" a Decide (aunque realiza llamadas a su API, es un proyecto completamente nuevo e independiente).
  • Un repositorio para el bot de Slack, siguiendo la explicación expuesta para el bot de Telegram.
  • Un repositorio para la aplicación de Unity, siguiendo nuevamente la explicación anteriormente expuesta.

• Se permite realizar push con varios commits. Es decir, no se obliga a hacer un push por commit.

• El mensaje de los commits debe seguir el siguiente formato en la mayoría de los casos:

Es decir, si el commit se corresponde con alguna issue debe vincularse a ella obligatoriamente. Siempre debe tener título y descripción. Además, el mensaje siempre debe expresarse en inglés.

Cuando se cierre una issue, en el mensaje del commit se sustituirá "[#issue]" por "[close #issue]", de forma que automáticamente la issue se cierre y se sitúe en la columna de tareas realizadas.

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

Para la integración continua se siguieron las siguientes pautas:

• Al terminar una sesión de trabajo, y antes de hacer commit se ejecutarán los test unitarios. El hecho de que no se pasen los test unitarios no implica que no se deba hacer commit, si los test unitarios en local fallan, el responsable de los cambios seguirá el siguiente proceso:
  • Si la razón del fallo es un error por parte del responsable en sus cambios no tiene que abortar el commit pero pospondrá el push de dichos commits al repositorio de origen hasta que se estén pasando los test a no ser que se necesiten los cambios en origen con urgencia.
  • Si la razón del fallo es que ha habido un cambio en el código o los modelos que precisa de una adaptación en los test el responsable commiteará y pusheará y creará una issue "Fix test" asignada al responsable de dichos test.
• Tras el push a origen se hará un build con travis de manera automática. Durante la build en travis se ejecutará y pusheará la imagen de Docker y se desplegará en Heroku.

En caso de que falle la build en Travis se debe solucionar el error que esté provocando que falle la build antes de cerrar la issue.2

Como se ha explicado en el proceso de gestión, las herramientas principales usadas durante la integración continua han sido Travis y Docker (Siendo Heroku más bien una herramienta para la gestión de despliegue). A continuación, se detallará brevemente la configuración de Docker y Travis en este proyecto. Para más detalle se puede consultar la documentación oficial aportada en el apartado "Mapa de Herramientas"

La imagen de Docker ejecutará las siguientes instrucciones:

1. Se instalan las dependencias gunicorn, psycopg2, ipdb, ipython
2. Se clona la rama ortosia-cabina dentro del directorio /app
3. Se instalan todas las dependencias de requirements.txt
4. Se copia la configuración docker-setting como local_setting (usada por la aplicación decide) dentro del directorio /app/decide

Durante la build de travis se realizan las siguientes acciones:

1. Se cargan las variables del entorno usadas para el logeo en Docker y Heroku.
2. Se instalan las dependencias de requirements.txt
3. Se copia la configuración docker-setting como local_setting (usada por la aplicación decide) dentro del directorio /decide
4. Se crea la base de datos y su usuario y se ejecutan las migraciones.
5. Se ejecutan los test (Unitario y de cobertura).
6. Se ejecuta la imagen de Docker y se pushea a Dockerhub.
7. Se hace deploy en Heroku de la imagen pusheada a Dockerhub

https://travis-ci.org/pablotabares/decide/jobs/475689973

https://github.com/pablotabares/decide/blob/ortosia-cabina/.travis.yml

En el caso del bot de Telegram, al realizar un push a cualquier rama se ejecuta una nueva build en Travis. En dicha build se ordena el análisis del código mediante SonarQube, y además se pasan los tests. Si estos resultan exitosos, la aplicación es desplegada automáticamente en Heroku.

Gestión de liberaciones, despliegue y entregas

Liberaciones

Nuestro sistema de control de liberaciones, por la naturaleza variada de nuestras contribuciones, ha seguido caminos distintos. En nuestras contribuciones a Decide, dado que solo teníamos una rama para este fin, hemos seguido un esquema de liberación incremental usando nuestra rama como rama de desarrollo, considerando las compilaciones estables según Travis (ver gestión de despliegue) como nuestras liberaciones. De este modo seguimos dos líneas de lanzamiento, la nuestra (en Heroku, ver despliegue) y la de Decide-Ortosia, con los cambios integrados de todos los grupos.

• Slack-bot: La gestión de liberaciones para la aplicación Slack ha sido muy progresiva, añadiendo pequeñas funcionalidades progresivamente. Para cada milestone se ha llevado una versión estable de los cambios, dejando los cambios que aún no estaban estables en la rama de desarrollo.
• Telegram-bot: Entre milestones se han implementado nuevas funcionalidades y se ha realizado corrección de errores. En el primer milestone se creó un bot de telegram básico que saludaba, en el segundo se implementó la opción de crear votaciones y para el tercero la posibilidad de votar en las mismas.
• Unity-booth: la gestión de liberaciones para la aplicación Unity ha sido simple. En cada milestone se ha implementado un paso de funcionalidad, y para cada milestone se ha compilado un lanzamiento parcial. En el primer milestone la funcionalidad era caminar por el escenario; en el segundo se podía entrar a Decide iniciando sesión y se generaba el primer nivel de pasillos, y en el tercero ya se puede votar y se generan los pasillos y las aulas para cada votación en la que el usuario con sesión iniciada puede votar (y que esté soportada por el sistema). Estas versiones estables son las que se pueden considerar lanzamientos, ya que se llegaron a compilar y a empaquetar como ejecutable separado del entorno de desarrollo.

Despliegue

Para la gestión de despliegue de la cabina web hemos usado Heroku y Travis, después de una build exitosa de Travis se hace un despliegue de manera automática en Heroku. Debido a esto tras cada push se realiza un despliegue del sistema

Slack-Bot** :** El despliegue del bot de Slack se realiza en un repositorio independiente usando Heroku, consta de dos ramas una de desarrollo (dev) y una rama maestra (master), los cambios se prueban en la rama de desarrollo y solo se mergean con master tras comprobar que funciona correctamente mediante los tests del bot de slack (usando @Ortosia testeate! en el canal de Slack), el despliegue de Heroku se realiza automáticamente en la rama master tras cada push, también se pueden realizar despliegues manuales desde Heroku de cualquier rama del repositorio.

Telegram-Bot** :** El repositorio en el que se aloja el proyecto del bot de Telegram ha sido integrado con Heroku, de forma que cuando se hace un push a la rama principal, se realiza el despliegue en Heroku.

Unity-booth: El programa en Unity, al ser una aplicación de cliente y no una aplicación web distribuida, se despliega descomprimiendo un archivo ZIP. El ejecutable resultante es compatible con sistemas operativos Windows, y debe ser extraído al completo (no solo el ejecutable), ya que va acompañado de una carpeta de archivos de datos y unos DLL necesarios para la ejecución del programa. Se requiere de conexión a Internet, ya que el software se comunica con nuestro despliegue de Decide en Heroku.

Para la gestión de entregas hemos usado el sistema de Milestones de GitHub, cada issue debe estar completa antes de la fecha del hito asociado a dicha issue. En el caso de que el hito caduque antes de que el responsable pueda cerrar la issue este deberá mover la fecha al próximo hito programado y evaluar si es preciso elevar la prioridad de dicha issue.

Mapa de herramientas

A continuación se detallan los elementos de Ilustración 1:

Git : Software de control de versiones, se usa tanto en local como en remoto.

Github : Es una forja (plataforma de desarrollo colaborativo) que utiliza git para el control de versiones. Cada vez que hacemos push desde el repositorio local al repositorio origen se lanza la build de travis.

Travis : Servicio de integración continua. En nuestro proyecto se encarga (entre otras cosas) de pushear la imagen de Docker del sistema a Dockerhub y luego lanza esa imagen recién subida en Heroku.

Dockerhub : Comunidad y librería de imágenes Docker. En Dockerhub almacenamos nuestra imagen Docker.

Heroku : Servicio de computación en la nube. La imagen Docker de nuestro sistema se lanza en Heroku.

Ejercicio de propuesta de cambio

Problema : Existen en desarrollo 4 cabinas completamente diferentes, la base web, el bot de telegram, el bot de slack y la cabina en unity. Estos subsistemas son muy diferentes unos de otros y añaden mucho contenido nuevo a la rama ortosia-cabina (claro ejemplo la cabina de unity que añade muchos recursos). Esto provoca que cada vez que se quiera bajar la rama se obligue al usuario a bajar muchos recursos que pueden resultarle completamente innecesarios.

Decidimos que lo mejor sería reestructurar el repositorio creando una organización que contenga un repositorio por cada funcionalidad. Además, a excepción de la cabina web, las cabinas no precisan estar desplegadas en el mismo entorno que el sistema decide ya que se comunican por API.

Issue asociada : https://github.com/pablotabares/decide/issues/126

Tras crear la issue en github se le añadieron las etiquetas correspondientes, el milestone asociado y se le asignó a los 3 responsables.

La responsable principal cambió manualmente el estado de la issue de "To do" a "In progress". Esto se hizo desde Projects de github mediante la mecánica "drag'n drop".

Primeramente secreó la organización en github. Desde el apartado para ello se la nombró "ortosia-cabina", se usó el correo de la responsable principal de la issue y se eligió el plan de pago "Team For Open Source" (gratuito).

Una vez creada la organización ortosia-cabina la responsable principal de la issue (y dueña de al organización) envió las invitaciones a todos los miembros de ortosia-cabina. A continuación se crearon los repositorios telegram-bot, unity-booth y slack-bot usando la interfaz proporcionada por github para ello. Desde la interfaz principal de la organización se pulsa sobre "New" como puede verse en la Ilustración 2.

Se le dio un nombre a cada repositorio (cada responsable se encargó de crear su propio repositorio) y se marcó la opción de inicializar automáticamente el repositorio por parte de github, pueden verse estás opciones en la Ilustración 3.

Una vez creados los repositorios cada responsable copió su subsistema al nuevo repositorio. Los pasos a seguir, en el caso del subsistema "telegram-bot" fueron:

1. 1)Clonar el repositorio en local, desde el directorio al que se quiere clonar el repositorio: git clone https://github.com/ortosia-cabina/telegram-bot
2. 2)Cortar el contenido del subsistema de la rama ortosia-cabina y pegar en el directorio del nuevo repositorio.
3. 3)Añadir un procfile al repositorio, se puede ver aquí https://github.com/ortosia-cabina/telegram-bot/blob/dd5a4dc274e29c1502b49aef7288b2d59532c0c1/Procfile

el contenido de dicho procfile.

1. 4)Añadir los cambios al stage, en directorio del repositorio: git add . Este comando añade al stage todo los cambios en el repositorio.
2. 5)Commitear el stage: git commit -m mensajedecommit
3. 6)Pushear los commits del repositorio a origen: git push origin HEAD Este comando pushea los commits de la rama actual a origen.

A continuación se cubren los pasos para hacer los sistemas funcionales en sus nuevos repositorios (descritos en la descripción de la issue) crear una aplicación en heroku para cada subsistema y actualizar cada procfile.

En el caso del subsistema "telegram-bot", para crear la aplicación en heroku:

1. 1)Logear en Heroku, comando: heroku login, esto abrirá en el navegador el login de heroku.
2. 2)Crear la aplicación heroku, comando: heroku create "ortosia-telegram-bot"
3. 3)Añadiendo el remote, desde el directorio del repositorio: heroku git:remote -a "ortosia-telegram-bot"

Una vez hecho esto se procedió a eliminar los recursos de la rama de ortosia-cabina del repositorio original. Para esto se eliminó del repositorio local y se volvieron a seguir los pasos anteriores para confirmar, commitear y pushear los cambios a origen.

https://github.com/pablotabares/decide/commit/0a3c33bafcf0707c7410d4067834ce3ad9a863e6

Los otros responsables de los subsistemas restantes siguieron cambios similares para reestructurar los subsistemas.

Una vez todos los subsistemas fueron funcionales en sus nuevos repositorios la responsable principal del cambio comentó desde github cerrando la issue como puede verse en la Ilustración 4.

Quedando ya el cambio completamente implementado.

Conclusiones y trabajo futuro

Mejoras Unity-booth:

• Utilizar tests unitarios en la prueba de próximas funcionalidades, lo que requeriría una reestructuración del esquema de compilación.
• Crear muros al final de los pasillos para evitar que el usuario salga de la estructura donde se vota.
• Implementar soporte para el sistema de votación con preguntas desbloqueables.

Mejoras Bot-Slack:

• Integrar los tests que se lanzan con el comando "@Ortosia testeate!" con Travis, permitiendo así que los test se lancen automáticamente en cada push al repositorio.
• Seguir con las llamadas a la API de decide, permitiendo realizar las opciones que le faltan al bot y extenderlas.

Mejoras Bot-Telegram :

• Crear una pila de tests que prueben las distintas funcionalidades del bot.
• Integrar estos tests y el despliegue en Heroku con Travis, de forma que se realice el despliegue únicamente cuando los tests resulten exitosos.
• Mandar los votos encriptados.
• Realizar un bot usando la API de Telegram, ha permitido ganar experiencia con la misma y aprender algo más aparte de Django.

Mejoras y conclusiones Cabina Web:

• Sería recomendable insistir en la resolución de la issue https://github.com/pablotabares/decide/issues/156 en prepro. Existe un workaround en la rama ortosia-cabina para dicha issue pero no puede ser llevado a prepro sin la aprobación de mixnet.
• Debido a que existen dos grupos de cabina en decide-ortosia ha existido descoordinación en el trato recibido por cabina web en prepro ya que empezó a recibir cambios por parte de cabina2 antes que de cabina dejando obsoletas algunas iteraciones realizadas en la rama ortosia-cabina. Sería recomendable mejorar la comunicación entre cabina y cabina2 para evitar casos como este.