Cómo automatizar el control de versiones y los lanzamientos de proyectos con una implementación continua
Tener un software con versiones semánticas le ayudará a mantener y comunicar fácilmente los cambios en su software. Hacer esto no es fácil. Incluso después de fusionar manualmente el PR, etiquetar la confirmación y enviar la versión, aún debe escribir notas de la versión. Hay muchos pasos diferentes y muchos son repetitivos y toman tiempo.
Veamos cómo podemos hacer un flujo más eficiente y automatizar completamente nuestro proceso de lanzamiento mediante el versionado semántico de complementos en un proceso de implementación continua.
Versionado semántico
Una versión semántica es un número que consta de tres números separados por un punto. Por ejemplo, 1.4.10es una versión semántica. Cada uno de los números tiene un significado específico.
cambio mayor
El primer número es un cambio importante, lo que significa que tiene un cambio importante.
cambio menor
El segundo número es un cambio menor, lo que significa que agrega funcionalidad.
Cambio de parche
El tercer número es un cambio de parche, lo que significa que incluye una corrección de errores.
Es más fácil considerar el control de versiones semánticas como Breaking . Feature . Fix. Es una forma más precisa de describir un número de versión que no deja lugar a interpretación.
Formato de confirmación
Para asegurarnos de que estamos lanzando la versión correcta (incrementando correctamente el número de versión semántica) necesitamos estandarizar nuestros mensajes de confirmación. Al tener un formato estandarizado para los mensajes de confirmación, podemos saber cuándo incrementar qué número y generar fácilmente una nota de la versión. Usaremos la convención de mensajes de confirmación de Angular, aunque podemos cambiar esto más adelante si prefieres algo más.
Dice así:
headeroptional bodyoptional footerCada mensaje de confirmación consta de un encabezado , un cuerpo y un pie de página .
El encabezado de confirmación
El encabezado es obligatorio. Tiene un formato especial que incluye un tipo, un alcance opcional y un asunto .
El tipo de encabezado es un campo obligatorio que indica qué impacto tienen los contenidos de la confirmación en la próxima versión. Tiene que ser uno de los siguientes tipos:
- hazaña : nueva característica
- solución : corrección de errores
- docs : Cambio a la documentación.
- estilo : cambios que no afectan el significado del código (por ejemplo, espacios en blanco, formato, punto y coma faltantes, etc.)
- refactor : cambios que no corrigen un error ni agregan una característica
- perf : Cambio que mejora el rendimiento
- prueba : agregue pruebas faltantes o correcciones a las existentes
- tarea : cambios en el proceso de compilación o herramientas y bibliotecas auxiliares, como generar documentación
El alcance es una propiedad de agrupación que especifica con qué subsistema está relacionado el compromiso, como una API, el panel de una aplicación, cuentas de usuario, etc. Si el compromiso modifica más de un subsistema, entonces podemos usar un asterisco ( *). en cambio.
El asunto del encabezado debe contener una breve descripción de lo que se ha hecho. Hay algunas reglas al escribir uno:
- Utilice el imperativo presente (por ejemplo, “cambiar” en lugar de “cambiado” o “cambios”).
- Ponga en minúscula la primera letra de la primera palabra.
- Deja un punto (
.) al final. - Evite escribir temas de más de 80 caracteres. El cuerpo de la confirmación.
Al igual que el asunto del encabezado, use el tiempo presente imperativo para el cuerpo. Debe incluir la motivación para el cambio y contrastarla con el comportamiento anterior.
El pie de página de confirmación
El pie de página debe contener información sobre cambios importantes y también es el lugar para hacer referencia a los problemas que cierra este compromiso.
La información de cambios importantes debe comenzar con BREAKING CHANGE:seguido de un espacio o dos líneas nuevas. El resto del mensaje de confirmación va aquí.
Hacer cumplir un formato de confirmación
Trabajar en equipo siempre es un desafío cuando hay que estandarizar algo a lo que todos deben ajustarse. Para asegurarnos de que todos utilicen el mismo estándar de confirmación, utilizaremos Commitizen.
Commitizen es una herramienta de línea de comandos que facilita el uso de un formato de confirmación consistente. Hacer que un repositorio sea compatible con los compromisos significa que cualquier miembro del equipo puede ejecutarlo git czy recibir un mensaje detallado para completar un mensaje de confirmación.
Generando una versión
Ahora que sabemos que nuestras confirmaciones siguen un estándar consistente, podemos trabajar para generar una versión y notas de la versión. Para ello, utilizaremos un paquete llamado semantic-release. Es un paquete bien mantenido con gran soporte para múltiples plataformas de integración continua (CI).
La liberación semántica es la clave de nuestro viaje, ya que realizará todos los pasos necesarios para una liberación, que incluyen:
- Averiguar la última versión que publicaste
- Determinar el tipo de lanzamiento en función de las confirmaciones agregadas desde el último lanzamiento
- Generar notas de la versión para confirmaciones agregadas desde la última versión.
- Actualizar un
package.jsonarchivo y crear una etiqueta Git que corresponda a la nueva versión de lanzamiento - Impulsando la nueva versión
Cualquier CI servirá. Para este artículo usamos GitHub Action, porque me encanta usar las funciones existentes de una plataforma antes de buscar una solución de terceros.
Hay varias formas de instalar semantic-release, pero usaremos semantic-release-cli ya que proporciona todo paso a paso. Ejecutamos npx semantic-release-cli setupen la terminal y luego completamos el asistente interactivo.
El guión hará un par de cosas:
- Se ejecuta
npm addusercon la información de NPM proporcionada para generar un archivo.npmrc. - Crea un token personal de GitHub.
- Se actualiza
package.json.
Una vez que finalice la CLI, agregará semantic-release a package.jsonpero en realidad no lo instalará. Ejecute npm installpara instalarlo, así como otras dependencias del proyecto.
Lo único que nos queda es configurar el CI a través de GitHub Actions. Necesitamos agregar manualmente un flujo de trabajo que ejecute la liberación semántica. Creemos un flujo de trabajo de lanzamiento en .github/workflows/release.yml.
name: Releaseon: push: branches: - mainjobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run releaseSteffen Brewersdorff ya hace un excelente trabajo cubriendo CI con GitHub Actions, pero repasemos brevemente lo que está sucediendo aquí.
Esto esperará a que mainse produzca el impulso en la rama, solo entonces ejecutará la canalización. Siéntase libre de cambiar esto para que funcione en una, dos o todas las ramas.
on: push: branches: - mainLuego, extrae el repositorio checkoute instala Node para que npm esté disponible para instalar las dependencias del proyecto. Podría realizarse un paso de prueba, si eso es lo que prefieres.
- name: Checkoutuses: actions/checkout@v2- name: Setup Node.jsuses: actions/setup-node@v1with: node-version: 12- name: Install dependenciesrun: npm ci# You can add a test step here# - name: Run Tests# run: npm testFinalmente, deja que la liberación semántica haga toda la magia:
- name: Releaserun: npm run releaseImpulsa los cambios y observa las acciones:
Ahora, cada vez que se realiza (o fusiona) una confirmación en una rama específica, la acción se ejecutará y realizará una versión, completa con notas de la versión.
¡Fiesta de lanzamiento!
¡Hemos creado con éxito un flujo de trabajo de lanzamiento semántico de CI/CD! No es tan doloroso, ¿verdad? La configuración es relativamente simple y no hay inconvenientes en tener un flujo de trabajo de publicación semántica. Solo facilita mucho el seguimiento de los cambios.
semantic-release tiene muchos complementos que pueden realizar automatizaciones aún más avanzadas. Por ejemplo, incluso hay un bot de lanzamiento de Slack que puede publicar en un canal de proyecto una vez que el proyecto se ha implementado con éxito. ¡No es necesario dirigirse a GitHub para buscar actualizaciones!
Deja un comentario