Ultimamente, en los proyectos en los que participo, por suerte, está teniendo más importancia la figura de DevOps, lo que conlleva a políticas de ramas, despliegues, etc…
O lo que es lo mismo, ya no vale el en mi máquina funciona y, yo, cada día más feliz. Pero el camino no ha sido nada fácil, no lo es, seguimos andando en él. Estas nuevas metodologías no sólo son herramientas, son sobre todo eso, formas de trabajo, metodológicas, con sus procesos.
Algo que a todos los equipos que llevo les cuesta entender de las políticas de ramas y su espejo por tanto en la política de versiones, ¿cuándo algo es un bugfix y cuando algo es un hotfix? Algo que a primera vista o si trabajas con ello, parece sencillo, pero que a muchos equipos de trabajo, sobre todo aquellos que siempre trabajaron con una metodología de entrega final, no quiero encasillar en nombres, pues le cuesta más pensar que en ese proceso de llegar a la entrega, hay versiones y, no sólo las planificadas como entregables, también pueden aparecer demos en el camino y, la idea es poder adaptarnos con agilidad a esos cambios, gestionando en todo momento las expectativas de nuestros clientes, pero sobre todo, de todo el equipo que está realizando el producto. Que a veces, con agilidad, nos olvidamos de las frustraciones internas en pro de que no las haya en el cliente.
Volviendo al tema del hotfix y el bugfix, ¿cuándo mi nueva rama debe de entrar dentro de un ciclo u otro? Esa tremenda decisión hará, por ende, una actuación en las versiones del producto.
Si nos lo llevamos al entorno de la simplicidad nos podemos quedar con que un bugfix es una acción sobre el código fuente en desarrollo actualmente, un cambio en el código o conjunto de cambios para abordar un defecto de la funcionalidad del código que estamos realizando y entregando, para obtener esa versión.
Por el otro lado, un hotfix, lo podemos considerar generalmente como un parche o actualización para una versión dada, es decir, ya entregada y en posesión de los clientes. Llevan un flujo de vida diferente que los caracteriza sobre todo en:
- No son publicados de manera planificada, sino cuando se resuelven.
- Son destinados a abordar situaciones específicas, de nicho, o respuestas de emergencia.
- Relevantes sólo para un problema específico, documentado en las notas de la versión.
Los hotfix, por su naturaleza, son usados normalmente «de emergencia», lo que conlleva a veces saltarse políticas y pueden traer ciertos inconvenientes, por lo que es muy importante, que a pesar de su urgencia, no se salten los «quality gates» que haya definidos, pues podemos crear nuevos errores en caso de que este mal probado.
En resumen, un bugfix o corrección de errores, generalmente lo usamos cuando se encuentra el problema durante la fase de desarrollo y prueba interna. Un hotfix o revisión, generalmente se usa cuando el cliente ha encontrado un problema en la versión actual del producto y, no puede esperar a que se solucione en la siguiente versión del mismo.
Y recuerda el mantra, un bug detectado a tiempo, deja de ser un bug, sino una nueva feature.
Si quieres que te ayude en tu camino sobre el versionado y el ciclo de vida, así como el gobierno del mismo, hazlo a través del siguiente formulario, seguro que encontramos caminos:
lacosarevuelta.es 