Uso de git tag para marcar lanzamientos

En la lección anterior, aprendimos sobre los fundamentos de las etiquetas en Git. Ahora profundizaremos en cómo utilizar git tag específicamente para marcar lanzamientos (releases) de software y gestionar eficientemente el ciclo de vida de tu producto.

El concepto de lanzamiento en desarrollo de software

Un lanzamiento (release) es una versión específica de tu software que se considera estable y lista para ser utilizada por los usuarios. Los lanzamientos representan hitos importantes en el desarrollo del proyecto y suelen incluir:

• Nuevas funcionalidades
• Correcciones de errores
• Mejoras de rendimiento
• Cambios en la API
• Actualizaciones de seguridad

Marcar estos lanzamientos con etiquetas Git proporciona una forma clara de identificar y acceder a estas versiones específicas del código.

Planificación de lanzamientos

Antes de crear etiquetas para marcar lanzamientos, es importante tener un plan claro:

1. Definir el ciclo de lanzamiento

Establece la frecuencia con la que realizarás lanzamientos:

• Lanzamientos frecuentes: Cada 2-4 semanas (desarrollo ágil)
• Lanzamientos periódicos: Mensual o trimestral
• Lanzamientos basados en características: Cuando se completan ciertas funcionalidades

2. Establecer criterios para lanzamientos

Define qué debe cumplirse antes de crear un lanzamiento:

• Todas las pruebas automatizadas pasan
• Revisión de código completada
• Documentación actualizada
• Problemas críticos resueltos

3. Determinar la estrategia de versionado

Decide cómo numerarás tus versiones:

• Versionado semántico (recomendado): MAYOR.MENOR.PARCHE
• Versionado por fecha: AAAA.MM.DD
• Versionado por iteración: 1.0, 2.0, 3.0

Flujo de trabajo para marcar lanzamientos con git tag

A continuación, se presenta un flujo de trabajo completo para marcar lanzamientos utilizando Git:

1. Preparación para el lanzamiento

# Asegúrate de estar en la rama principal
git checkout main

# Actualiza tu repositorio local
git pull origin main

# Crea una rama de lanzamiento (opcional pero recomendado)
git checkout -b release/v1.0.0

2. Finalización de la preparación

# Actualiza la versión en los archivos del proyecto
# (package.json, VERSION.txt, etc.)

# Actualiza el CHANGELOG.md
# Documenta las nuevas características, correcciones y cambios importantes

# Commit de los cambios de preparación
git add .
git commit -m "Prepara lanzamiento v1.0.0"

3. Pruebas finales

# Ejecuta pruebas completas
npm test  # o el comando equivalente para tu proyecto

# Realiza pruebas manuales si es necesario

4. Fusión con la rama principal

# Vuelve a la rama principal
git checkout main

# Fusiona la rama de lanzamiento
git merge --no-ff release/v1.0.0

# Resuelve conflictos si los hay

5. Creación de la etiqueta de lanzamiento

# Crea una etiqueta anotada para el lanzamiento
git tag -a v1.0.0 -m "Versión 1.0.0

Características principales:
- Nueva funcionalidad X
- Mejora de rendimiento en Y
- Corrección de error Z

Ver CHANGELOG.md para detalles completos."

# Envía la etiqueta al repositorio remoto
git push origin v1.0.0

6. Actualización de la rama de desarrollo (si aplica)

# Si utilizas una rama de desarrollo separada
git checkout develop
git merge --no-ff main

# Envía los cambios
git push origin develop

7. Limpieza

# Elimina la rama de lanzamiento temporal
git branch -d release/v1.0.0

Tipos de lanzamientos y cómo etiquetarlos

Diferentes tipos de lanzamientos pueden requerir diferentes enfoques de etiquetado:

Lanzamientos principales

Para versiones estables y completas:

git tag -a v1.0.0 -m "Lanzamiento estable v1.0.0"

Pre-lanzamientos

Para versiones previas que requieren pruebas adicionales:

# Alpha (desarrollo temprano)
git tag -a v1.0.0-alpha.1 -m "Versión alpha 1 de v1.0.0"

# Beta (características completas pero con posibles errores)
git tag -a v1.0.0-beta.2 -m "Versión beta 2 de v1.0.0"

