Diferencia entre revisiones de «Verificación Grupo 2 (Curso 2016-2017)»
(→Aspectos Organizativos) |
(→Ecosistema de desarrollo) |
||
| Línea 89: | Línea 89: | ||
* '''Jenkins''' | * '''Jenkins''' | ||
* '''Git''' | * '''Git''' | ||
| + | |||
| + | |||
| + | === Gestión de código fuente === | ||
| + | |||
| + | '''*Introducción''' | ||
| + | Para que todos los alumnos de la asignatura tengan acceso al código fuente del sistema AGORA-US se ha creado un grupo en la plataforma Github llamado AgoraUS-G2-1617. En este grupo encontraremos un repositorio git para cada subsistema. | ||
| + | |||
| + | '''Primeros pasos''' | ||
| + | * El jefe de proyecto se encargará de crear el repositorio para el subistema de Verificación dentro del grupo AgoraUS-G2-1617.Justo después de crear el repositorio correspondiente al sistema de Verificación, realizará un fork al repositorio que contiene al susbsitema de Verificación desarrollado por los compañeros del Grupo2 del año 15/16 | ||
| + | |||
| + | * El jefe de proyecto añadirá a todo el equipo al repositorio una vez el fork haya sido realizado. | ||
| + | |||
| + | '''Metodología para subir los cambios''' | ||
| + | |||
| + | === Gestión de conflictos === | ||
| + | '''Introducción''' : si se diera el caso de un conflicto, el miembro del equipo que se haya topado con el mismo será el responsable de resolverlo. Para ello tendrá que comunicarlo al equipo para ponerse de acuerdo con el miembro o miembros para acordar la versión correcta del código. | ||
| + | |||
| + | ''' Resolución de conflictos ''' : cuando se produce un conflicto Git nos impide realizar el push correspondiente mostrándonos un aviso del mismo. Una vez se ha comunicado el conflicto al miembro o los miembros implicados se resuelve el conflicto manualmente y se vuelve a realizar el push. | ||
| + | |||
| + | === Gestión de la integración continua === | ||
| + | |||
| + | === Gestión de incidencias === | ||
Revisión del 00:38 5 sep 2017
Contenido
Miembros
- Hugo Ramos Rico Jefe de Proyecto
- Alberto Castillo Molina Ingeniero Software
- Alejandro García García Ingeniero Software
- Andrés García González Ingeniero Software
- Dylan Moreno Téllez Ingeniero Software
Aspectos Organizativos
Introducción
Punto de partida: en las primeras semanas de clase se explica la composición del sistema de votación online Agora-US y cada uno de los módulos/subsistemas que lo componen. Estos subsistemas han sido desarrollados por alumnos que han cursado la asignatura en años anteriores. Tras conocer cuales van a ser los módulos que componen Agora-US y haber formado los equipos, el profesor David Benavides organiza una reunión para que los alumnos de la asignatura elijan sus subsistemas y empiecen a comunicarse con los grupos cuyos subsistemas están relacionados
Objetivo del proyecto: estudiar el subsitema desarrollado anteriormente, viendo las posibles mejores o posibles bugs que existán en el mismo y realizar una documentación lo más óptima posible para que así quede constancia de la evolución que este subsistema ha sufrido a lo largo del tiempo. Todo ello sin perder de vista la integración con los demás subsistemas de Agora-US
Subsistema de verificación : el módulo de verificación es aquel que se encargará de las siguientes funciones dentro de Agora-US:
* Creación de claves públicas y privadas para las distintas votaciones. * Comprobar si un voto ha sido cifrado correctamente o no. * Comprobar que la votación no ha sido adulterada.
Subsistema relacionados con Verificación :
- Administración de votos
- Cabina de votación
- Almacenamiento
Gestión de tareas
- Para la gestión de tareas se usará TRELLO
https://trello.com/b/RyU5wy2S/trabajo-egc-verificacion
Código heredado
Partiremos del código utilizado por el Grupo del año pasado alojado en el siguiente git: https://github.com/jeparca/EGCVerificacion15
Se han encontrado una serie de errores en el código del curso anterior:
-Los métodos usados en la clase Token.java estaban como "private" en vez de "public". -La clase VerificacionTest.java tenía copiado los métodos de la clase Token.java en lugar utilizar los métodos de esta clase, ya que son los mismos. -El código de la clase Token.java que usaban Assert no estaba capturado con try-catch.
Repositorio de código
- Se utilizará Git como herramienta de gestión de código y se podrá acceder al repositorio desde https://github.com/AgoraUS-G2-1617/G27
Gestión de incidencias
- Se utilizará la función issues de GitHub, pudiendo cada miembro del equipo abrir una incidencia explicando de forma breve la solución de la misma y procediendo a su cierre.
Máquinas virtuales
La máquina virtual que se ha usado para el desarrollo del trabajo presenta las siguientes características:
- Windows7 - (Contraseña del usuario Desarrollo : desarrollo) - MySQL 5.7 (Workbench en la versión 6.3) - (Usuario:root // Contraseña:desarrollo) - Maven 3.3.9 - Tomcat 8.5 - Jenkins - Git 2.11 - Github - Eclipse Neon
Enlace Máquina Virtual: https://www.dropbox.com/s/7baeq23wxb24cm1/W7.zip?dl=0
Actas de reunión
Ecosistema de desarrollo
Tecnologías y herramientas
El equipo de trabajo decide crear una máquina virtual para facilitar la gestión del código a futuros compañeros de la asignatura, dicha máquina virtual cuenta con las siguientes tecnologías y herramientas:
- Java7
- Maven
- Tomcat
- MySQL
- MySQL Workbench
- Jenkins
- Git
Gestión de código fuente
*Introducción Para que todos los alumnos de la asignatura tengan acceso al código fuente del sistema AGORA-US se ha creado un grupo en la plataforma Github llamado AgoraUS-G2-1617. En este grupo encontraremos un repositorio git para cada subsistema.
Primeros pasos
- El jefe de proyecto se encargará de crear el repositorio para el subistema de Verificación dentro del grupo AgoraUS-G2-1617.Justo después de crear el repositorio correspondiente al sistema de Verificación, realizará un fork al repositorio que contiene al susbsitema de Verificación desarrollado por los compañeros del Grupo2 del año 15/16
- El jefe de proyecto añadirá a todo el equipo al repositorio una vez el fork haya sido realizado.
Metodología para subir los cambios
Gestión de conflictos
Introducción : si se diera el caso de un conflicto, el miembro del equipo que se haya topado con el mismo será el responsable de resolverlo. Para ello tendrá que comunicarlo al equipo para ponerse de acuerdo con el miembro o miembros para acordar la versión correcta del código.
Resolución de conflictos : cuando se produce un conflicto Git nos impide realizar el push correspondiente mostrándonos un aviso del mismo. Una vez se ha comunicado el conflicto al miembro o los miembros implicados se resuelve el conflicto manualmente y se vuelve a realizar el push.
