DEV Community: Manuel Gil @imgildev

SemVer: Qué es y por qué es importante para el desarrollo de software

Manuel Gil @imgildev — Thu, 06 Apr 2023 05:11:33 +0000

Introducción

En el mundo del desarrollo de software, la gestión de versiones es un aspecto fundamental para garantizar la calidad y la compatibilidad del software. A continuación veremos como funcionan estas versiones y como podemos aplicarla a nuestros proyectos.

¿Qué es SemVer?

El Versionamiento Semantico o SemVer por su nombre en inglés (Semantic Versioning), es una de las convenciones de nomenclatura de versiones más populares para entender las versiones de un software, que proporciona una manera semántica y consistente etiquetas para rastrear las versiones de un proyecto de software.

Esta nomenclatura nos permite conocer el estado de una aplicación de manera simple y la podemos encontrar como una serie de número dividido en tres grupos separados por un punto. Cada grupo se conoce como mayor, menor y parche respectivamente (major, minor y patch en inglés o también como x, y, z), por ejemplo: 1.0.1, 2.1.0, 14.2.9, etc…

Cada uno de estos grupos sirve para describir un estado diferente en el proceso de desarrollo:

Patch: el cambio de este número representa una reparación en el código. Esta actualización se realiza siempre que se soluciona un error en el código para asegura su estabilidad y seguridad, por ejemplo: 1.0.1 → 1.0.2, 2.1.0 → 2.1.1, 14.2.9 → 14.2.10.
Menor: este número representa una característica nueva, lo que implica que la actualización es segura y agrega una funcionalidad o comportamiento nuevo que se puede implementar. Al agregar una característica nueva se actualiza este grupo y el número de patch pasa a cero, por ejemplo: 1.0.1 → 1.1.0, 2.1.0 → 2.2.0, 14.2.9 → 14.3.0.
Major: cuando este número cambia está representando una ruptura, lo que implica que dicha actualización causará daños en el código ya que esta versión o es compatible con versiones anteriores. La actualización de este grupo requiere que los números tanto de menor como de patch sean restaurados a cero, por ejemplo: 1.0.1 → 2.0.0, 2.1.0 → 3.0.0, 14.2.9 → 15.0.0.

También es posible encontrar información acerca de la estabilidad de un proyecto como un dato adicional en el path:

Dev: esta etiqueta hace referencia a un código que aún se encuentra en un estado de desarrollo. Ejemplo: 1.0.1-dev, 2.1.0-dev, 14.2.9-dev.
Alpha: es la primera etapa de código que se prepara para ser parte de un release. Ejemplo: 1.0.1-alpha, 2.1.0-alpha, 14.2.9-alpha.
Beta: es una versión más estable pero que aún no cumple con la estabilidad suficiente para ser un release. Ejemplo: 1.0.1-beta, 2.1.0-beta, 14.2.9-beta.
RC1: esta versión es una posible candidata a un para un release, aun siendo un pre-release cuenta con una gran estabilidad. Ejemplo: 1.0.1-RC1, 2.1.0-RC1, 14.2.9-RC1.
RC2: aun cuando esta versión es un pre-release, es la más estable y cercana al release. Ejemplo: 1.0.1-RC2, 2.1.0-RC2, 14.2.9-RC2.
Stable: esta versión tiene toda la estabilidad y se considera como release, por el mismo motivo no requiere ser agregada en la etiqueta semántica ya que incurriría en una redundancia. Ejemplo: 1.0.1, 2.1.0, 14.2.9.

Todas aquellas versiones inferiores a la 1.0.0 también son consideradas como pre-releases.

Según esta nomenclatura, un proyecto iniciaría con un mínimo de una característica lo que implica que la versión mínima sería 0.1.0, de la misma manera, si un proyecto o producto ya se encuentra en producción su versión mínima sería 1.0.0.

¿Por qué es importante SemVer en el desarrollo de software?

Ya que SemVer es una convención popular, al aplicarla a cualquier desarrollo mostrará el estado un software de manera rápida a las personas que contribuyen en él, al mismo tiempo que es posible crear o encontrar documentación que apoyan este tipo de versionamiento como son los llamados archivos de cambios o changelog.

SemVer también es usado por muchos gestores de dependencias como npm , composer , maven , entre otros; para describir el estado de las dependencias de un proyecto y sirve como apoyo a los grupos de desarrollo en cuanto a los beneficios o desventajas que se pueden encontrar al actualizar estas dependencias.

Cómo funciona SemVer en los gestores de dependencias

En muchos de los proyectos #OpenSource integran SemVer a través de etiquetas semánticas, las cuales podemos encontrar ordenadas de la versión más alta a la más baja y hacen referencia a un punto especifico del código.

## v1.1.0

on Mar 7, 2023

- commit: 606e572

## v1.0.0

on Mar 1, 2023

- commit: e02581f

## v0.3.1

on Feb 16, 2023

- commit: d194c2e

## v0.3.0

on Feb 15, 2023

- commit: 570045b

## v0.3.0-RC2

on Feb 14, 2023

- commit: 28fe4ec

