Estrategia_Versionamiento_2024_Semana6 - CaviedesGitHub/MiProyectoFinal GitHub Wiki

Flujo de Trabajo y Sistema de Versionamiento

Después de un debate interno, voy a seguir utilizando la estrategia de versionamiento basado en troncal. Estuve pensando cambiar a Github Flow que tiene bastante en común con mi estrategia inicial ya que convergen en apoyar la integración continua y el despliegue a producción rápido. Sin embargo, el hecho de utilizar obligatoriamente una rama temporal para cada feature o cambio y luego esperar la aprobación de un pull request para llevar el código a la rama principal me genera una carga metodológica que en mi situación de trabajo individual no me favorece. De todas maneras, mi estrategia, la troncal, me permite si quiero crear una rama temporal para una feature ocasionalmente.

Trunk-based development
Trunk-based development

Teniendo en cuenta que el control de versiones es 90% proceso y 10% la herramienta, es decir, las políticas y procedimientos que establezca el grupo para organizar y sincronizar su trabajo son más importantes que el dominio técnico de la herramienta que utilicemos, en este proyecto se va a seguir las siguientes:

LOS REPOSITORIOS
Se va a utilizar un repositorio remoto central para el producto y un repositorio local para el programador. Hay que tener en cuenta que tengo varios productos (microservicios) y que por cada microservicio hay un repositorio central remoto en el servicio amazon CodeCommit y un repositorio local.

LAS RAMAS

Ramas permanentes

Rama Master. Es la única rama permanente, todo commit que llegue a esta rama lo va a tomar un proceso de integración y despliegue continuo, en este caso una canalización del servicio Amazon CodePipeline, y lo desplegara en el entorno respectivo de la aplicación ABC Jobs alojada en el servicio ElasticBeanstalk de Amazon. El hecho de que todo commit vaya directamente a producción hace que el proceso de ejecución de pruebas sea muy importante, este debe ser estricto y solo dejar pasar a despliegue los commits que cumplan con todas las pruebas y ademas con un alta cobertura del código probado.

Ramas Temporales

Ramas Feature. Esta rama las creare ocasionalmente, cuando crea que sea conveniente u oportuno. En esta rama se pueden desarrollar nuevas características o hacer cambios. Los cambios se hacen en los repositorios locales y frecuentemente se sincronizan los cambios con la rama feature del repositorio central. Aquí podría tener un paso intermedio con la espera de una aprobación de un pull request, que me podría servir para revisar el trabajo por ultima vez antes de enviarlo a master. Tengo que recordar que la filosofía de la estrategia basada en troncales es minimizar el tiempo que demoramos para hacer commit a la rama principal. Por eso se aconseja cambios pequeños y frecuentes y no demorar mucho tiempo en una rama temporal.

Ramas HotFixes. Se crean cuando se encuentran errores en producción y deben ser solucionados rápidamente. Los cambios se hacen en los repositorios locales y frecuentemente se sincronizan los cambios con la rama hotfix del repositorio central. Una vez que los cambios están listos para ser desplegados se solicita un pull request a la rama master para que los cambios sean verificados y aprobados antes de la integración. repito, me sirve para una ultima verificación de mi trabajo.

ESTRATEGIA CUANDO HAY UN DESPLIEGUE FALLIDO
Si hay un error en la versión de la aplicación desplegada y necesitamos retirarla o volver a una versión anterior, Elasticbeanstalk me da la posibilidad de hacerlo manualmente con la configuración que tiene en estos momentos. Como no estoy utilizando despliegues avanzados(por ejemplo, Blue-green), ni utilizando varias maquinas por servicio, por el momento, no puedo hacerlo automático. A continuación una imagen del servicio Elasticbeanstalk donde me permite hacer esto:

Version Anterior
Version Anterior

AMBIENTES
El software esta configurado para usar 5 ambientes, inicialmente pensé en tres ambientes: de desarrollo local, de pre producción y de producción. Pero debido a la carga operativa demasiado alta para tener otro ambiente el de preproduccion no sera usado. Cuando el proyecto de compilación ejecuta las pruebas, los microservicios están configurados para utilizar una base de datos distinta para pruebas.

BUENAS PRACTICAS CONTROL DE VERSIONES

