[IV 21-22] Objetivo 6

.circleci/config.yml

@@ -0,0 +1,16 @@
+jobs:
+
+  test-app:
+    machine:
+      image: ubuntu-2004:202010-01
+    steps:
+      - checkout
+      - run:
+          name: "Task para app test"
+          command: "rake docker"
+
+workflows:
+  version: 2
+  test-app-workflow:
+    jobs:
+      - test-app 

.github/workflows/dockerhub.yml

@@ -5,10 +5,6 @@ on:
     paths:
       - Dockerfile
       - Gemfile
-  pull_request:
-    paths:
-      - Gemfile
-      - Dockerfile
 
 jobs:
   build:

.github/workflows/gha.yml

@@ -0,0 +1,24 @@
+name: Test
+on: push
+
+jobs:
+  tests-github:
+    strategy:
+      matrix:
+        rubyv: ['3.0.0', '3.0.1']
+    name: Tests Ruby
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout 
+      uses: actions/checkout@v2
+
+    - name: Set up Ruby
+      uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
+      with:
+        ruby-version: ${{ matrix.rubyv }}
+
+    - name: Install dependencies
+      run: bundle install
+
+    - name: Run tests
+      run: rake test

.rspec

@@ -1 +1 @@
---require spec_helper
+

README.md

@@ -113,4 +113,8 @@ Tras crear nuestra cuenta en Dockerhub y crear nuestro repositorio de nombre igu
 
 Dicho token se ha añadido como secreto de nuestro repositorio como token de acceso, que en consonancia al token de nuestro usuario de dockerhub, serán los dos secretos enlazados a nuestro repositorio de GitHub.
 
-Podemos encontrar [aquí](docs/docker.md) una visión más amplia de algunos conceptos en relación a los contenedores.
+Podemos encontrar [aquí](docs/docker.md) una visión más amplia de algunos conceptos en relación a los contenedores.
+
+## Sistemas de Integración Continua
+
+La información referente a las herramientas usadas las podemos encontrar a partir de [aquí](docs/CI.md), a partir de la cual podremos encontrar el resto de documentación relacionada.

Rakefile

@@ -14,4 +14,10 @@ desc "Task para revisar la sintaxis de los archivos del proyecto,"
 task :check do
     puts "Realizando comprobaciones de sintaxis..."
     exec "ruby -c ./lib/*"
+end
+
+desc "Task para lanzar la imagen del docker,"
+task :docker do
+    puts "Lanzando la imagen..."
+    exec "docker run -t -v `pwd`:/app/test paszser/comparerapp"
 end

docs/CI.md