## v0.3.0-RC1

on Feb 12, 2023

- commit: ecffd4c

Basado la información de estas etiquetas y algunos operadores matemáticos y lógicos, los gestores de dependencias son capaces de detectar las condiciones y restricciones para la instalación y actualización de las dependencias.

Las restricciones que se pueden encontrar son:

Restricción de versión exacta: define una versión exacta a instalar de un paquete. Ejemplo "someone/my-package": "2.1.3" instalará la versión 2.1.3.
Rango de versiones: es posible definir un rango superior e inferior para la instalación de una dependencia. Ejemplo: "someone/my-package": ">=2.1.0 || <2.2.0" instalará cualquier versión entre la 2.1.0 y 2.2.0.
Intervalo de versiones con guiones: al igual que la restricción por rango podemos definir los límites de esta restricción separados por un guion. Ejemplo "someone/my-package": "2.1.0 - 2.3.0" instalará cualquier versión entre la 2.1.0 y 2.3.0.
Rango de versión comodín: este restricción está provista con un comodín o wildcard para definir el rango de instalación de manera simple. Ejemplo: "someone/my-package": "2.1.*" instalará cualquier versión desde la 2.1.0 hasta la 2.1.n disponible, "someone/my-package": "2.*" instalará cualquier versión desde la 2.0.0 hasta la 2.n disponible.
Rango de versiones de tilde: el comportamiento de esta restricción es similar al uso de wildcard, sin embargo hace uso de una tilde o virgulilla para definir su rango. Ejemplo "someone/my-package": "~2.1.0" instalará cualquier versión superior o igual a 2.1.0 e inferior a 2.2.0, "someone/my-package": "~2.1" instalará cualquier versión superior o igual a 2.1.0 e inferior a la 3.0.0.
Rango de versión de caret: esta versión mejorada hace uso de un acento o caret realizará una instalación que no rompa con la estabilidad del proyecto. Ejemplo: "someone/my-package": "^2.1.0" instalará cualquier versión superior o igual 2.1.0 e inferior a 3.0.0 ya que este cambio puede generar rupturas de código.

También debemos tener en cuenta que los gestores de dependencias están en la capacidad de instalar versiones de desarrollo o pre-release dentro de los rangos definidos y dependiendo de su configuración.

Cómo implementar SemVer en un proyecto de software

Ya sea que deseemos o no publicar nuestro proyecto, los gestores de dependencias cuentan con una etiqueta para llevar el versionamiento de nuestro software, como ocurre en el caso de npm:

