En la actualidad multitud de Sistemas de Integración Continua. Vamos a proceder a elegir algunos de ellos para probarlos y ver cuales se adaptan más para los requisitos de este proyecto. Estos son:
- Poder correr el lenguaje utilizado en nuestro proyecto para lanzar los tests programados.
- Probar distintas versiones de Python.
- Poder integrar el CI con Github.
- Ser un sistema demandado por el panorama laboral actual.
-
Uno de los principales inconvenientes de Travis son los planes de pago. Esto puede suponer un problema para algunos usuarios que prefieran optar por otros Sistemas de Integración Continua antes que pagar una cuota mensual. Pero realmente sin probarlo no sabemos si realmente puede merecer la pena, no para uso personal alomejor, pero si para propuesta y uso en una empresa ya que sería ella la encargada del mantenimiento. Para ello vamos a utilizar el mes gratuirto que nos ofrece para ver si realmente merece la pena.
-
Usando la opción de Trigger Build desde Travis crearemos el fichero .travis.yaml que será el encargado de proporcionar la configuración para la herramienta en la rama especificada. Este detalle parece una tontería pero es de bastante utilidad ya que en Azure no puedes elegir una rama ya existente, debes crear una nueva a partir de master.
language: python
python:
- "2.7"
- "3.8.10"
- "nightly"
# Comandos para instalar las dependencias
install:
- pip install poetry
- poetry install
# Comandos para lanzar los tests
script:
- invoke test- Una vez hecho esto se crearán 3 jobs (uno can cada versión de Python especificada) en los que se lanzarán los tests del repositorio tal y como hemos indicado en el YAML.
- Podremos entrar en cada Job para ver el log resultante de la ejecución.
-
Como cada uno de los anteriores Sistemas de CI lo primero que debemos hacer es iniciar sesión mediante nuestra cuenta de Github y autorizar el uso de CircleCI.
-
Una vez enlazadas las cuentas y elegido el repositorio podremos pasar a configurar nuestro YAML de CircleCI. En este caso vamos a hacer uso de nuestra imagen construida y desplegada en Dockerhub.
- Una vez configurado el YAML podremos commitear los cambios y lanzarlo. Esto creará un Pipeline donde se lanzarán los jobs especificados en el archivo de configuración.
- Además, podremos ver el log step por step de la ejecución de nuestro pipeline.
- Como estamos usando nuestra propia imagen Docker desplegada en Dockerhub no necesitamos configurar el manejo de la cache en nuestro YAML ya que todas las dependencias vienen instaladas en la imagen. Así le sacamos partido a nuestro Dockerfile construido facilitándonos la configuración de Circle CI en nuestro repositorio.
Al igual que nuestra Github Action para construir y subir la imagen Docker a DockerHub podemos crear otra para pasar los tests del repositorio cuando deseemos.
- Lo primero crear el archivo encargado de la ejecución de los tests y añadirlo al directorio .github/workflows/.
- Una vez creado comenzaremos configurando cuando queremos que se lance la Github Action. En este caso, como queremos usarla para comprobar los tests únicamente se lanzará cuando se modifique algún archivo del directorio my_hairdressing_app/ o del directorio testing/.
- Ahora pasamos a configurar el job que ejecutará los tests. Al igual que en Azure Pipelines podemos configurar la acción para que compruebe diferentes versiones de Python. Vamos a seguir las buenas prácticas a la hora de construir el job tal y como se indica en el repositorio oficial de Github Actions.
Uno de los puntos muy positivos de Azure Pipelines es su completa y actualizada documentación, con una guía de integración con Github y otra de Compilación de aplicaciones de Python.
- Creamos nuestra cuenta de Azure accediendo mediante nuestra cuenta de Github y creamos el mismo repositorio que queremos enlazar, en este caso IV, donde construiremos nuestro pipeline.
- En este pipeline podremos crear directamente un paquete Python enlazado a nuestro repositorio de Github para ejecutar nuestra aplicación con distintas versiones de Python. Esto generará automáticamente un YAML de configuración que modificaremos para adaptarlo a nuestros gestores de dependencias y gestores de tareas. Siguiendo estos pasos el YAML podremos crearlo en la rama master del repositorio o en una nueva rama creada a partir de esta. Como nosotros realmente lo que queremos es trabajar en la rama de nuestro Pull Request, crearemos directamente el YAML en nuestro proyecto y desde Azure al crear el pipeline seleccionaremos la opcción de Existing Azure Pipelines YAML file.
- La primera vez que ejecutemos nuestro pipeline dará error. Esto es debido a que necesitamos solicitar en un formulario una "subvención gratuita de paralelismo" para poder lanzar los jobs con las diferentes versiones de Python. Una vez solicitado y concedido procederemos a ejecutarlo:
Como podemos ver no todas las versiones de Python están disponibles en Azure Pipelines por lo que tendremos que elegir las mas cercanas a nuestro interés.
##[warning]Specifying an exact version is not recommended on Microsoft-Hosted agents. Patch versions of Python can be replaced by new ones on Hosted agents without notice, which will cause builds to fail unexpectedly. It is recommended to specify only major or major and minor version (Example:
3or3.6)
Al ejecutar los jobs con versiones específicas de Python obtenemos el warning anterior. En este nos avisa de que no está recomendado utilizar una versión exacta ya que pueden cambiar en los Hosted agents. Para evitarnos errores inesperados pasaremos a especificar las versiones únicamente como major y minor.
Para los requisitos especificados los cuatro Sistemas de Integración Continua testeados nos han dado buenos resultados con una facil configuración e integración. Sin embargo uno queda descartado por no tener una versión freemium y solo tener un mes de prueba como es el caso de Travis. Aunque para el objetivo de la asignatura solo se pide la integración de dos sistemas he considerado dejar CircleCI, Azure Pipelines y Github Actions.