@@ -0,0 +1,55 @@
+# Sistemas de Integración Continua
+
+Trataremos de automatizar la integración de los cambios en el código y su testeo en el proyecto de una forma más ordenada y fiable. Así verificaremos que el código sea correcto antes de su integración, y para ello debemos seleccionar herramientas que nos ayuden a lograr esta causa.
+
+## Planteamiento
+
+Se tratará de elegir dos herramientas e implementarla en el proyecto testeando así la imagen de docker y distintas versiones del lenguaje con ellos, pasando por una serie de requisitos que plantearemos a continuación y con los que nos sentiremos satisfechos si cumple.
+
+## Requisitos
+
+1. Que nos permita el testeo de más de una versión del lenguaje que empleamos en el proyecto mediante el uso, por ejemplo, de *matrix*.Así se dota de cierta flexibilidad a los tests que haremos con dichas versiones elegidas.
+
+2. Uso libre y gratis de las herramientas, pues no buscamos gastar capital en la obtención de una teniendo algunas de uso gratuito..
+
+3. Que nos permita probar los cambios también en el contenedor creado para el proyecto.
+
+4. Instalación y configuración clara, concisa y fácil, con una documentación que sea al menos entendible y directa.
+
+5. Fácil integración y uso en consonancia a GitHub para que sea más sencillo harmonizar el proyecto y la herramienta en cuestión.
+
+6. Facilidad a la hora de implementar la funcionalidad de *Checks API* para que aparezca correctamente en Github y se compruebe desde los tests.
+
+## Opciones
+
+A continuación se va a presentar una lista de las opciones que se han barajado de cara a las dos herramientas a usar:
+
+* Jenkins: Servidor de automatización open source. Colabora en la automatización de parte del desarrollo software mediante la integración continua y la facilita. No es solo un motor con resultados binarios tales como "Success/Failed" si no que deja un feedback que mediante la webapp de la herramienta se puede visualizar. A su vez, Jenkins es una arquitectura de plugins, lo que la hace fácilemnte extensible y se adapta bien a otras herramientas y lenguajes. Ofrece API REST y cuenta con *matrix jobs*.
+
+* Bamboo: Canalización de entrega continua que ofrece resistencia, fiabilidad y escalabilidad a equipos de todos los tamaños hasta la implementación. Escala con confianza manteniendo el rendimiento. Gran resistencia de compilación y alta disponibilidad. Migraciones integradas desde otras herramientas y flujos de trabajo de ramificación de Git integrados. Se configura fácilmente y ofrece API REST.
+
+* CircleCI: Herramienta de integración continua para automatizar los procesos de creación, prueba e implementación. Ofrece API REST, un flujo de trabajo de aprobación y la creación de informes y análisis que resulta útil en los test de código. Es compatible con muchos lenguajes y funciona atado a un repositorio git. Su webapp ofrece una interfaz fácilmente entendible donde se pueden controlar diversos aspectos controlables. El uso básico es gratuito y nos ofrece funcionalidades más que suficientes aunque se puede mejorar con un pago. Ofrece a su vez la funcionalidad de *Checks API* de forma bastante simple y afable de instalar mediante la propia documentación de la herramienta.
+
+* Github Actions: Es una herramienta que permite reducir la cadena de acciones necesaria para la ejecución de código, mediante la creación de un de flujo de trabajo. Es configurable para que GitHub reaccione a ciertos eventos de forma automática según nuestras preferencias. Permite compartir datos entre los trabajos mencionados en el mismo workflow. Es compatible con una gran cantidad de lenguajes y versiones de los mismos, así como una configuración mediante un archivo .yml que le da bastante versatilidad respecto a nuestros deseos.
+
+* GitLab: Implementa una herramienta de integración continua de uso sencillo, rápido yu open source. Con CI/CD de GitLab en el mismo lugar, podemos crear tickets, unir solicitudes, escribir código y establecer la integración y entrega continua sin depender de otra aplicación. Cuenta también con *matrix jobs*.
+
+* Travis: A pesar de no ser de pago, la inclusión de la tarjeta de crédito es obligatoria. Es un sistema de Integración Continua, gratuita para proyectos Open Source y de pago para proyectos privados. Se integra sin problemas con GitHub, incluso con la funcionalidad de *checks API* y automáticamente ejecuta el pipeline definido en cada push o pull requests. Incluye API, autorización basada en roles y creación de informes/análisis.
+
+## Elección
+
+Para este proyecto, se elegirán como las dos herramientas de integración, tanto CircleCI como Github Actions.
+
+### Justificación de la Elección
+
+Las principales razones para justificar la elección son que ambas herramientas cumplen con creces los requisitos impuestos con anterioridad. Ambas son compatibles con el testeo de varias versiones de nuestro lenguaje, el cual en este proyecto realizamos con Github Actions. Ambas son de uso libre y gratis, siendo así el nivel más básico de CircleCI, más que suficiente para este proyecto. Por ejemplo en Github Actions podemos hacer uso de *matrix* como nuestra matriz de compilaciones recogiendo así las versiones del lenguaje que queremos usar para hacer el test del proyecto.
+
+También, podemos hacer pruebas enlazando el docker creado con anterioridad para el proyecto, armando el archivo .yml para ello. En este caso lo hemos realizado con CircleCI dotando a las herramientas así de funciones específicas para abarcar todo lo que se pide en el objetivo.
+
+La instalación de ambas herramientas se puede hacer de forma muy sencilla siguiendo la documentación que aportan en sus respectivas páginas. Estos pasos y su set up se explican en detalle en los archivos de documentación de cada herramienta. La integración con Github en ambas herramientas es casi automática, siguiendo un par de sencillos pasos en Circle CI (documentado en su archivo respectivo) y casi instantáneo al montar el esqueleto necesario para Github Actions.
+
+A su vez, para el objetivo se requiere el uso de los *Checks* el cual siguiendo unos sencillos pasos, que también están documentados en el respositorio, hemos conseguido completar con CircleCI.
+
+Otras herramientas habrían sido buenas opciones, véase Travis, que debido a la mencionada inclusión de tarjeta de pago, se deshechó como opción. Jenkins a pesar de ser uno de los más recomendados, si se precisa la ejecución de algo en específico que no se encuentre ni de forma nativa ni en plugins habrá que buscar integraciones con otros sistemas externos, con los gastos que ello conlleva, por lo que poniendo la vista a largo plazo se ha rechazado esta opción.
+
+La afinidad con las herramientas finalmente seleccionadas daba un plus de confianza a la hora de tomar una decisión, siendo las elegidas las comentadas al principio de este apartado. Como razón **extraoficial**, la cual no hemos tomado con anterioridad, que ha ayudado indirectamente a su elección, es que encontramos encuestas por la red en las que se pueden observar como ambas ocupan buenas posiciones de cara a la comunidad de usuarios de los mismos, lo que facilita decantarse por ellos. La información aquí presente se complementa con la que se encuentra [aquí](docs/CI_CircleCI.md) y [aquí](docs/CI_GithubActions.md) .

