Combined Shape
ArtículosLabsContacto

Automatizando releases en tu proyecto

En cualquier tipo de software las versiones son algo familiar. La primera versión de un proyecto es normalmente denotada como 1.0.0, la versión beta cuando un proyecto es nuevo, o una versión menor cuando se arregla algún error o existe una nueva feature.

Al instalar un plugin de WordPress o una librería de NPM, cada vez que cambiamos una versión algo se arregla o algo se añade y la forma sistematica para describir esos cambios es a través de “semantic versioning”.

¿Qué es semantic versioning (semver)?

Semantic versiong es la forma como denotamos el cambio de un proyecto.

  • Patch: (1.0.x), denota un “fix” normalmente se crea cuando se corrige algún error.
  • Minor: (1.x.0), denota un cambio pequeño, normalmente añade funcionalidad que no rompe nada en la versión actual.
  • Major: (x.0.0), denota un “breaking change”, es decir un cambio en el API, un refactor que afect la interfaz de tu proyecto y que al consumidor del proyecto le puede forzar a hacer algún cambio en la implementación del proyecto.

Haciendo un nuevo release

Implementar semantic versioning es bastante sencillo y la complejidad viene con la personalización que necesitemos, veamos la que más utilizo.

Instalemos las herramientas

  1. Intalemos el paquete para hacer semantic release yarn add --dev semantic-release

  2. Agregemos la configuración a package.json

    "release": {
"verifyConditions": [
 "@semantic-release/github"
],
"publish": [
 "@semantic-release/github"
],
"githubUrl": "https://api.github.com"
}

Donde en este ejemplo, es de un proyecto en el que no voy a publicar el proyecto en NPM. Este solamente creará un tag y un release en github.

Si en caso quisiera que también el proyecto se publicara en el registry, la configuración sería algo así.

En este ejemplo, usaremos Travis CI, y la configuración necesaria es una variable de entorno GH_TOKEN, que puedes obtener en el área personal de tokens y luego agregar en tu proyecto.

En caso necesites publicar el projecto a NPM registry, debes agregar NPM_TOKEN.

Luego debemos hacer saber a nuetro CI que deseamos publicar una nueva versión en el build, agregando la configuración en Travis (.travis.yml):

language: node_js
node_js:
- node
cache: npm
script:
- npm run build
after_success:
  - npm run semantic-release
notifications:
  email: false

Cada vez que se haga un push a master en tu proyecto (merge o commit), este hará un nuevo release en GitHub. En caso utilizas yarn, puedes cambiarlo y funcionará de igual forma.

last-release-githublast-release-github

Haciendo commits “semánticos”

Las nuevas versiones de tu proyecto pueden ser descritas por los commits, y siguen el formato de Angular.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Los tipos de commits más comunes son:

  • fix: genera un patch version
  • feat: genera un minor version
  • BREAKING CHANGE: genera un major version

Sin embargo existen más.

Al principio puede ser tedioso y una tarea mental hacer commits con este formato, haciendo que no se genere una nueva versión de nuestro proyecto. Para esto existen herramientas que enforzan y facilitan la creación de commits con este formato.

  1. Instalemos el commit linter. yarn add --dev husky @commitlint/config-conventional @commitlint/cli

  2. Configuremos el git hook relacionado.

{
  "scripts": {
    "commitmsg": "commitlint -e $GIT_PARAMS"
  }
}

Y luego, este verificará que el commit tenga el formato necesario para hacer semantic release.

Existen otras herramientas como Commitizen que tienen el mismo objetivo.

Entonces…

Crear releases de nuestros proyectos ayudan a poder saber como el proyecto ha evolucionado y el estado del mismo.

Además de proveer una forma común de describir el tipo de cambio que nuestro proyecto tiene durante el tiempo, e informar a los consumidores del mismo.

·

📚

2 functions that made my components responsive at The practical dev.

From WordPress to static site—the Contentful way at Contentful's blog.

Coders Cut: The conversational article at Typeform's blog.

📹

The journey of a new interface at Frontend Connect.

Jepser Bernardino: Sitios web estáticos con WordPress y React at WordPress.tv.

Jepser Bernardino: Styled components ¿Por qué css en javascript? at WordPress.tv.