En lo posible es deseable tener estas prácticas en el proyecto:

  1. No solo el código se versiona. Es conveniente versionar otros artefactos que hacen parte del producto del software como scripts de base de datos, el documento de pruebas, datos de pruebas, archivos de configuración, etc.
  2. Mensajes de commit con significado. Escribir mensajes en los commits que sean útiles para revisar la historia de los cambios y para propósitos de depuración del código puede ahorrar horas de trabajo al equipo.
  3. Cada commit tiene solo un propósito. Todo commit debe tener un propósito: corregir un error, agregar una funcionalidad, realizar una mejora, etc.
  4. Integre frecuentemente los cambios de otros. Antes de iniciar una modificación en su copia local, actualícela con la ultima versión publicada con el repositorio compartido.
  5. Comparta sus cambios frecuentemente. Una vez finalice cambios de un propósito específico, comparta sus cambios con los demás miembros del equipo haciendo push al repositorio compartido.
  6. No romper el build de otros. Al actualizar con sus cambios ramas compartidas con otros, garantice que la versión publicada compila y se ejecuta correctamente.
  7. Mantener una bitácora de cambios. Mantener un archivo que registra los cambios de una versión a otra.
  8. Versionado semántico. Nombrar bajo algún estándar las diferentes versiones del producto.
  9. Política para el manejo de ramas. Si utiliza ramas establezca políticas para su nombramiento, creación, integración y cierre.

Las practicas 4, 5 y 6 son para un equipo, pero es bueno saberlas.

SISTEMA DE VERSIONAMIENTO

En este proyecto voy a utilizar el sistema de versionado semántico. En este momento mi aplicación esta en la versión 0.3.0 porque la Api todavía no es estable, sin embargo para cuando finalice el sprint 1, va a pasar a la version 1.0.0. A continuacion un resumen:

VERSIONADO SEMANTICO

Para lanzar nuevas versiones de este proyecto de forma fácil y segura, evitando el infierno de las dependencias utilizaremos el sistema de versionado semántico. El cual se resume así:

Dado un número de versión MAYOR.MENOR.PARCHE, se incrementa:

La versión MAYOR cuando realizas un cambio incompatible en el API, La versión MENOR cuando añades funcionalidad compatible con versiones anteriores, y La versión PARCHE cuando reparas errores compatibles con versiones anteriores.

Y los primeros pasos de su especificación son:

  1. El Software que usa Versionado Semántico DEBE declarar un API público. Este API puede ser declarado en el propio código o debe existir estrictamente en la documentación. Sin importar como sea realizado, este DEBERÍA ser preciso y comprehensivo.

  2. Un número de versión normal DEBE tener la forma de X.Y.Z donde X, Y y Z son números enteros no negativos, y NO DEBEN ser precedidos de ceros. X es la versión mayor, Y es la versión menor, y Z es la versión parche. Cada elemento DEBE incrementarse numéricamente. Por ejemplo: 1.9.0 -> 1.10.0 -> 1.11.0

  3. Una vez que el paquete versionado ha sido publicado, el contenido de esa versión NO DEBE ser modificado. Cualquier modificación DEBE ser publicada como una nueva versión.

  4. Una versión mayor en cero (0.y.z) se considera como desarrollo inicial. Todo PUEDE cambiar en cualquier momento. El API público NO DEBERÍA ser considerado estable.

  5. La versión 1.0.0 define el API público. La manera en que cada número de versión es incrementado después de esta publicación dependerá de su API público y cómo cambia.

  6. La versión parche Z (x.y.Z x > 0) DEBE ser incrementada si solamente se introducen correcciones de errores compatibles con versiones anteriores. Una corrección de error se define como un cambio interno que corrige un comportamiento incorrecto

  7. La versión menor Y (x.Y.z x > 0) DEBE ser incrementada si se introduce funcionalidad nueva y compatible con la versión anterior del API público. Ésta DEBE ser incrementada si se introduce cualquier funcionalidad al API público o mejora al código privado. Este PUEDE incluir cambios a nivel de parches. La versión parche DEBE reiniciarse a 0 cuando una versión menor se incrementa.

  8. La versión mayor (X.y.z X > 0) DEBE ser incrementada solamente si se introducen cambios incompatibles con la versión anterior del API público. Este PUEDE incluir cambios de nivel menor y parches. Versiones parche y menores DEBEN ser reiniciadas a 0 cuando una versión mayor es incrementada.

Releases