docs/CI_CircleCI.md

@@ -0,0 +1,31 @@
+# CircleCI
+
+Teniendo en cuenta ya la elección que hemos tomado para los sistemas de integración continua, documentaremos los pasos tomados para el set up de CircleCI.
+
+En primera instancia, nos registraremos con nuestra cuenta de GitHub y autorizaremos el uso en nuestros repositorios.
+
+Tras ello, nos dirigiremos a seleccionar el repositorio en el que aplicaremos esta herramienta, indicando a su vez la rama en la que habremos incluido previamente el archivo *.circleci/config.yml* donde se especifican aspectos como la imagen de nuestro docker.
+
+A continuación podremos comprobar como en nuestro PR, un test de CircleCI aparece, dándonos así ese feedback que buscamos.
+
+## Set Up
+
+Para preparar todo lo relacionado con la herramiento, hemos seguido la documentación que el propio CircleCi proporciona [aquí](https://circleci.com/docs/2.0/), en específico apartados como [este](https://circleci.com/docs/2.0/configuration-reference/) para armar el archivo de configuración y su sintaxis. Aquí testearemos la versión de ruby que tenemos en el Docker implementada para tener una herramienta de integración continua asociada a dicha versión, que es la establecida (3.1.0)
+
+## Ventajas
+
+La elección de CircleCI como uno de nuestros CI no es casualidad. Su sencillez para enlazarlo con nuestro repositorio de Github o la capacidad que tenemos de configurarlo como mejor nos convenga son razones de peso para ello. En este caso hemos usado la versión 2 del mismo debido a recomendaciones presentes en la documentación a pesar de la existencia de nuevas versiones, asegurándonos así de una compatibilidad completa de detalles como pueden ser la imagen del docker. Otra razón es la facilidad que nos presenta esta herramienta para implementar los checks que igualmente se requieren para pasar el Objetivo. Este aspecto se comentará más adelante en profundidad.
+
+## Uso y funcionamiento
+
+Como es observable en los test que pasa el PR, los tests efectivamente se ejecutan y se pasan sin problema alguno en los checks. Desde CircleCI también pasan los tests correctamente.
+
+Todo esto es gracias, en parte, (y por no decir por completo), al fichero de configuración del que disponemos.
+
+Algunos detalles importantes a comentar del mismo es la selección de la versión que usaremos, 2 en este caso, así como la imagen de docker asociada a nuestro proyecto.
+
+Como comando a ejecutar, asociamos el que usamos para correr los tests, siendo "rake test" el nuestro.
+
+## Checks
+
+Como se ha ido comentando en este fichero de documentación, se ha añadido la funcionalidad de activar los checks en el propio PR donde se nos comunica que efectivamente se han pasado los test. Todo lo relacionado con esto se ha sacado de la documentación [aquí](https://circleci.com/docs/2.0/enable-checks/)

docs/CI_GithubActions.md

@@ -0,0 +1,35 @@
+# Github Actions
+
+Teniendo en cuenta ya la elección que hemos tomado para los sistemas de integración continua, documentaremos los pasos tomados para el set up de Github Actions.
+
+En primera instancia, nos iremos al directorio creado en el objetivo anterios *.github/workflows/* y ahí crearemos un archivo .yml de configuración para los Test del Github Actions, el cual llamamos gha.yml.
+
+En este archivo usamos la opción de que cada vez que hacemos un push, correremos este script de testeo en una máquina ubuntu por comodidad. A continuación haremos una serie de pasos dentro de esa máquina, que identificacmos como acciones a realizar. La primera de ellas lo que va a realizar es descargarse nuestro repositorio mediante *actions/checkout@v2* siendo actions la organización donde están las acciones mencionadas antes por defecto en Github. Identificamos *checkout* como el nombre de esa acción y *v2* su versión.
+
+Ahora, haremos uso de algunas acciones para poder setear el lenguaje de Ruby con el que podremos ejecutar a su vez los test que tenemos preparados siguiendo las prácticas que nos recomienda la documentación [aquí](https://docs.github.com/es/actions/automating-builds-and-tests/building-and-testing-ruby).
+
+Usamos *ruby/setup-ruby* como forma provista por Ruby en github para especificar de forma sencilla la versión a usar desarrollado [aquí](https://github.com/ruby/setup-ruby). 
+
+Con la clave *with* indicamos las versiones de ruby con las que realizaremos los test en este caso. Más adelante comentaremos este apartado de las versiones en más detalle más adelante.
+
+Finalmente simplemente instalaremos las dependencias que pudieran ser necesarias con *bundle install* y ejecutaremos los tests que deben pasar para que se de el check aprobado por la herramienta.
+
+## Set Up
+
+Para preparar todo lo relacionado con la herramienta, hemos seguido la documentación que se proporciona en Github [aquí](https://docs.github.com/en/actions), y siguiendo enlaces que se facilitan en los documentos de la asignatura como [este](https://github.com/features/actions).
+
+## Ventajas
+
+La toma de GithubActions como una de nuestras opciones como CI tiene claras razones. Otros CI tienen algo en común, pues los script que se pasan se deben construir desde 0, no hay un paquete que podamos subir a dockerhub directamente. Debemos subirlo a la imagen de dockerhub y correr ahí esas líneas de testeo. Github Actions nos permite no solo crear pasos y ejecutarlas, si no que esos pasos están ya creados por alguien y se pueden reutilizar (en caso de que no estén hechos uno mismo se puede encargar de ello), como es el caso de [este](https://github.com/ruby/setup-ruby) enlace citado anteriormente. Lo mejor es la capacidad de enlazarlo con nuestro repo en Github pues ahí mismo podemos ver los resultados de forma concisa y sencilla.
+
+## Uso y funcionamiento
+
+Siguiendo así los pasos especificados en nuestro archivo, podremos ver en el apartado de actions como se ejecutan y pasan los test que están predefinidos por nosotros.
+
+Al estar integrado en Github, este nos proporciona una vista fácil de comprobar con la que podemos observar el resultado de los tests y ver en qué fallamos en caso de que no pase.
+
+## Versiones de Ruby
+
+Aquí comentaremos un aspecto curioso que se ha dado en el desarrollo del archivo de configuración de Github Actions. A pesar de que la última versión estable de Ruby es la *3.1.0* como se puede ver [aquí](https://www.ruby-lang.org/es/downloads/) en el apartado de versiones estables, y siendo la 2.6.9 la más antigua estable, y las versiones anteriores ninguna tiene soporte. En la documentación seguida para enlazar Ruby y setearlo [aquí](https://docs.github.com/es/actions/automating-builds-and-tests/building-and-testing-ruby) nos recomienda hacer uso de una versión del set up en la que las últimas versiones de Ruby no se encuentran soportadas. Como se indica [acá](docs/img/rubyvError.png) la última versión de la que podemos hacer uso es la *3.0.1*. En este caso y a pesar que [aquí](https://github.com/ruby/setup-ruby) se ha dado soporte a las últimas versiones de Ruby hace apenas un par de semanas, se ha preferido seguir las prácticas que se encuentran en la documentación de GithubActions para ceñirnos a pruebas más fiables.
+
+Por ello hemos optado por usar las versiones 3.0.0, y 3.0.1, pues son distintas a la misma que probamos en la imagen del docker y entran en los parámetros recomendados en la documentación de la herramienta.

iv.yaml

@@ -4,3 +4,4 @@ automatizar:
   fichero: Rakefile
   orden: rake
 test: spec/tienda_web_spec.rb
+CI: .circleci/config.yml