# Release Candidate (potencialmente estable)
git tag -a v1.0.0-rc.1 -m "Candidato a lanzamiento 1 de v1.0.0"

Parches y hotfixes

Para correcciones rápidas en versiones ya lanzadas:

git tag -a v1.0.1 -m "Parche: corrige error crítico de seguridad"

Lanzamientos de soporte a largo plazo (LTS)

Para versiones que tendrán soporte extendido:

git tag -a v2.0.0-LTS -m "Versión 2.0.0 con soporte a largo plazo"

Integración con plataformas de alojamiento Git

Las etiquetas de lanzamiento se integran perfectamente con las funcionalidades de releases de plataformas como GitHub, GitLab y Bitbucket.

GitHub Releases

1. Crea una etiqueta en Git:

   git tag -a v1.0.0 -m "Versión 1.0.0"
   git push origin v1.0.0
   

2. En GitHub, navega a tu repositorio > Releases > Draft a new release
3. Selecciona la etiqueta que acabas de crear
4. Añade un título y descripción detallada
5. Opcionalmente, adjunta binarios compilados o assets
6. Publica el release

GitLab Releases

1. Crea una etiqueta en Git como se mostró anteriormente
2. En GitLab, navega a tu proyecto > Releases > New release
3. Selecciona la etiqueta existente
4. Completa la información del release
5. Publica el release

Bitbucket Releases

1. Crea una etiqueta en Git como se mostró anteriormente
2. En Bitbucket, navega a tu repositorio > Downloads > Add file
3. Sube los archivos relevantes y asocia la etiqueta

Automatización del proceso de lanzamiento

Usando scripts de shell

Puedes crear scripts para automatizar el proceso de lanzamiento:

#!/bin/bash
# release.sh

# Verificar que se proporciona una versión
if [ -z "$1" ]; then
  echo "Uso: ./release.sh <versión>"
  exit 1
fi

VERSION=$1

# Actualizar archivos de versión
echo "Actualizando archivos de versión a $VERSION"
echo $VERSION > VERSION
# Actualizar otros archivos según sea necesario

# Commit de los cambios
git add .
git commit -m "Prepara lanzamiento $VERSION"

# Crear etiqueta
git tag -a $VERSION -m "Versión $VERSION"

# Enviar cambios y etiqueta
git push origin main
git push origin $VERSION

echo "Lanzamiento $VERSION completado"

Usando GitHub Actions

Puedes automatizar el proceso de lanzamiento con GitHub Actions:

name: Create Release

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
        
      - name: Build project
        run: |
          npm install
          npm run build
          
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false
          
      - name: Upload Release Asset
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./dist/app.zip
          asset_name: app.zip
          asset_content_type: application/zip

Usando herramientas específicas de lenguaje

Muchos ecosistemas tienen herramientas específicas para gestionar lanzamientos:

JavaScript/Node.js

# Incrementa la versión y crea la etiqueta
npm version patch  # o minor, major

# Publica el paquete a npm
npm publish

Python

# Usando poetry
poetry version patch  # o minor, major
git add pyproject.toml
git commit -m "Incrementa versión"
git tag v$(poetry version -s)
git push origin main --tags

# Publica a PyPI
poetry publish --build

Ruby

# Actualiza la versión en version.rb
bundle exec rake release

Estrategias de lanzamiento para diferentes tipos de proyectos

Bibliotecas y frameworks

Para bibliotecas que serán utilizadas por otros desarrolladores:

1. Mantén la compatibilidad hacia atrás cuando sea posible
2. Documenta claramente los cambios incompatibles
3. Proporciona guías de migración entre versiones mayores
4. Considera mantener múltiples ramas de lanzamiento para diferentes versiones

Ejemplo de estructura de ramas:

main (desarrollo de la próxima versión mayor)
1.x (mantenimiento de la serie 1.x)
0.x (soporte limitado para usuarios antiguos)

Aplicaciones web y móviles

Para aplicaciones orientadas al usuario final:

1. Lanzamientos frecuentes con mejoras incrementales
2. Considera lanzamientos graduales (rollouts)
3. Implementa feature flags para habilitar/deshabilitar funcionalidades
4. Mantén un canal beta para pruebas con usuarios reales

