integracion-continua.md

Práctica 3: Integración continua y trabajo en equipo

1. Objetivos y resumen de la práctica

En esta práctica se pretende conseguir:

1. Formar equipos de trabajo y configurar GitHub para el trabajo conjunto.

2. Crear una máquina Docker con nuestra aplicación que sea capaz tanto de ejecutar todo tipo de tests (unitarios y de integración) como de poner en marcha la aplicación para las pruebas funcionales.

3. Conectar el repositorio GitHub con Travis, un servicio de integración continua que cada vez que se suba un cambio a una rama (o se active un pull request) realice las siguientes tareas:

   • Construir la máquina Docker con la aplicación
   • Lanzar tests unitarios
   • Lanzar tests de integración
   • Si todo funciona correctamente, publicar la nueva versión de la aplicación a DockerHub

4. Adaptar el flujo de trabajo en Git y GitHub al trabajo en equipo.

5. Desarrollar características adicionales en el proyecto siguiendo el nuevo flujo de trabajo.

2. Formación de equipos

Debéis formar equipos de 3 personas. Utilizad el enlace de GitHub Classroom que enviaré al foro de Moodle para crear un equipo nuevo o escoger un equipo ya existente. El equipo trabajará con un repositorio creado por GitHub Classroom con el nombre todolistgrupo-2017-NOMBRE-GRUPO. También se creará un equipo en el grupo mads-ua.

Una vez creado el repositorio debéis crear en él un tablero para gestionar las tarjetas con los issues y los pull requests. Creadlos con las mismas columnas que en las prácticas 1 y 2.

Escoged el proyecto que vais a usar en estas dos últimas prácticas de entre los proyectos de los miembros del equipo. Intentad que se un proyecto con código limpio y fácilmente ampliable.

Subidlo al nuevo repositorio, cambiando la URL del origin del repositorio local y haciendo un push:

$ git remote set-url origin https://github.com/mads-ua/todolistgrupo-2017-NOMBRE-EQUIPO.git
$ git push -u origin master

Por último, los otros miembros del equipo deberán clonar el repositorio para que los tres podáis trabajar con él en local.

3. Configuración máquina Docker

El objetivo de este apartado es crear una máquina Docker con vuestra aplicación que sea capaz tanto de ejecutar todo tipo de tests (unitarios y de integración) como de poner en marcha la aplicación para las pruebas funcionales.

Debéis hacer lo siguiente:

• Crear un nuevo issue denominado Configuración máquina Docker, con el objetivo de construir un fichero Dockerfile con el que se pueda crear la máquina Docker con nuestra aplicación. Uno de los miembros del equipo deberá ser el responsable de su implementación.

Consultar cómo definir el Dockerfile en los apuntes de la sesión de teoría sobre integración continua.

• Crear una rama para resolver el issue, como hacíamos en las primeras prácticas. Cuando el Dockerfile esté terminado, hacer un commit, un push de la rama y crear el pull request.

  Añadir como revisores a los otros dos miembros del equipo, que deberán probar en su repositorio local que el Dockerfile funciona correctamente.

  Para actualizar el repositorio local con las nuevas ramas que se suban al repositorio remoto:

  $ git fetch
  
  # Vemos las referencias a las ramas remotas con el nombre origin/RAMA-REMOTA
  $ git branch -vva
  
  # Creamos la rama local que hace tracking de la rama remota y nos
  # movemos a ella
  $ git checkout RAMA-REMOTA
  

  Debe probarse que la máquina docker es capaz de ejecutarse correctamente trabajando con las siguientes configuraciones:

  • Ejecución de tests trabajando con base de datos en memoria.
  • Ejecución de tests de integración, lanzando los tests con una base de datos MySQL.
  • Lanzamiento de una ejecución de la aplicación, trabajando con una configuración de stage.

• Una vez comprobado que la máquina Docker funciona, se aceptará el pull request y se integrará con master.

• Por último, debéis crear una cuenta en Docker Hub y subir a ella la máquina con el nombre DOCKER-ID/mads-todolist-2017 y el número de versión 0.2.

  Poner en la Wiki del proyecto un enlace a la URL de la máquina subida a Docker Hub, en una página llamada Integración continua.

3. Conectar el proyecto mads-todolist con Travis

Travis es un servicio de integración continua que se integra fácilmente con GitHub. Tiene una versión gratuita para proyectos abiertos (travis-ci.org) y una versión de pago para proyectos privados (travis-ci.com). La cuenta educativa de GitHub nos da permisos para trabajar en la versión de pago de forma gratuita.

Travis se conecta con GitHub y lanza un proceso de build síncrono que descarga, compila y prueba la rama del repositorio en la que se ha subido un nuevo commit.

Una vez hecha la integración con Travis se podrá comprobar en cada commit de GitHub si han pasado los tests correctamente:

A su vez, en Travis, podrás acceder y consultar los detalles de cada build:

Comienza abriendo un nuevo issue llamado Integración con Travis en el que desarrollarás esta integración.

