¿Qué es un Release en GitHub?
En GitHub podemos empaquetar software, en donde podemos incluir archivos binarios y notas para indicar a la gente como usarlo, esto es fundamental en el proceso de software, ya nuestro principal objetivo como desarrolladores es construir software que sea desplegable en cada una de las iteraciones y ponerlo disponible al negocio para que lo use.
Básicamente los Release en GitHub usan tags, los cuales marca un punto en específico de la historia de tu repositorio, entonces te preguntaras, como creo un tag asociado a un commit en GitHub, pues lo veremos a continuación.
Entendiendo como gestionar los Releases en el Gitflow
Si usamos la estrategia de branching de gitflow, estaremos familiarizados de como integrar el concepto de Release al momento de liberar código. Dentro del proceso de desarrollo existen distintos momentos en los cuales podemos generar un nuevo Release:
- Cuando liberamos un nuevo producto (lo generamos a partir de la rama master/main).
- Cuando generamos una corrección que es compatible con versiones anteriores (el cual se genera a través de una rama hotfix).
- Cuando agregaremos una nueva funcionalidad compatible con versiones anteriores, donde trabajamos en una rama de tipo feature.
- Cuando agregamos funciones que no necesariamente son compatibles con versiones anteriores, a partir de una rama Release para aislar el código base de un nuevo Release.
Una de las practicas más usadas para determinar que funcionalidad usaremos en cada commit es el Cherry pick, este tema lo abordaremos en artículos subsecuentes.
¿Como distinguimos de un Release a otro?, a través de tags. Un tag expresa una versión en particular y la siguiente tabla expresa de forma adecuada como ir asignando la nomenclatura de forma correcta.
El ejemplo que vamos a revisar está basado en este repo de GitHub, el cual puedes crear una copia usando el template que está disponible (no olvides dar check en incluir todas las ramas).
Creación de nuestro primer Release no productivos
Existen casos en los cuales necesitamos crear pre-releases para exponer funcionalidades de forma anticipada y tener feedback de nuestros usuarios; para esto vamos al repositorio, en el panel lateral derecho se puede observar la sección de Releases, vamos a dar clic en “Create a new Release”.
Es aquí donde vamos a crearlo siguiendo los siguientes pasos:
- Establecer el tag, si no existe lo creamos.
- Especificamos la rama, en este punto es importante solo seleccionar ramas que estén protegidas y que puedan gestionar de forma adecuada una versión del nuestros aplicativos.
- Especificamos el título del Release
- En caso de usar la información de los Pull Request a estas ramas para describir el Release damos clic en el botón de “Generate Release Notes”
- Escribimos/editamos la descripción del Release
- En este caso no vamos a agregar binarios, sin embargo, puedes agregarlos en la sección de “attach binaries”
- En caso de ser un pre-release activamos la casilla “This is a pre-relase”
- Damos clic en “Publish release”
Tenemos ya nuestro primer pre-release, algo interesante que podemos ver es que tenemos acceso directo al código fuente, el commit relacionado y el tag correspondiente.
Para cada nuevo Release es recomendable crear una rama por Release y protegerlas con “Branch policies”; sin embargo, esto no limita que uses otras estrategias de ramas que se adecuen mejor a tu proceso de desarrollo.
Protección de ramas
Como mencionaba anteriormente uno de los principales mecanismos para resguardar el código que es susceptible a ser desplegado en la nuble, es crear reglas de protección de ramas para esto vamos a al sitio de GitHub, en el repositorio damos clic en “Settings”, posteriormente en el panel lateral izquierdo en la sección de “Code and automation” damos clic en “Branches”, y en la sección de “Branch protection rules” damos clic en el botón “add branch protection rule”
Procedemos a especificar la rama que protegeremos en el campo de “Branch name pattern” en nuestro caso es main; posteriormente activamos las siguientes opciones:
- “Require a Pull Request before merging”, con el objetivo de integrar solamente un cambio a esa rama a través de un Pull Request.
- “Require approval”, para que alguien revise los cambios a ser integrados en la rama protegida.
- “Require conversation resolution before merging”, en caso de que el revisor realice algún comentario/observación el cambio no se integre hasta que sea resuelto.
Damos clic en el botón de “Create”.
Hacemos lo mismo ahora para proteger todas las ramas de release, para esto en el Branch name pattern “release/*”
Creación de un Release por nuevo feature
El escenario que veremos a continuación es cuando necesitamos integrar un nuevo feature a nuestra solución, para esto creamos una nueva rama, donde actualizaremos una hoja de estilo, para esto vamos a la sección de “code”, en la rama main tecleamos el nombre nuestra rama “feature-css-update” y vamos a dar clic en “Create branch: feature-css-update from ‘main’”.
Vamos al archivo “base.css” y realizamos la modificación en el elemento “body -> background-color: black” y damos clic en “commit”.
Ahora vamos a generar un pull Request para integrar nuestros cambios a la rama de “release/release-v1.0”, vamos a la sección de “Pull Request”, después damos clic en “New Pull Request”, seleccionamos la rama base en este caso “release/release-v1.0” y en la rama a comparar “feature-css-update”, agregamos el titulo y la descripción de los cambios que integraremos a través del Pull Request. Damos clic en “Create pull Request”
Aprobamos el Pull Request y le damos clic en “Merge Pull Request”.
Una vez integrados los cambios procedemos a eliminar la rama, damos clic en “Delete Branch”
Ahora que ya tenemos nuestros cambios en la rama release, en un proceso de desarrollo real podría desplegarse en algún ambiente intermedio, y una vez realizadas pruebas de diversa índole (carga, aceptación, integración, etc.), seguiría su integración en la rama productiva.
Vamos a crear un pull Request de la rama de release a la rama main. Damos clic en la sección de “Pull Request”, después damos clic en “New Pull Request”, seleccionamos la rama base en este caso “main” y en la rama a comparar “release/release-v1.0”, agregamos el titulo y la descripción de los cambios que integraremos a través del Pull Request y damos clic en “Create pull Request”
Aprobamos el Pull Request y le damos clic en “Merge pull Request”.
Ahora que ya tenemos nuestros cambios en la rama main, vamos a crear el release de la versión 1.0.0; para esto regresamos a la sección de “Code”, “Releases” una vez que ya estamos ahí damos clic en el botón “Draft a new release”.
Creamos un nuevo draft release y especificamos la siguiente información:
- Establecemos el tag en V1.0.0
- Especificamos la rama “release/release v1”
- Especificamos el título del Release que este caso es V1.0.0
- Clic en el botón de “Generate Release Notes”
- Escribimos/editamos la descripción del Release
- Damos clic en “Save Draft”
Ahora como guardamos el Release solo como un draft, podemos editarlo, vamos la sección de Release, en el Release que queremos editar damos clic en el botón de editar en la parte superior derecha. Ya estando en el formulario, cambiamos la rama objetivo a main y le damos clic en “Publish release”
Ya se encuentra asociada la rama main con la etiqueta de forma correcta.
Creación de un Release por Hotfix
En el caso de que se realice un hotfix creamos una rama independiente llamada “hotfix-v1.0.1”, hacemos la corrección, commit y la integramos a la rama main a través de un Pull Request.
Ahora que ya está integrado podemos crear nuestro Release, especificamos la siguiente información:
- Establecemos el tag en V1.0.1
- Especificamos la rama “main”
- Especificamos el título del Release que este caso es V1.0.1
- Clic en el botón de “Generate Release Notes”
- Escribimos/editamos la descripción del Release
- Damos clic en “Publish Release”
Ahora podemos visualizar nuestro nuevo Release resultado de un hotfix.
Comparación de Releases
Uno de los puntos importantes es el de comparar los Release para determinar los cambios que hay entre una y otra. Para esto podemos ir al Release del cual queremos iniciar la comparación, dar clic en el botón de compare y seleccionar el tag objetivo.
Esto nos muestras los commits adicionales que se integran diferentes con la posibilidad de visualizar los archivos y contribuidores.
Esto fue todo por hoy espero que te haya gustado este articulo y te sea de mucha utilidad, puedes ver más contenido que estaré generando en este medio.
¡Saludos y disfruta estar en la nube!