Proceso de Versionado
Este documento describe el proceso de versionado que usamos en nuestro repositorio de GitHub. Usamos un flujo de trabajo de tres ramas: dev, candidate y release. Este proceso garantiza que todas las nuevas características y correcciones sean probadas exhaustivamente antes del lanzamiento.
Rama Dev
Sección titulada «Rama Dev»La rama dev es la rama principal para el desarrollo continuo. Todas las nuevas características, correcciones de errores y mejoras se fusionan en esta rama. Esta es la rama más activa, y es donde los desarrolladores deben basar su trabajo.
Para contribuir a la rama dev, siga estos pasos:
- Haga un fork del repositorio en su propia cuenta de GitHub.
- Clone el repositorio bifurcado en su máquina local.
- Cree una nueva rama para su característica o corrección de errores.
- Realice sus cambios y haga commit en su rama.
- Haga push de su rama a su repositorio bifurcado en GitHub.
- Cree un pull request desde su rama a la rama dev en el repositorio principal.
Los mantenedores de código revisarán su pull request y proporcionarán retroalimentación. Una vez que el código sea aprobado, se fusionará en la rama dev.
Ramas Candidate
Sección titulada «Ramas Candidate»Una vez que las características en la rama dev están listas para pruebas, se fusionan en una rama candidate. Esta rama sirve como área de preparación para el código que está casi listo para su lanzamiento.
El código en la rama candidate se prueba exhaustivamente. Los errores o problemas encontrados se corrigen en la rama dev y luego se fusionan de vuelta en la rama candidate.
La rama candidate normalmente está en esta fase de pruebas durante aproximadamente 2 semanas. Sin embargo, este período puede ser más largo o más corto, dependiendo de la urgencia de las correcciones o del tamaño de las nuevas características.
- Cree una nueva rama
candidatedesdedev. - Cree un PR desde la rama
candidatea la ramareleasecon un nombre como “Proposed.” - Actualice la “Descripción General de Alto Nivel del Cambio” para incluir los Pull Requests de
candidate. Actualice el “Contexto del Cambio” para incluir cualquier nota adicional sobre los PRs.
Rama Release
Sección titulada «Rama Release»Una vez que el código en la rama candidate ha sido probado exhaustivamente y todos los problemas han sido abordados, se fusiona en la rama release. Este es el paso final antes de que se lance el código.
La rama release contiene el código que está actualmente en producción o está a punto de ser lanzado. Solo el código completamente probado y estable debe estar en esta rama.
Una vez que el código está en la rama release, se etiqueta con un número de versión. Este número de versión se usa para rastrear el lanzamiento y también se usa al crear notas de versión.
En la rama release, se construye y publica un binario en https://build.xahau.tech/. Este binario es el producto final que se entrega a los usuarios finales.
Para lanzar el código, siga estos pasos:
- Fusione el pull request
candidateen la rama release. - Elimine la rama
candidate.
Resumen
Sección titulada «Resumen»Este flujo de trabajo de tres ramas garantiza que todo el código sea probado exhaustivamente antes del lanzamiento. Nos permite detectar y corregir problemas antes de que lleguen a producción, y proporciona un camino claro para mover el código desde el desarrollo hasta el lanzamiento. El uso de una LAN personalizada para pruebas y métricas de perfilado garantiza que nuestro código no solo sea funcional sino también eficiente y con buen rendimiento.