3.1. Cómo darse de alta en Travis y conectar el repositorio

Para darte de alta en Travis debes acceder a travis-ci.com autentificándote con tu cuenta de GitHub.

Debes seguir las instrucciones que aparecerán para conectar el repositorio de la práctica 3 con Travis.

Comprueba en los ajustes que el repositorio se ha conectado correctamente con Travis:

3.2. Cómo configurar el build en Travis

El build en Travis se configura con el fichero .travis.yml que debe estar en la raíz del repositorio. En este fichero se incluye las instrucciones para compilar y ejecutar los tests del proyecto.

Crea un nuevo issue llamado Integración con Travis y una rama nueva en el repositorio local. Añade el siguiente fichero de configuración .travis.yml y sube la rama al repo remoto en GitHub.

Fichero .travis.yml:

sudo: required

language: bash

services:
  - docker

before_install:
   - docker build -t DOCKER-ID/mads-todolist-2017:0.2 .

script:
   - docker run --rm DOCKER-ID/mads-todolist-2017:0.2 /bin/bash -c "sbt test"

Podéis ver que el fichero de configuración de Travis construye la máquina Docker y después la ejecuta, lanzando los tests en memoria. Si pasan todos los tests Travis marcará como correcto el build.

Una vez hecho el push, Travis detectará automáticamente el cambio en la rama y realizará el build. Podremos ver en tiempo real la ejecución de los tests, en el frontal de Travis y en https://travis-ci.com/USUARIO/REPOSITORIO.

Cuando pasen correctamente los tests podréis ver el tick en el commit de GitHub.

3.3. Modificación del fichero .travis.yml y pull request

Modifica el fichero .travis.yml para incluir como último paso la ejecución también de los tests de integración ejecutándose contra una máquina docker MySQL.

Una vez comprobado que funciona correctamente, crea un pull request en GitHub para cerrar el issue.

Travis lanzará una ejecución del build del pull request, en el que mezclará la rama del PR con la rama master.

GitHub nos informará también si los tests pasan correctamente y si podemos hacer la integración del pull request sin problemas.

Realizad el pull request y actualizad los repositorio locales.

3.4. Modificación del README del proyecto

Por último, subid un commit a master con un cambio en el README.md para incluir en él una imagen que muestre el estado del último build realizado en Travis. Lo debe hacer un miembro distinto del que ha hecho el issue anterior. No hace falta crear un issue para esta modificación.

La imagen final del README.md deberá ser similar a la siguiente:

Puedes consultar cómo embeber esta imagen en la página de documentación de Travis Embedding Status Images. Cuidado con indicar correctamente en la URL la rama de la que se va a obtener el estado (debe ser master).

Comprueba que funciona correctamente subiendo un commit a master con un fallo en algún test. Y sube después otro commit arreglándolo.

4. Nuevo flujo de trabajo en Trello y GitHub

Como ya tenemos equipos de trabajo, debemos adaptar el flujo de trabajo tanto en GitHub a más de una persona.

Cambiaremos lo siguiente:

• Selección del issue: Al pasar un issue de "Seleccionado" a "En marcha" se debe asignar un responsable.
• Nueva rama con el issue: El responsable será el que abra una rama nueva para el desarrollo del ticket y la subirá a GitHub.
• Desarrollo: Se trabaja en la rama. Cualquier compañero puede unirse al ticket y trabajar junto con el responsable.
• Pull request: Cuando el ticket se ha terminado, el responsable abre un pull request en GitHub y pone la tarjeta en la columna En PR.
• Revisión de código: Los miembros del equipo revisan el código en el pull request (consultar documentación en GitHub: Reviewing proposed changes in a pull request). Al final, todos los miembros del equipo deben dar el OK, añadiendo una reacción.
• Integración del pull request: Cuando todos dan el OK, el responsable de la tarea integra el pull request en master.
• Actualización de los repositorios locales: Todos hacen un pull en master para actualizar los cambios del pull request. Y se borra la rama local ya integrada.

A continuación explicamos con más detalle algunos aspectos del flujo de trabajo.

4.1. Comandos Git para el trabajo en equipo

Veamos algunos comandos de Git relacionados con el trabajo compartido con repositorios remotos.

• Subir una rama al repositorio remoto:

  $ git checkout -b nueva-rama
  $ git push -u origin nueva-rama
  

• Descargar una rama del repositorio remoto:

  $ git fetch 
  $ git checkout -b nueva-rama origin/nueva-rama
  

  El comando git fetch se descarga todos los cambios pero no los mezcla con las ramas locales. Los deja en ramas cacheadas a las que les da el nombre del servidor y la rama (origin/nueva-rama).

  En el caso del comando anterior, una vez cacheada la rama origin/nueva-rama se crea la nueva-rama local con todos sus commits.

• Actualizar una rama con cambios que otros compañeros han subido al repositorio remoto:

  $ git checkout nueva-rama
  $ git pull
  

  El comando git pull es equivalente a un git fetch seguido de un git merge. Algunos recomiendan no usar git pull, sino hacer siempre el merge manual. Por ejemplo:

  $ git checkout nueva-rama
  $ git fetch
  $ git merge origin/nueva-rama
  

