Una configuración de implementación e integración continua con CircleCI y Coveralls
La integración continua (CI) y la implementación continua (CD) son prácticas de desarrollo cruciales, especialmente para los equipos. Todo proyecto es propenso a errores, independientemente de su tamaño. Pero cuando hay un proceso de CI/CD configurado con pruebas bien escritas, esos errores son mucho más fáciles de encontrar y corregir.
En este artículo, veamos cómo verificar la cobertura de la prueba, configurar un proceso de CI/CD que utilice CircleCI y Coveralls e implementar una aplicación Vue en Heroku. Incluso si ese cóctel exacto de herramientas no es de su grado, los conceptos que cubrimos seguirán siendo útiles para cualquier cosa que se incluya en su configuración. Por ejemplo, Vue se puede intercambiar con un marco de JavaScript diferente y los principios básicos siguen siendo relevantes.
Aquí hay un poco de terminología antes de comenzar:
- Integración continua: esta es una práctica en la que los desarrolladores confirman el código tempranamente y con frecuencia, sometiéndolo a varios procesos de prueba y compilación antes de fusionarlo o implementarlo.
- Implementación continua: esta es la práctica de mantener el software implementable en producción en todo momento.
- Cobertura de prueba: esta es una medida utilizada para describir el grado en que se prueba el software. Un programa con alta cobertura significa que la mayor parte del código se somete a pruebas.
Para aprovechar al máximo este tutorial, debes tener lo siguiente:
- Cuenta CircleCI : CircleCI es una plataforma CI/CD que usaremos para la implementación automatizada (que incluye probar y crear nuestra aplicación antes de la implementación).
- Cuenta de GitHub : almacenaremos el proyecto y sus pruebas en un repositorio.
- Cuenta Heroku : Heroku es una plataforma utilizada para implementar y escalar aplicaciones. Lo usaremos para implementación y alojamiento.
- Cuenta Coveralls : Coveralls es una plataforma que se utiliza para registrar y mostrar la cobertura del código.
- NYC : este es un paquete que usaremos para verificar la cobertura del código.
Un repositorio que contiene el ejemplo cubierto en esta publicación está disponible en GitHub.
vamos a configurar las cosas
Primero, instalamos NYC en la carpeta del proyecto:
npm i nycA continuación, debemos editar los scripts package.jsonpara verificar la cobertura de la prueba. Si intentamos verificar la cobertura mientras ejecutamos pruebas unitarias, necesitaremos editar el script de prueba:
"scripts": { "test:unit": "nyc vue-cli-service test:unit",},Este comando supone que estamos creando la aplicación con Vue, que incluye una referencia a cue-cli-service. Será necesario cambiar el comando para reflejar el marco utilizado en el proyecto.
Si intentamos verificar la cobertura por separado, debemos agregar otra línea a los scripts:
"scripts": { "test:unit": "nyc vue-cli-service test:unit", "coverage": "nyc npm run test:unit"}, Ahora podemos verificar la cobertura con un comando de terminal:
npm run coverageA continuación, instalaremos Coveralls que se encarga de informar y mostrar la cobertura:
npm i coverallsAhora necesitamos agregar Overoles como otro script en package.json. Este script nos ayuda a guardar nuestro informe de cobertura de prueba en Coveralls.
"scripts": { "test:unit": "nyc vue-cli-service test:unit", "coverage": "nyc npm run test:unit", "coveralls": "nyc report --reporter=text-lcov | coveralls"}, Vayamos a nuestro panel de Heroku y registraremos nuestra aplicación allí. Heroku es lo que usaremos para alojarlo.
Usaremos CircleCI para automatizar nuestro proceso de CI/CD. Proceda al panel de CircleCI para configurar nuestro proyecto.
Podemos navegar a nuestros proyectos a través de la pestaña Proyectos en la barra lateral de CircleCI, donde deberíamos ver la lista de nuestros proyectos en nuestra organización GitHub. Haga clic en el botón “Configurar proyecto”. Eso nos lleva a una nueva página donde se nos pregunta si queremos usar una configuración existente. De hecho, tenemos nuestra propia configuración, así que seleccionamos la opción “Usar una configuración existente”.
Después de eso, nos llevan a la cartera del proyecto seleccionado. ¡Excelente! Hemos terminado de conectar nuestro repositorio a CircleCI. Ahora, agregamos nuestras variables de entorno a nuestro proyecto CircleCI.
Para agregar variables, debemos navegar a la configuración del proyecto.
La configuración del proyecto tiene una pestaña Variables de entorno en la barra lateral. Aquí es donde queremos almacenar nuestras variables.
Las variables necesarias para este tutorial son:
- El nombre de la aplicación Heroku:
HEROKU_APP_NAME - Nuestra clave API de Heroku:
HEROKU_API_KEY - El token del repositorio de Coveralls :
COVERALLS_REPO_TOKEN
La clave API de Heroku se puede encontrar en la sección de cuenta del panel de Heroku.
El token del repositorio de Coveralls está en la cuenta de Coveralls del repositorio. Primero, debemos agregar el repositorio a Coveralls, lo cual hacemos seleccionando el repositorio de GitHub de la lista de repositorios disponibles.
Ahora que hemos agregado el repositorio a Coveralls. Podemos obtener el token del repositorio haciendo clic en el repositorio.
Integrando CircleCI
Ya hemos conectado Circle CI a nuestro repositorio de GitHub. Eso significa que CircleCI será informado cada vez que ocurra un cambio o acción en el repositorio de GitHub. Lo que queremos hacer ahora es seguir los pasos para informar a CircleCI de las operaciones que queremos que ejecuten después de que detecte cambios en el repositorio.
En la carpeta raíz de nuestro proyecto localmente, creamos una carpeta llamada .circleciy, en ella, un archivo llamado config.yml. Aquí es donde estarán todas las operaciones de CircleCI.
Aquí está el código que va en ese archivo:
version: 2.1orbs: node: circleci/node@1.1 // node orb heroku: circleci/heroku@0.0.10 // heroku orb coveralls: coveralls/coveralls@1.0.6 // coveralls orbworkflows: heroku_deploy: jobs: - build - heroku/deploy-via-git: # Use the pre-configured job requires: - build filters: branches: only: masterjobs: build: docker: - image: circleci/node:10.16.0 steps: - checkout - restore_cache: key: dependency-cache-{{ checksum "package.json" }} - run: name: install-npm-dependencies command: npm install - save_cache: key: dependency-cache-{{ checksum "package.json" }} paths: - ./node_modules - run: # run tests name: test command: npm run test:unit - run: # run code coverage report name: code-coverage command: npm run coveralls - run: # run build name: Build command: npm run build # - coveralls/uploadEsa es una gran cantidad de código. Analicémoslo para saber qué está haciendo.
Orbes
orbs: node: circleci/node@1.1 // node orb heroku: circleci/heroku@0.0.10 // heroku orb coveralls: coveralls/coveralls@1.0.6 // coveralls orbLos orbes son paquetes de código abierto que se utilizan para simplificar la integración de software y paquetes entre proyectos. En nuestro código, indicamos los orbes que estamos usando para el proceso CI/CD. Hicimos referencia al nodeorbe porque utilizamos JavaScript. Hacemos referencia herokuporque estamos utilizando un flujo de trabajo de Heroku para la implementación automatizada. Y, finalmente, hacemos referencia al coverallsorbe porque planeamos enviar los resultados de la cobertura a Coveralls.
Los orbes Heroku y Coverall son orbes externos. Entonces, si ejecutamos la aplicación a través de pruebas ahora, se generará un error. Para eliminar el error, debemos navegar a la página "Configuración de la organización" en la cuenta CircleCI.
Luego, naveguemos hasta la pestaña Seguridad y permitamos orbes no certificados:
Flujos de trabajo
workflows: heroku_deploy: jobs: - build - heroku/deploy-via-git: # Use the pre-configured job requires: - build filters: branches: only: masterUn flujo de trabajo se utiliza para definir una colección de trabajos y ejecutarlos en orden. Esta sección del código es responsable del alojamiento automatizado. Le indica a CircleCI que cree el proyecto y luego lo implemente. requiressignifica que el heroku/deploy-via-gittrabajo requiere que se complete la compilación; eso significa que esperará a que se complete la compilación antes de la implementación.
Trabajos
jobs: build: docker: - image: circleci/node:10.16.0 steps: - checkout - restore_cache: key: dependency-cache-{{ checksum "package.json" }} - run: name: install-npm-dependencies command: npm install - save_cache: key: dependency-cache-{{ checksum "package.json" }} paths: - ./node_modulesUn trabajo es una colección de pasos. En esta sección del código, restauramos las dependencias que se instalaron durante las compilaciones anteriores a través del restore_cachetrabajo.
Después de eso, instalamos las dependencias no almacenadas en caché y luego las guardamos para que no sea necesario volver a instalarlas durante la próxima compilación.
Luego le decimos a CircleCI que ejecute las pruebas que escribimos para el proyecto y verifique la cobertura de la prueba del proyecto. Tenga en cuenta que las dependencias de almacenamiento en caché hacen que las compilaciones posteriores sean más rápidas porque almacenamos las dependencias, eliminando así la necesidad de instalar esas dependencias durante la siguiente compilación.
Subiendo nuestro código de cobertura a monos
- run: # run tests name: test command: npm run test:unit - run: # run code coverage report name: code-coverage command: npm run coveralls# - coveralls/uploadAquí es donde ocurre la magia de Coveralls porque es donde realmente ejecutamos nuestras pruebas unitarias. ¿Recuerdas cuando agregamos el nyccomando al test:unitscript en nuestro package.jsonarchivo? Gracias a eso, las pruebas unitarias ahora brindan cobertura de código.
Las pruebas unitarias también brindan cobertura de código, por lo que incluiremos aquellas incluidas en el informe de cobertura. Es por eso que llamamos a ese comando aquí.
Y por último, el código ejecuta el script Coveralls que agregamos en package.json. Este script envía nuestro informe de cobertura a los overoles.
Quizás hayas notado que la coveralls/uploadlínea está comentada. Se suponía que esto sería el carácter final del proceso, pero al final se convirtió más bien en un bloqueo o un error en términos de desarrollador. Lo comenté porque puede ser la carta de triunfo de otro desarrollador.
Poniendo todo junto
¡Contempla nuestra aplicación, completa con integración e implementación continuas!
La integración y el despliegue continuo ayudan en muchos casos. Un ejemplo común sería cuando el software se encuentra en una etapa de prueba. En esta etapa, se realizan muchas confirmaciones para muchas correcciones. Lo último que me gustaría hacer como desarrollador sería ejecutar pruebas manualmente e implementar mi aplicación manualmente después de cada cambio menor realizado. Ughhh. ¡Odio la repetición!
No sé ustedes, pero CI y CD son cosas que conozco desde hace algún tiempo, pero siempre encontré maneras de dejarlas de lado porque parecían demasiado difíciles o consumían mucho tiempo. Pero ahora que ha visto la configuración relativamente poca que existe y los beneficios que conlleva, es de esperar que se sienta animado y listo para darles una oportunidad en su propio proyecto.
Deja un comentario