mjuez / tfm2016_analisis-visual-revisiones-codigo

Herramienta para la obtención y visualización de datos de revisiones de código.

🏆 1er Premio nacional SISTEDES ACCENTURE 2018 a Mejor Trabajo Fin de Máster

Descripción

Anvireco es una herramienta para la extracción y visualización de datos sobre revisiones de código realizadas en repositorios de código alojados en GitHub.

Autor

• Mario Juez - [email protected]

Tutores

• Carlos López Nozal - [email protected]
• Raúl Marticorena Sánchez - [email protected]

Wiki

En la wiki se pueden encontrar los manuales de usuario tanto de la API como del cliente.

Requisitos

Requisitos mínimos

• Node.js y npm: La aplicación está desarrollada en Node.js y hace uso del gestor de paquetes npm.
• MongoDB: La aplicación está preparada para trabajar con bases de datos NoSQL MongoDB. No es imprescindible tener una instancia local de MongoDB, como alternativa se pueden utilizar servicios en la nube como MongoDB Atlas o mLab.

Requisitos recomendados

• GitHub Developer application: Permite aumentar el límite de peticiones/hora a la API de GitHub de 60 a 5000.

Dependencias

Dependencias de la API (backend)

Nombre	Licencia	Imprescindible
express	MIT	Sí
body-parser	MIT	Sí
node-github	MIT	Sí
mongoose	MIT	Sí
TypeScript	Apache-2.0	Sí
ts-node	MIT	Sí
tslint	Apache-2.0	Sí
bluebird	MIT	Sí
gulp	MIT	Sí
gulp-sourcemaps	ISC	Sí
gulp-typescript	MIT	Sí
request	Apache-2.0	Sí
request-promise	ISC	Sí
twix	MIT	Sí
moment	MIT	Sí
json2csv	MIT	Sí
cheerio	MIT	Sí
gulp-typedoc	ISC	No
chai	MIT	No
chai-as-promised	WTFPL	No
chai-http	MIT	No
sinon	BSD	No
mocha	MIT	No
typedoc	Apache-2.0	No

Dependencias del cliente (frontend)

Nombre	Licencia	Imprescindible
jQuery	MIT	Sí
sammy	MIT	Sí
semantic-ui	MIT	Sí
d3	BSD-3-Clause	Sí
c3	MIT	Sí

Instalación

A continuación se muestran los pasos necesarios para la instalación y despliegue de la aplicación (manual de programador) en una máquina local. Las tecnologías utilizadas también son compatibles con sistemas operativos Windows, Linux y Mac OS X.

Descarga de la aplicación

En primer lugar se debe descargar la aplicación. Bien el fichero .zip generado por GitHub, o clonando el repositorio:

git clone https://github.com/mjuez/TFM2016_Analisis-Visual-Revisiones-Codigo.git

Una vez descargada y descomprimida, es necesario situarse dentro de la carpeta que contiene el fichero package.json.

Variables de entorno

Las variables de configuración de la aplicación se deben definir como variables de entorno y son las siguientes:

• MONGO_CONNSTRING: Cadena de conexión a la base de datos MongoDB (formato).
  • Ejemplo: mongodb://admin:[email protected]:27017/anvireco.
• ANVIRECO_APPNAME (opcional): Nombre de una aplicación GitHub Developer application.
  • Ejemplo: Anvireco.
• ANVIRECO_ID (opcional): Client ID de una aplicación GitHub Developer application.
  • Ejemplo: 00x000x00xxx0x0x0xx0.
• ANVIRECO_SECRET (opcional): Client Secret de una aplicación GitHub Developer application.
  • Ejemplo: 00x000x00xxx0x0x0xx000x000x00xxx0x0x0xx0.
• PORT (opcional): Puerto donde se va a ejecutar el servidor node.js.
  • Ejemplo: 3000.

Nota: La definición de variables de entorno depende del sistema operativo utilizado y no se detalla en este manual.

Instalación de dependencias

Existen dos formas de instalar las dependencias de la aplicación utilizando el gestor de paquetes npm:

• Entorno de producción: Instala únicamente las dependencias imprescindibles para la ejecución de la aplicación.

  npm install --only=production
  

• Entorno de desarrollo: Instala todas las dependencias, incluyendo aquellas opcionales como por ejemplo las de testing.

  npm install
  