{
  "name": "test",
  "version": "1.0.0", // Etiqueta para uso de SemVer
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Git y plataformas como GitHub también nos permite agregar etiquetas con las cuales podemos hacer referencia a nuestro código:

git tag -a v1.0.0 -m "version 1.0.0" <commit_sha>

También existe herramientas que nos pueden facilitar la publicación de versiones en nuestro código, algunos ejemplos para proyectos con javascript:

Release It!: herramienta CLI para la automatización de versionamiento y publicaciones.
Release Please: herramienta para la automatización de archivos changelog, versionamiento y publicación.
Sui: paquete para gestión de commits y releases en proyectos monorepo.

Conclusión

En resumen, SemVer es una convención de nomenclatura de versiones que se utiliza para etiquetar y rastrear las versiones de un proyecto de software de manera semántica y consistente. Es importante para el desarrollo de software porque ayuda a los desarrolladores y usuarios a comprender los cambios en una nueva versión del software y a gestionar la compatibilidad del software. Implementar SemVer en un proyecto de software es una práctica recomendada para garantizar la calidad y la compatibilidad del software.

Automatizando la generación de datos ficticios con Seed, Factory, Faker y TypeORM en NestJS

Manuel Gil @imgildev — Fri, 31 Mar 2023 22:47:43 +0000

Introducción

En muchas ocasiones necesitamos generar datos ficticios para probar nuestro desarrollo o llenar nuestra base de datos de pruebas. La creación manual de estos datos puede resultar tediosa y llevar mucho tiempo. En este artículo, hablaremos sobre cómo automatizar el proceso de generación de datos ficticios utilizando TypeORM.

Para empezar es necesaria la instalación de una extensión adicional ya que TypeORM por si solo no cuenta con una opción para generar datos ficticios.



npm install --save @nestjs/typeorm typeorm typeorm-extension

Adicional a esto se requiere la instalación de un driver de conexión a la base de datos.



npm install pg --save

En este caso se usará PosgreSQL por lo que realizamos la instalación del controlador recomendado por TypeORM en su sitio.

Para este ejemplo se tendrán dos entidades hipotéticas user y post .

Por último se hace la instalación de dependencias necesarias para la ejecución del código.



npm install --save @nestjs/config @types/bcrypt bcrypt

Para el ejemplo se plantea la siguiente estructura de carpetas.

Definiendo un Factory

Un factory es una función que nos sirve para establecer una estructura u objeto con datos aleatorios ficticios en tiempo de ejecución. Con el uso de Faker podemos generar nombres, direcciones, números de teléfono, correos electrónicos y muchos otros tipos de datos ficticios.

En la definición de nuestro Factory se cuenta con una instancia de la librería Faker para generar datos aleatorios.

Por ejemplo, el archivo user.factory.ts contendría.

Se puede encontrar más información acerca de Faker y sus características en fakerjs.dev.

Semilla o Seed

A través de un seed o semilla se puede generar un set de datos aleatorios, para ello se hace uso de una clase seeder que se apoya de un Factory para la creación de datos.

Lo podemos ver en el archivo user.seeder.ts.

En el caso de la entidad post existe una relación que requiere de un usuario en la base de datos, por lo que se hace uso de un dato conocido para agregar esta relación, el archivo post.seeder.ts sería el siguiente.

Para poder tener un mejor control de la ejecución del sets es importante definir un punto de entrada, el cual tiene el nombre init.seeder.ts por convención y será llamado en las configuraciones de TypeORM.

Configuración de TypeORM

Para este ejemplo se define un archivo typeorm.config.ts en el que se hace uso de las entidades, migraciones y seeds.

Esta configuración requiere de las variables de entorno por lo que se hace uso del ConfigModule .

En el archivo .env se deben actualizar las variables para la conexión a la base de datos.



DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=root
DATABASE_DATABASE=test

Ejecución

Para ejecutar las migraciones y generación de datos aleatorios se agregan las configuraciones requeridas en el archivo package.json:



"scripts": {
  ...
  "typeorm": "ts-node -r tsconfig-paths/register node_modules/typeorm/cli.js -d database/config/typeorm.config.ts",
  "mig-gen": "npm run typeorm migration:generate -- ",
  "mig-run": "npm run typeorm migration:run",
  "mig-rev": "npm run typeorm migration:revert",
  "seed": "ts-node -r tsconfig-paths/register node_modules/typeorm-extension/dist/cli/index.js seed -d database/config/typeorm.config.ts"
},

Para iniciar ejecutamos el comando migration:generate a través del atajo que se acaba de ingresar.



npm run mig-gen -- database/migrations/init

Una vez creado el archivo con la migración inicial, corremos esta migración con el atajo de migration:run.



npm run mig-run

Por último ejecutamos la semilla con el comando seed.



npm run seed

Esto generaría un set de datos aleatorios con en la base de datos con el que podemos probar la aplicación.

El código completo de este ejemplo se encuentra publicado en github si desea descargarlo.

ManuelGil / nest-typeorm-seed-example

This is a example of seeding with TypeOrm and NestJS

A progressive Node.js framework for building efficient and scalable server-side applications.

Description

Nest framework TypeScript starter repository.

Installation

$ npm install

Running the app

# development
$ npm run start

# watch mode
$ npm run start:dev

# production mode
$ npm run start:prod

Test

# unit tests
$ npm run test

# e2e tests
$ npm run test:e2e

# test coverage
$ npm run test:cov

Support

Nest is an MIT-licensed open source project. It can grow thanks to the sponsors and support by the amazing backers. If you'd like to join them, please read more here.

Stay in touch

Author - Kamil Myśliwiec
Website - https://nestjs.com
Twitter - @nestframework

License

Nest is MIT licensed.

View on GitHub

Conclusión

La generación de datos ficticios es una parte importante del desarrollo de aplicaciones. Utilizando Seed, Factory y Faker podemos automatizar este proceso y ahorrar mucho tiempo. Con estos tres elementos se puede generar grandes cantidades de datos ficticios de forma rápida y eficiente.

¿Qué es GitHub Pages?

Manuel Gil @imgildev — Sat, 18 Mar 2023 18:58:34 +0000

GitHub Pages es un servicio gratuito ofrecido por GitHub que permite a los usuarios alojar sitios web estáticos directamente desde sus repositorios de GitHub. Esto significa que cualquier usuario de GitHub puede publicar su propio sitio web sin tener que pagar por alojamiento web o preocuparse por la configuración del servidor.

Para empezar a utilizar GitHub Pages, los usuarios simplemente necesitan crear un nuevo repositorio en GitHub y agregar archivos HTML, CSS y JavaScript a su proyecto. Luego, pueden habilitar GitHub Pages en la configuración del repositorio y elegir una rama o carpeta para alojar su sitio web.

GitHub Pages también permite a los usuarios personalizar su sitio web utilizando plantillas de Jekyll, un generador de sitios web estáticos que se integra perfectamente con GitHub Pages. Los usuarios pueden elegir entre varias plantillas prediseñadas o crear la suya propia para personalizar completamente su sitio web.

Además, GitHub Pages también incluye características avanzadas como soporte para SSL, redirección de URL y análisis web. Los usuarios también pueden agregar su propio dominio personalizado para su sitio web, lo que les permite crear una presencia en línea única y profesional.

En resumen, GitHub Pages es una herramienta excelente para cualquier usuario que quiera crear un sitio web estático de manera rápida y fácil. Con su integración perfecta con GitHub y su amplia gama de características, GitHub Pages ofrece una solución de alojamiento web simple pero poderosa para cualquier persona que quiera compartir su trabajo en línea.