Cómo utilizar Dependabot para mantener su entorno actualizado

Agregar dependencias a un proyecto a menudo le ayuda a no reinventar la rueda. Pero al mismo tiempo, puede causar problemas en muchos aspectos diferentes del proyecto:

  • Control de versiones: a veces, las dependencias pueden requerir versiones específicas de otras dependencias y esto puede causar problemas en su aplicación
  • Empaquetado: debe tener cuidado de no terminar con demasiado código adicional que inflará sus paquetes
  • Actualización: JavaScript se mueve rápido, y si no actualiza los paquetes con regularidad, jugará Jenga en el futuro.

Existen diferentes herramientas para cubrir la tarea de actualizar dependencias, como Dependencies.io, Snyk y Dependabot. Como he estado usando Dependabot por un tiempo, decidí escribir sobre mi experiencia.

Dependabot es una herramienta adquirida por GitHub hace un año que verifica archivos de dependencia de diferentes lenguajes (Ruby, JavaScript, Python, PHP, Elixir, por nombrar algunos) y encuentra nuevas versiones de las bibliotecas que está utilizando en su proyecto. Aquí está la configuración:

Captura de pantalla de Dependabot

Las actualizaciones diarias pueden ser abrumadoras y creo que las actualizaciones semanales tienen un mejor costo / beneficio. Además, me asigno las solicitudes de extracción para poder recibir notificaciones tan pronto como se abran.

Cómo utilizar Dependabot de forma eficaz

Dependabot incluye, en cada RP, notas de la versión, registros de cambios, enlaces de confirmación y detalles de vulnerabilidad siempre que estén disponibles. Esto es útil porque puede echar un vistazo a la información y decidir continuar o no.

Sin embargo, como programadores pragmáticos, queremos asegurarnos de que las cosas no se rompan. Los detalles de las relaciones públicas son importantes, pero más que eso, queremos una simulación de todos (o casi todos) los entregables que tiene el proyecto.

Integración CI

Esta captura de pantalla muestra lo que sucede cada vez que se abre un PR en la base de código de la biblioteca de componentes de mi trabajo.

  • Pruebas (Jest / Bundle) : la tarea Jest probará los componentes de React mientras que la tarea Bundle simulará los comandos de agrupación que ejecutamos cuando queremos actualizar el paquete en el registro de NPM
  • Linters (hojas de estilo / JavaScript) : los archivos de hoja de estilo siguen una configuración personalizada de sass-lint y el código JS sigue una serie de reglas de ESLint. Si un RP presenta una nueva versión de un linter con nuevas reglas, podremos capturar eso.
  • Cypress (Prueba de captura de pantalla / Prueba de accesibilidad) : si un paquete nuevo introduce cambios que pueden reflejarse en la apariencia de los componentes, Cypress capturará la diferencia, la capturará y almacenará en S3. Dado que Cypress necesita una versión en vivo del sitio web de documentación, también cubrimos el proceso de compilación de Gatsby.

Con todos estos pasos, es muy poco probable que un paquete externo rompa nuestra rama maestra. Felicitaciones a mi compañero de trabajo Grant Lee que también trabaja en este proyecto.

También publicado en mi blog. Si te gusta este contenido, sígueme en Twitter y GitHub. Foto de portada de Zhang Kenny en Unsplash