Compilación de ficheros TypeScript

Los ficheros TypeScript (.ts) dentro del directorio src son compilados a JavaScript (.js) y guardados en el directorio release. La compilación se realiza mediante un objetivo de gulp llamado compile.

gulp compile

Ejecución de pruebas unitarias

La ejecución de las pruebas unitarias solo se puede llevar a cabo si se han instalado todas las dependencias. Mediante el comando npm test se ejecutan las pruebas.

Nota: Para la ejecución de las pruebas no es necesario compilar los ficheros TypeScript.

Ejecución de la aplicación

La aplicación se ejecuta mediante el comando npm start. La aplicación es accesible desde http://localhost:puerto donde puerto es el valor de la variable de entorno PORT.

Nota 1: Si no se ha definido la variable de entorno PORT, la aplicación se desplegará por defecto en el puerto 3000 y será accesible a través de http://localhost:3000/.

Nota 2: Para la ejecución de la aplicación es imprescindible la compilación previa de los ficheros TypeScript.

Demo

• Producción: http://anvireco.herokuapp.com/
• Desarrollo: http://anvireco-dev.herokuapp.com/
• Machine learning reviewers data processing: https://anvireco-reviews-preprocessor.duckduck.mjuez.com/

Licencia

Copyright (c) 2017 Mario Juez Gil - Licenciado bajo licencia MIT

Un proyecto para:

tfm2016_analisis-visual-revisiones-codigo's Issues

Conceptos teoricos Buenas prácticas ágiles

Añade una subsección en conceptos teóricos que incluya las buenas prácticas ágiles que vas a seguir en el TFM. Utiliza esta página (https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ ) para seleccionarlas y obtener una pequeña descripción.

En la sección de herramientas describe su funcionalidad e indica la buena práctica ágil con la que está asocidada.

TaskBoard, Burndown chart -> Trello o ZenHub
Continuous integration -> Travis

Conceptos teóricos

Issue creada por error probando el funcionamiento de la funcionalidad Projects de github.

Actualización de README.md

Se busca incluir un pequeño manual del programador en el README del repositorio, así como las "badges" de travis y codebeat para mostrar el estado de la construcción de las ramas dev/master y el GPA del código respectivamente.

Conversión de mongoose.Document a Entidad en repositorios

Los métodos de los modelos (repositorios) de mongoose retornan premisas que cuando son resueltas retornan Documentos en lugar de Entidades.
Actualmente (aunque por alguna razón funciona) nuestros repositorios no hacen la conversión de Documentos a Entidades.

Estudio de servidor de despliegue de aplicaciones web

Duplicado #6

Lectura de la documentación de OpenShift con el fin de entender el funcionamiento de la plataforma y como poder desplegar una instancia de SonarQube.

Como fuente principal sugiero la información disponible en los siguientes enlaces:
-[Guía del desarrollador de OpenShift] https://developers.openshift.com/en/overview-what-is-openshift.html
-[Guía del usuario de OpenShift Origin] https://docs.openshift.org/origin-m4/oo_user_guide.html

Actualización de Técnicas y Herramientas

Actualmente se están utilizando herramientas como mongoose que se deben incluir en la memoria.

Obtención de Comentarios de Revisión, Usuarios, Repositorio

Actualmente se pueden obtener Pull Request, y Revisiones, quedan 3 tipos de tareas por implementar:

• Comentarios de Revisión (Review Comment)
• Usuarios
• Repositorio

Estudio de servidor de despliegue de aplicaciones Web

Lectura de la documentación de OpenShift con el fin de entender el funcionamiento de la plataforma y como poder desplegar una instancia de SonarQube.

Como fuente principal sugiero la información disponible en los siguientes enlaces:
-[Guía del desarrollador de OpenShift] https://developers.openshift.com/en/overview-what-is-openshift.html
-[Guía del usuario de OpenShift Origin] https://docs.openshift.org/origin-m4/oo_user_guide.html

Cierre de la aplicación con repositorios grandes

Haciendo pruebas con el repositorio elasticsearch, hasta ahora no había problemas para obtener las pull request, sin embargo al implementar la funcionalidad de obtener las revisiones asociadas a las pull request, llega un momento en el cual la aplicación se cierra con el siguiente error:

<--- Last few GCs --->

