Hacer release frontend
Fácil, se hace desde Jenkins.
La forma de trabajo es la misma de siempre, trabajamos en los branches y eventualmente pasamos los MR a staging.
Una vez que querramos pasar a producción, hacemos el release para cambiar la versión en staging desde Jenkins. Para eso vamos al job release y seleccionamos "Build with parameters".
La opción "Dry run" permite hacer una prueba en seco de cómo sería el release pero sin cambiar nada.
El incremento se usa para saber a qué versión cambiar usando semantic versioning.
Por ejemplo, si la versión actual es 1.0.2, veamos las opciones posibles:
- si el incremento es
patch, la nueva versión será1.0.3; - si el incremento es
minor, nos iremos a la versión1.1.0; - por último, si elegimos
major, será2.0.0.
Usar la opción pertinente para cada caso.
Para más información ver SEMVER.
El release lo que hace es:
- cambiar la versión en el
package.json - hacer un commit con el cambio
- hacer un tag en Gitlab de ese commit
Como se hace un commit se dispara el job de staging y es el que efectivamente cambia la versión que se muestra en el frontend:
