Quiero hacer una reserva de inmediato: este artículo no ofrece una receta lista para usar. Es más bien mi historia de viajar al mundo de Typecript y NodeJS, así como los resultados de mis experimentos. Sin embargo, al final del artículo habrá un enlace al repositorio de GitLab, que puede ver, y tal vez tome algo que le guste. Tal vez incluso en mi experiencia, cree su propia solución automatizada.

Porque es necesario

Entonces, ¿por qué necesita crear bibliotecas, o en un caso particular, paquetes NPM?

1. Reutilizando código entre proyectos.
   
   Todo comenzó con el hecho de que noté la costumbre de crear una carpeta / herramientas en los proyectos. Además, también llevo la mayor parte de esta carpeta cuando cambio a un nuevo proyecto. Y luego me hice una pregunta, ¿por qué no hacer un paquete NPM en lugar de copiar y pegar y luego simplemente conectarlo a cualquier proyecto?
2. Ciclo de vida diferente. En una de las aplicaciones, hubo un gran ensamblaje corporativo de componentes como dependencia. Fue posible actualizarlo solo en su totalidad, incluso si solo se actualizó un componente. Los cambios en otros componentes podrían romper algo y no siempre tuvimos suficiente tiempo estimado para volver a probarlo. Este modelo es muy inconveniente. Cuando cada paquete cumple su propósito o un pequeño conjunto de objetivos relacionados, ya se pueden actualizar cuando realmente se necesita. Además, las siguientes versiones del paquete se lanzan solo cuando tienen algunos cambios, y no "para la empresa".
3. Separe el código menor de la lógica comercial central. DDD tiene el principio de la destilación del dominio; implica identificar piezas de código que no pertenecen al dominio principal y aislarse de ellas. ¿Y cómo es mejor aislar que llevar este código a un proyecto separado?
   Por cierto, la destilación del dominio es muy similar al principio SRP solo en un nivel diferente.
4. Cobertura de código propio. En uno de los proyectos en los que participé, la cobertura del código fue de aproximadamente el 30%. Y la biblioteca que saqué de ella tiene una cobertura de aproximadamente el 100%. El proyecto, aunque perdió el porcentaje de cobertura, ya que estaba en la zona roja antes de la eliminación, se mantuvo. Y la biblioteca tiene indicadores tan envidiables hasta el día de hoy, después de casi un año y 4 versiones principales.
5. Código abierto El código que no contiene lógica de negocios es el primer candidato para la separación del proyecto, por lo que puede abrirse.

Lanzar nuevas bibliotecas "caras"

Existe tal problema: para crear una biblioteca, no es suficiente obtener un repositorio git debajo de ella. También debe configurar la tarea para que el proyecto pueda ensamblarse, realizar una verificación estática (pelusa) y probar. Además, además de las pruebas, es recomendable recopilar la cobertura del código. Además, deberá publicar el paquete manualmente cada vez. Y todavía necesita escribir léame. Eso es solo con el archivo Léame que no puedo evitar.

Entonces, ¿qué se puede hacer con todas estas tareas aburridas y sin interés?

Primer paso: semilla

Comencé creando un proyecto semilla. Es una especie de kit de inicio, tenía la misma estructura que mi primer proyecto para llevar el código en un paquete separado. Creé en él tragos y secuencias de comandos que construirían, probarían y recogerían la cobertura del paquete en una sola acción. Ahora, para crear otro proyecto, necesitaba clonar la semilla en una nueva carpeta y cambiar el origen para que apunte al repositorio recién creado en GitHub (entonces todavía usaba GitHub).

Esta forma de crear proyectos ofrece otra ventaja. Ahora, los cambios con respecto a la construcción o prueba del proyecto se realizan una vez, en el proyecto semilla. Y copiar y pegar estos cambios ya no es necesario. En cambio, en el proyecto final, la próxima vez que tenga que trabajar con él, creo un segundo control remoto llamado semilla y tomo estos cambios desde allí.

Y funcionó para mí por un tiempo. Hasta que usé semilla en un proyecto donde participaron varios desarrolladores. Escribí una instrucción en tres pasos: tomar el último maestro, compilar y publicar. Y en algún momento, uno de los desarrolladores, por alguna razón, completó el primer paso y el tercero. ¿Cómo es esto posible?