• Subir cambios de la rama actual:

  (estando en la rama que queremos subir)
  $ git push
  

  El comando git push funcionará correctamente sin más parámetros si previamente hemos subido la rama con un git push -u.

• Comprobar el estado de las ramas locales y remotas:

  $ git branch -vv
  

  Este comando no accede directamente al servidor, sino que muestra la información de la última vez que se accedió a él. Si queremos la información actualizada podemos hacer un git fetch --all antes:

  $ git fetch --all
  $ git branch -vv
  

  Es importante recordar que git fetch (a diferencia de git pull) no modifica los repositorios locales, sino que baja las ramas remotas cachés locales.

• Información de los repositorios remotos:

  $ git remote show origin
  

  Proporciona información del repositorio remoto, todas sus ramas, del local y de la conexión entre ambos.

  git remote -v update
  

  Proporciona información del estado de las ramas remotas y locales (si están actualizadas o hay cambios en algunas no bajadas o subidas).

• Borrado de ramas remotas desde el terminar:

  $ git push origin --delete nueva-rama
  $ git remote prune origin
  

4.2. Desarrollo de una página "Acerca de"

Probar todos los comandos anteriores en una rama en la que se implemente la página "Acerca de" en la que se muestre una con los miembros del equipo y el número de versión de la aplicación (0.3-SNAPSHOT).

Crear un issue en el que participen todos los miembros del equipo. Crear una rama en la que desarrollar los cambios. Cada miembro del equipo deberá realizar un commit en el que se añade su nombre a la lista.

Crear el pull request en GitHub, revisar el código y aceptarlo.

4.3. Configuración de la rama production y publicación de v1.0

El flujo de trabajo Git que vamos a seguir es muy similar al flujo de trabajo GitFlow (recordad la clase de teoría). Pero vamos a introducir alguna variante en la nomenclatura de las ramas.

En la versión original de GitFlow se publican las distintas versiones del proyecto en la rama long-lived master y se hace el desarrollo en la rama develop. Nosotros vamos a adoptar esta idea, pero cambiando el nombre de las ramas. La rama de desarrollo será la rama master en la que hemos trabajado desde el principio, y la rama con las versiones lanzadas la llamaremos production.

El equipo elegirá un responsable de integración que se encargue de crear la rama production y publicar en ella la primera versión v1.0 del proyecto.

Cread un issue con la tarea Lanzar release v1.0 que tendrá como responsable esta persona escogida.

Una vez que se ha integrado en master el pull request con la página "Acerca de" que contiene la lista de desarrolladores del proyecto y el número de versión "Versión 0.3-SNAPSHOT", el responsable de integración deberá publicar la nueva versión siguiendo los pasos de GitFlow:

• Crear la rama production y publicarla en GitHub.
• Crear la rama local release-v1.0 a partir de master.
• Realizar en esta rama los cambios específicos de la versión. En nuestro caso:
  • Cambiar en la página "Acerca de" "Versión 0.3-SNAPSHOT" por "Versión 1.0"
  • Añadir en la página la fecha de publicación de la versión.
  • Cambiar la versión en el build.sbt a 1.0.
• Publicar la rama release-v1.0 en GitHub y hacer un pull request sobre production.
• Mezclar también la rama de release con master.
• Por último, hacer un commit en master cambiando el número de versión a 1.1-SNAPSHOT (en el "Acerca de" y en el build.sbt).

Una vez hecho esto ya se puede borrar la rama release-v1.0 y las ramas production y master estarán actualizadas a las nuevas versiones.

La rama production también será integrada por Travis. Debemos comprobar que pasan todos los tests.

Opcional

• Modificar el fichero de configuración de Travis para que la versión de la máquina docker sea la definida por el número de build de Travis (en la variable de entorno TRAVIS_BUILD_NUMBER).
• Añadir en la configuración de Travis la publicación de la máquina docker en Docker Hub cada vez que se realice un build en la rama master (consultar en la página de información de Travis Using Docker in Builds).

5. Desarrollo de características adicionales en equipo

Pendiente.

6. Entrega y evaluación

• La práctica tiene una duración de 2 semanas y debe estar terminada el martes 21 de noviembre.
• La parte obligatoria puntúa sobre 7 y la opcional sobre 3 puntos.
• La calificación de la práctica tiene un peso de un 7% en la nota final de la asignatura.
• Para realizar la entrega uno de los miembros del equipo debe subir a Moodle un ZIP que contenga todo el proyecto, incluyendo la historia Git. Para ello comprime el directorio local del proyecto después de haber hecho un clean. Debes dejar también en Moodle la URL del repositorio en GitHub.

Para la evaluación se tendrá en cuenta:

• Desarrollo continuo (los commits deben realizarse a lo largo de las 2 semanas y no dejar todo para la última semana).
• Correcto desarrollo de la metodología.
• Corrección del código.