[11766:0x3fc7a20]   343097 ms: Mark-sweep 1430.4 (1514.0) -> 1430.4 (1514.0) MB, 2645.3 / 0.0 ms  (+ 1.4 ms in 1 steps since start of marking, biggest step 1.4 ms) allocation failure GC in old space requested
[11766:0x3fc7a20]   345249 ms: Mark-sweep 1430.4 (1514.0) -> 1430.4 (1483.0) MB, 2152.1 / 0.0 ms  last resort gc 
[11766:0x3fc7a20]   347259 ms: Mark-sweep 1430.4 (1483.0) -> 1430.4 (1483.0) MB, 2009.8 / 0.0 ms  last resort gc 


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x301787bc0d39 <JS Object>
    1: $__buildDoc [/home/mario/Gdrive/TFM/git/node_modules/mongoose/lib/document.js:~159] [pc=0x8350aea3f34](this=0x2e04fdb28539 <a model with map 0x665d3aa6971>,obj=0x301787b04311 <undefined>,fields=0x2e683b05c7c9 <an Object with map 0x3602c8607011>,skipId=0x301787b043b1 <true>)
    2: constructor(aka Document) [/home/mario/Gdrive/TFM/git/node_modules/mongoose/lib/document.js:~39] [pc=0x8350a...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x126426c [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewTransitionArray(int) [node]
 6: v8::internal::TransitionArray::Insert(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Map>, v8::internal::SimpleTransitionFlag) [node]
 7: v8::internal::Map::CopyReplaceDescriptors(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::DescriptorArray>, v8::internal::Handle<v8::internal::LayoutDescriptor>, v8::internal::TransitionFlag, v8::internal::MaybeHandle<v8::internal::Name>, char const*, v8::internal::SimpleTransitionFlag) [node]
 8: v8::internal::Map::CopyAddDescriptor(v8::internal::Handle<v8::internal::Map>, v8::internal::Descriptor*, v8::internal::TransitionFlag) [node]
 9: v8::internal::Map::CopyWithField(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::FieldType>, v8::internal::PropertyAttributes, v8::internal::Representation, v8::internal::TransitionFlag) [node]
10: v8::internal::Map::TransitionToDataProperty(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::StoreFromKeyed) [node]
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::StoreFromKeyed) [node]
12: v8::internal::StoreIC::LookupForWrite(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
13: v8::internal::StoreIC::UpdateCaches(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
14: v8::internal::StoreIC::Store(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
15: v8::internal::KeyedStoreIC::Store(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [node]
16: v8::internal::Runtime_KeyedStoreIC_Miss(int, v8::internal::Object**, v8::internal::Isolate*) [node]
17: 0x8350a6063a7
Aborted (core dumped)

Aparentemente es un problema con mongoose y el uso de memoria.

Listado de repositorios

Crear una vista que permita visualizar el listado de los repositorios almacenados localmente para en un futuro poder navegar hacia ellos.

Hará falta crear los endpoint necesarios en la API.

Layout del cliente

Actualmente el cliente cuenta con un layout muy simple.

Se busca incluir un pie de página con información acerca del TFM, y también puede ser interesante un indicador con el estado del gestor de tareas que se actualice periódicamente (en ejecución, esperando de nuevas tareas, detenido -esperando peticiones-).

A lo mejor también se puede cambiar el menú superior por uno lateral en vistas a que en el futuro podríamos incluir la funcionalidad de hacer gráficas comparativas y una posibilidad puede ser elegir las opciones desde el propio menú.

Contador de Pull Request por repositorios y usuarios

Estudiar la posible mejora del prototipo permitiendo la obtención de contadores de pull requests totales de un repositorio y de un usuario.

Se deberá estudiar primero la API de Github para comprobar si existe un modo simple de obtener estos contadores, o por el contrario es una funcionalidad que requiere de un elevado número de peticiones a la API.

Técnicas y herramientas

Se debe comenzar el desarrollo de la parte de técnicas y herramientas de la memoria, incluyendo las que se utilizan hasta la fecha.

Gestión de cola de peticiones a la API de Github

Mejorar el prototipo implementando un sistema de colas para tratar el límite de 5000 peticiones a la API de Github. Cuando se terminan las peticiones, se debe recordar el progreso de la tarea actual y continuarlo en el momento de renovación del límite de peticiones.

Identificar y definir gráficas que ayuden a interpretar las revisones de código

Análizar el concepto de revisión de código extrayendo el diagrama conceptual para definir gráficas que ayuden a analizar el proceso de revisión de código en un proyecto.

• Red de participantes en las revisiones (ver ejemplos en http://som-research.uoc.edu/tools/gila/)
• Análisis de revisiones de un usuario concreto
• Review time line (ver ejemplos en http://som-research.uoc.edu/tools/gila/)
• Text review analysis (tag cloud)
  -...

Usar ejemplos de de componentes gráficos de la biblioteca que se vaya a utilizar para implementación. Lo dejo a elección de Mario.

• D3.js (https://github.com/d3/d3/wiki/Gallery)
• Vaddin (http://demo.vaadin.com/sampler/#ui)

Prototipo para probar persistencia con MongoDB

Este prototipo tiene como fin obtener por ejemplo una Pull Request de un repositorio GitHub y almacenarla localmente en una base de datos MongoDB.

Al parecer Heroku permite la instalación de MongoDB a través de un addon llamado mLab MongoDB, pero la versión gratuita está limitada a 496mb, por ello se trabajará con dos bases de datos, una local y la de heroku, se debería buscar la forma de que al realizar el despliegue (usando travis), se modifique la cadena de conexión para utilizar la base de datos de heroku en lugar de la local, en otras palabras, entorno de desarrollo (local) y entorno de producción (remoto)

Estudio de características de Pull Request

Las revisiones de código en Github se realizan a través del uso de Pull Requests, se trata por tanto de uno de los conjuntos de datos más importantes para este trabajo y se debe conocer su estructura y contenido.

A continuación pego el contenido de un comentario de @clopezno en la tarea #16 que puede ser de utilidad:

En el siguiente artículo se seleccionan las características de un pullrequest. Los criterios de clasificación de alto nivel que se especifican en la Tabla 1 del artículo son:

• Características del pull request - 16 medidas
• Características del proyecto - 8 medidas
• Características del desarrollador - 3 medidas

El análisis de datos esta hecho con R y obtenidos con GHTorrent

Entidad Revisión

Añadir la entidad Revisión (Review), y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.
Posiblemente también sea necesaria la creación de la entidad Comentario de revisión (Review Comment)

Diferencias entre "Comment", "Review", "ReviewComment"

Las Pull Request de GitHub cuentan con varios elementos cuya diferencia no está muy clara y es importante conocerla:

• Comment
• ReviewComment
• Review

En #28 se han utilizado los tres elementos y se busca ver cómo se obtienen usando la API y qué contenido específico tienen.

Aprendizaje Gerrit Code Review

Comprensión del como se realizan revisiones de código mediante Gerrit Code Review

• Integración con repositorios GitHub
• Integración con gestores de Tareas de GitHub
• Conocer los datos estructurados de las revisiones de código
• Conocer el API de comunicación con Gerrit Code Review
• Búsqueda de repositorios con revisiones de código

Usar la siguiente documentación
Gerrit Code Review - A Quick Introduction. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://review.gerrithub.io/Documentation/intro-quick.html

La aplicación de estos conceptos en el TFM pueden transformarse en un futuro en una tarae

Entidad Usuario

Añadir la entidad Usuario, y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.

Estudio de herramientas de integración continua

Nos gustaría hacer uso de una herramienta de integración continua que nos permita ejecutar los test y desplegar la aplicación en Openshift de forma automática.

Actualmente vamos a probar el funcionamiento de Travis CI.

Se puede realizar un prototipo de "hola mundo" en NodeJS para probar el funcionamiento e integración de Travis con los tests y con Openshift.

Tratamiento de la paginación de resultados

Actualmente existe un método recursivo en PullRequestService getAllPaginatedPullRequests que va realizando peticiones de páginas y almacenándolas en un array de entidades.
Hasta que dicho array no contiene todas las páginas, las entidades no son persistidas en la base de datos local. Se quiere cambiar el comportamiento para que se vayan almacenando las páginas a medida que se obtienen.

Los resultados de obtener todas las entidades (por ejemplo Pull Request) de la base de datos local, también se deberían devolver paginados, siguiendo la estrategia que utiliza la API de GitHub (páginas con un máximo de 100 resultados)

Gestor de tareas

Crear un gestor de tareas para tratar la realización de peticiones a la API de GitHub teniendo en cuenta el límite de peticiones.
Una tarea por tanto debe almacenar los parámetros para realizar las peticiones a la API de GitHub, así como el estado de la tarea, por ejemplo la última página obtenida de la API para así poder continuar con ella cuando se renueven las peticiones disponibles.
El gestor de tareas tendrá que decidir qué tarea se debe ejecutar en cada momento.

Ésta issue conecta con la número #27 que no se realizó en el quinto sprint.

Uso de librería nodejs-github

Se busca adaptar el prototipo para utilizar la librería nodejs-github que ofrece interfaces de acceso a la API de GitHub.

Enrutamiento en el cliente

Se tomó la decisión de realizar un cliente tipo SPA (single page application), lo que significa que las acciones que se realizan desde el cliente no deben provocar refrescos de la página.

Debido a la elevada cantidad de tecnologías que se utilizan en este proyecto, se decidió utilizar únicamente jQuery en el cliente, evitando frameworks como AngularJS cuyo aprendizaje nos supondría mucho tiempo.

El problema de utilizar únicamente jQuery es que labores como la de enrutamiento resultan muy tediosas cuando la cantidad de combinaciones de rutas crece. Éste problema está apareciendo en nuestro cliente actualmente al intentar implementar los filtros.

He encontrado un pequeño framework que funciona como plugin de jQuery llamado sammy.js, que simplifica la gestión del enrutamiento y considero necesario utilizarlo para conseguir un cliente mantenible.

Entidad Repositorio

Añadir la entidad Repositorio, y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.

Pruebas unitarias

Se deben desarrollar pruebas unitarias para el prototipo actual.

Listado de pull requests

Implementar el listado de pull requests de forma similar al listado de repositorios.
Puede ser interesante ofrecer métodos de ordenación (ascendente, descendente):

• Por nombre.
• Por fecha.
• Por número de revisiones.

Documentación de código TypeScript

Estudiar y elegir la forma de documentar el código TypeScript que se va a desarrollar.

Persistencia de datos de revisiones

Tenemos que buscar una solución para gestionar la persistencia de los datos obtenidos de la API de Github para tratar de minimizar el número de peticiones necesarias a dicha API.

Dependiendo del tipo de sistema gestor de persistencia que escojamos (SQL, NoSQL, ficheros) existen diversas herramientas (ORM, ODM) para NodeJS que podrían facilitarnos el manejo de los datos.

NoSQL ODM (mongodb)

• Mongoose
• Mongorito

SQL ORM (PostgreSQL, MySQL, MariaDB...)

• Sequelize

Como opción adicional existe ToroDB, un tipo de base de datos que es una mezcla entre NoSQL y SQL. Las consultas se hacen con la sintaxis de mongodb y los datos son almacenados en una base de datos PostgreSQL.

Prototipo para probar API de Github.

Se debe añadir al prototipo NodeJS una ruta que permita trabajar con la API de Github.
Como resultado se espera que dado un proyecto de Github, se calcule y muestre el número de revisiones que tiene.

Comprobación de existencia de repositorio

Se desea hacer sin consumir peticiones de la API de github para poder asegurarnos de responder al cliente instantáneamente si el repositorio existe o no.

Investigando el código fuente de la página 404 que arroja github frente a la de un repositorio existente, en el segundo caso incluye varias etiquetas meta características que no están presentes en la página de error, por ejemplo fb:app_id, o description. Al parecer la primera sirve para la interacción con facebook, la descripción sin embargo es característica de todo repositorio y aunque ambas deberían estar presentes siempre, la descripción tiene menos posibilidades de desaparecer que la aplicación facebook relacionada.

Si el repositorio no existe, nuestra API debería retornar 404 (paso previo a crear la tarea)

Interfaz de la pantalla principal

Realizar una pantalla principal básica de la aplicación, por ejemplo con dos campos de texto (usuario, repositorio) que permitan crear una tarea para obtener un repositorio remoto.
También podría tener un desplegable con la lista de repositorios almacenados localmente que permita navegar hacia la parte de la interfaz donde se mostrarán gráficas para dicho repositorio.

Se podría utilizar un framework como boostrap o semantic-ui para el tema de interfaz, y jQuery para realizar llamadas a nuestra API.

Obtención de datos local / remota

Actualmente todas las peticiones GET a nuestra API hacen llamadas a la API de GitHub.
Queremos separar las peticiones GET en dos tipos:

• Peticiones que obtienen datos de nuestra bbdd local (sin utilizar peticiones de la API de GitHub)
• Peticiones que desencadenan peticiones a la API de GitHub para insertar/actualizar datos en nuestra bbdd local.

La idea de esta separación tiene entre otros objetivos, el evitar que nuestra API emplee una cantidad de tiempo elevada en responder, las peticiones del segundo tipo deberían responder con el estado de la creación de una tarea que conlleva la petición de datos a la API de GitHub y que podría no ejecutarse en el momento (actualmente responde con los datos que se obtienen de GitHub).

Mensaje informativo de tarea creada

En la página principal, mostrar un mensaje tras pulsar el botón indicando si ha ido bien la creación de la tarea o no.

Aprendizaje del uso de la plantilla de Latex para la documentación

En el repositorio he cargado en la carpeta memoLatex la plantilla que se utiliza en el TFG de GII. Se necesita ajustar sustituyendo todas las referencias de "TFG o Trabajo Fin de Grado" por "TFM o Trabajo Fin de Máster"

La herramienta que aconsejo utilizar para compilar LateX es TexMaker

Prototipo Node.JS + Express + Typescript

Se busca realizar un prototipo básico de API REST en Node.JS.
Como framework web se utilizará Express (http://expressjs.com/es/). Se ha elegido este framework por los siguientes motivos:

• Proyecto con elevada actividad en Github en la actualidad.
  • Más de 5.000 commits.
  • 262 releases (la última de hace 24 días).
• Más de 30.000 estrellas.
• Revisiones de código mediante Pull Request, aunque hace poco uso de la figura de revisor.
• Buena documentación.

También se va a utilizar Typescript (https://www.typescriptlang.org/), un superset de Javascript tipado. Los motivos de utilizar Typescript son los siguientes:

• Desarrollado por Microsoft.
• Proyecto con elevada actividad en Github en la actualidad.
  • Más de 15.000 commits.
• Más de 19.000 estrellas.
• Revisiones de código mediante Pull Request.
• Transforma Javascript en un lenguaje tipado.

Inicialmente se va a utilizar Gulp (http://gulpjs.com/) como herramienta para automatizar tareas, aunque se deberá comparar con alternativas como Grunt.
En lo referente a los tests, inicialmente se utilizará Mocha (https://mochajs.org/) + chai (http://chaijs.com/), pero al igual que en el caso anterior, se deben estudiar en profundidad y valorar alternativas.

En el siguiente artículo se desarrolla un ejemplo bastante completo de uso de las anteriores tecnologías:
http://mherman.org/blog/2016/11/05/developing-a-restful-api-with-node-and-typescript/#.WKzA1iHhBpi

Aumento peticiones API github

La API de github permite un máximo de 60 peticiones a la hora, cantidad que se puede aumentar utilizando autenticación.

Se debe buscar el modo de utilizar la autenticación para poder realizar un máximo de 5000 peticiones/hora. En este enlace de la guía de la API de github se detalla como obtener tokens oauth para aplicaciones específicas

Definición de métricas a utilizar en las gráficas

Con los conocimientos que tenemos de la API y basándonos en este artículo y la herramienta ReDA, se busca establecer una definición inicial de las métricas a utilizar para el análisis visual de las revisiones de código.

Correcciones y mejora de conceptos teóricos

Se debe incluir el diagrama de #5 en la sección de conceptos teóricos como justificación y base de nuevos conceptos a definir. También se debe revisar la sección y corregir erratas.

toEntity y toEntityArray a Entity

Los métodos toEntity y toEntityArray del servicio PullRequestService deberían formar parte de las entidades en lugar de los servicios.

Prueba de integración Codebeat

Probar el correcto funcionamiento de la ejecución de las revisiones automáticas (codebeat) en un pull request.

Gráfica número de pull request a lo largo del tiempo

Probar el framework d3js para hacer una gráfica que muestre el número de pull requests de un repositorio en base al tiempo.

Prototipo para probar persistencia con MongoDB

Este prototipo tiene como fin obtener por ejemplo una Pull Request de un repositorio GitHub y almacenarla localmente en una base de datos MongoDB.

Al parecer Heroku permite la instalación de MongoDB a través de un addon llamado mLab MongoDB, pero la versión gratuita está limitada a 496mb, por ello se trabajará con dos bases de datos, una local y la de heroku, se debería buscar la forma de que al realizar el despliegue (usando travis), se modifique la cadena de conexión para utilizar la base de datos de heroku en lugar de la local, en otras palabras, entorno de desarrollo (local) y entorno de producción (remoto)

Menu de la aplicación

Hacer un menú de navegación para las principales secciones de la aplicación:

• Inicio
• Repositorios
• Pull Requests
• Usuarios

La idea es que en el futuro cada una de esas secciones contenga estadísticas generales, y un listado de cada una de las entidades para navegar hacia estadísticas concretas.

Conceptos teóricos sobre revisiones de código

Duplicado #3
Adjunto la siguiente bibliografía para definir los conceptos teóricos sobre revisiones de código en la memoria

• Understanding the GitHub Flow · GitHub Guides. (s. f.). https://guides.github.com/introduction/flow/
• Ways to Make Code Reviews More Effective. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://www.infoq.com/articles/effective-code-reviews?utm_source=infoqWeeklyNewsletter&utm_medium=WeeklyNL_EditorialContent_culture-methods&utm_campaign=10042016news
• A whole new Universe. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://github.com/universe-2016
• Bernhart, M., & Grechenig, T. (2013). On the understanding of programs with continuous code reviews. En 2013 21st International Conference on Program Comprehension (ICPC) (pp. 192-198). https://doi.org/10.1109/ICPC.2013.6613847
  -Bosu, A., Greiler, M., & Bird, C. (2015). Characteristics of Useful Code Reviews: An Empirical Study at Microsoft. En 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories (pp. 146-156). https://doi.org/10.1109/MSR.2015.21
  -Mining Review Repositories. (s. f.). Recuperado 4 de octubre de 2016, a partir de http://sdlab.naist.jp/reviewmining/

Elección y prueba de herramienta de revisión automática

Se quiere añadir una nueva fase de revisiones automáticas de código (cobertura, complejidad, defectos de código, etc) al proceso de integración continua (hasta ahora construcción, pruebas y despliegue).

Se proponen dos herramientas de las que se debe escoger una:

• CodeClimate
• SonarQube

Conceptos teóricos sobre revisiones de código

Adjunto la siguiente bibliografía para definir los conceptos teóricos sobre revisiones de código en la memoria

• Understanding the GitHub Flow · GitHub Guides. (s. f.). https://guides.github.com/introduction/flow/
• Ways to Make Code Reviews More Effective. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://www.infoq.com/articles/effective-code-reviews?utm_source=infoqWeeklyNewsletter&utm_medium=WeeklyNL_EditorialContent_culture-methods&utm_campaign=10042016news
• A whole new Universe. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://github.com/universe-2016
• Bernhart, M., & Grechenig, T. (2013). On the understanding of programs with continuous code reviews. En 2013 21st International Conference on Program Comprehension (ICPC) (pp. 192-198). https://doi.org/10.1109/ICPC.2013.6613847
  -Bosu, A., Greiler, M., & Bird, C. (2015). Characteristics of Useful Code Reviews: An Empirical Study at Microsoft. En 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories (pp. 146-156). https://doi.org/10.1109/MSR.2015.21
  -Mining Review Repositories. (s. f.). Recuperado 4 de octubre de 2016, a partir de http://sdlab.naist.jp/reviewmining/

Configuración de Travis para ramas master y dev

Hasta ahora, la configuración de travis sirve para la prueba y despliegue del segundo prototipo.
A partir de este momento, se va a desarrollar un prototipo principal cuya funcionalidad se irá incrementando en cada Sprint.
Hay que adaptar la configuración de travis para llevar a cabo el proceso de integración continua en dos ramas:

• dev: Rama de desarrollo.
• master: Rama principal que debería ser actualizada al final de cada sprint con los cambios definitivos.

Existirán por tanto dos aplicaciones en Heroku que sirven para simular dos entornos, el de producción (rama master) y el de desarrollo (rama dev). Las aplicaciones son las siguientes:

• anvireco-dev: Entorno de desarrollo.
• anvireco: Entorno de producción.