Segundo paso: publicación automática

A pesar del hecho de que fue un solo error, las acciones manuales como la publicación son aburridas. Por lo tanto, pensé que era necesario automatizarlo. Además, se necesitaba CI para evitar que los commits rojos ingresen al master. Al principio intenté usar Travis CI, pero encontré la siguiente restricción. Considera la solicitud de extracción en maestro equivalente a una confirmación en maestro. Y tuve que hacer cosas diferentes.

Uno de mis colegas me aconsejó que prestara atención a GitLab y su CI, y todo lo que quería funcionaba allí.

Creé el siguiente proceso de trabajo con el proyecto, que se utiliza cuando necesita corregir un error, agregar una nueva funcionalidad o crear una nueva versión:

1. Creo una rama del maestro. Escribo código y pruebas en él.
2. Creo una solicitud de fusión.
3. GitLab CI ejecuta automáticamente pruebas en un nodo: último contenedor
4. La solicitud pasa la revisión de código.
5. Después de congelar la solicitud, GitLab ejecuta el segundo conjunto de scripts. Este conjunto crea una etiqueta en la confirmación con el número de versión. El número de versión se toma de package.json, si se aumenta manualmente allí, de lo contrario, se toma la última versión publicada y se incrementa automáticamente.
6. El script construye el proyecto y ejecuta las pruebas nuevamente.
7. En los últimos pasos, la etiqueta de versión se envía al repositorio y el paquete se publica en NPM.

Por lo tanto, la versión indicada en la etiqueta siempre coincide con la versión del paquete publicado desde este commit. Para que estas operaciones funcionen, debe especificar variables de entorno con claves de acceso al repositorio y NPM en el proyecto GitLab.

Último paso: automatizar todo

En este punto, ya automaticé mucho, pero todavía había muchas acciones manuales para crear un proyecto. Esto, por supuesto, ya era progreso de todos modos, porque las acciones se realizaron una vez por proyecto, y no en cada versión. Pero aún así, la instrucción consistió en 11 pasos. Y yo mismo me equivoqué un par de veces al seguir estos pasos. Entonces decidí que desde que comencé a automatizar, necesito llevar esto al final.

Para que esta automatización completa funcione, pero la computadora necesito tener 3 archivos en la carpeta .ssh. Pensé que esta carpeta está bastante protegida, ya que la clave privada id_rsa ya está almacenada allí. Este archivo también se usará para permitir que GitLab CI pase etiquetas al repositorio.

El segundo archivo que puse allí es "gitlab", contiene la clave de acceso a la API de GitLab. Y el tercer archivo es "npm", la clave de acceso para publicar el paquete.

Y entonces comienza la magia. Todo lo que necesita para crear un nuevo paquete es ejecutar un comando en la carpeta semilla: "gulp startNewLib -n [npmName] / [libName]". Hecho, el paquete está creado, listo para su desarrollo y publicación automática.

Por ejemplo, el paquete "vlr / validity" se creó de esta manera.

Este comando hace lo siguiente:

1. Crea un proyecto en GitLab
2. Los clones se inicializan en una carpeta local junto a la carpeta desde la que se ejecuta el comando.
3. Cambia el origen del proyecto creado en el paso 1
4. Empuja la rama maestra
5. Crea variables de entorno en un proyecto a partir de archivos en una carpeta .ssh
6. Crea una primera rama de implementación
7. Cambia el nombre de la biblioteca en package.json, confirma y empuja la rama

Todo lo que necesita después de esto es poner el código allí y crear una solicitud de fusión.

Como resultado, de lo cual puede estar orgulloso, desde el momento en que se decide poner algún tipo de código en un proyecto separado hasta que se publique la primera versión, transcurren aproximadamente cinco minutos. Cuatro de ellos ocupan dos canales de GitLabCI, y un minuto para iniciar el comando anterior, arrastre y suelte el código, y haga clic en los botones en la interfaz de GitLab para crear y luego mantener la solicitud.

Existen algunas limitaciones: el nombre de GitLab debe coincidir con el nombre en npm. Y, sin embargo, este comando, a diferencia del resto de la funcionalidad en el proyecto semilla, solo funciona en Windows.

Si está interesado en este proyecto semilla, puede estudiarlo en el siguiente enlace .