Sistemas críticos

Para sistemas donde la estabilidad es crucial:

1. Ciclos de lanzamiento más largos con pruebas exhaustivas
2. Múltiples etapas de pre-lanzamiento (alpha, beta, rc)
3. Procesos de certificación formal antes del lanzamiento
4. Planes de rollback detallados

Comunicación de lanzamientos

Notas de lanzamiento efectivas

Las notas de lanzamiento deben ser claras y útiles:

1. Resumen ejecutivo: Descripción breve de lo más destacado
2. Nuevas características: Detalle de las nuevas funcionalidades
3. Mejoras: Cambios positivos en funcionalidades existentes
4. Correcciones: Errores solucionados
5. Cambios incompatibles: Destacados claramente
6. Problemas conocidos: Transparencia sobre limitaciones
7. Instrucciones de actualización: Pasos para actualizar

Canales de comunicación

Considera anunciar tus lanzamientos en:

• Página web del proyecto
• Blog técnico
• Redes sociales
• Listas de correo
• Comunidades relevantes (Reddit, HackerNews, etc.)
• Dentro de la aplicación (para actualizaciones de apps)

Buenas prácticas para lanzamientos con git tag

1. Etiqueta solo código estable

Asegúrate de que el código que etiquetas como lanzamiento ha pasado por todas las pruebas necesarias.

2. Utiliza mensajes descriptivos en las etiquetas

git tag -a v1.0.0 -m "Versión 1.0.0

Principales cambios:
- Nueva interfaz de usuario
- Mejora de rendimiento en X
- Corrección de errores críticos

Ver CHANGELOG.md para detalles completos."

3. Firma las etiquetas de lanzamiento

Para verificar la autenticidad de los lanzamientos:

git tag -s v1.0.0 -m "Versión 1.0.0 firmada"

4. Nunca modifiques una etiqueta publicada

Si encuentras un problema en un lanzamiento, crea una nueva etiqueta (v1.0.1) en lugar de modificar la existente.

5. Coordina etiquetas con cambios en archivos de versión

Asegúrate de que la versión en tus archivos (package.json, VERSION.txt, etc.) coincida con la etiqueta Git.

6. Documenta el proceso

Crea un documento RELEASING.md que describa el proceso exacto para crear un lanzamiento en tu proyecto.

Solución de problemas comunes

Etiqueta creada en el commit incorrecto

Problema: Has creado una etiqueta de lanzamiento en el commit equivocado.

Solución:

# Elimina la etiqueta local
git tag -d v1.0.0

# Elimina la etiqueta remota si ya la has enviado
git push origin --delete v1.0.0

# Crea la etiqueta en el commit correcto
git tag -a v1.0.0 -m "Versión 1.0.0" commit_hash

# Envía la etiqueta corregida
git push origin v1.0.0

Conflictos entre etiquetas y ramas

Problema: Has creado una rama y una etiqueta con el mismo nombre.

Solución: Evita usar el mismo nombre para ramas y etiquetas. Si ocurre:

# Para referenciar específicamente la etiqueta
git checkout refs/tags/v1.0.0

# Para referenciar específicamente la rama
git checkout refs/heads/v1.0.0

Versiones no sincronizadas

Problema: La versión en los archivos del proyecto no coincide con la etiqueta Git.

Solución: Establece un proceso claro para actualizar ambos al mismo tiempo, idealmente automatizado.

Conclusión

El uso adecuado de git tag para marcar lanzamientos es una práctica fundamental en el desarrollo de software profesional. Proporciona una forma clara de identificar versiones específicas, facilita la colaboración entre equipos y ayuda a los usuarios a entender la evolución de tu proyecto.

Al combinar etiquetas Git con un proceso de lanzamiento bien definido, notas de lanzamiento detalladas y una estrategia de comunicación efectiva, puedes crear un ciclo de vida de producto más transparente y manejable tanto para desarrolladores como para usuarios.

En la próxima lección, exploraremos cómo gestionar versiones en GitHub utilizando la funcionalidad de Releases, que se integra con las etiquetas Git y proporciona características adicionales para la distribución de software.