Aprendiendo a versionar software

Tengo el enorme privilegio de ser ingeniero de software de una de las compañías más grandes de tecnología del planeta. Estoy seguro que todo desarrollador de software quisiera trabajar en una compañía así de grande como Google, Facebook o Microsoft. Se trata de trabajar para el nivel más alto, ojo, no creo que el más exigente, he visto compañías pequeñas e incluso equipos de cuatro personas que hacen cosas maravillosas.

En el mundo del software no se trata de tener a un ejército de desarrolladores o un grupo de cuatro personas en la cochera trabajando. Para mi gusto después de toda esta experiencia hay prácticas que he aprendido en todo nivel.

He visto que nadie hace las cosas tan mal como para no aprender nada y nadie hace las cosas tan bien como para no mejorar.

Por ello en este artículo quiero compartirte cuál es la manera más adecuada de versionar software. Si, ponerle esos numeritos que al principio a nadie nos importa y que con un poco más de experiencia lo son todo. ¿Por qué lo digo? Fácil, con solo conocer una versión puedes conocer muchísimas cosas, algunas de ellas son las siguientes.

• Conocer el nivel de compromiso que se tiene en ese producto.
• Saber si se trata de una versión estable y lista para producción o de algo que puede ser para pruebas.
• Permite conocer de manera muy certera los avances tanto pequeños como amplios de ese producto, hay muchas veces en que un avance menor es mucho más importante que una nueva versión completa.

¿Cómo debo versionar mi software?

Esta pregunta es fácil, de hecho hay muchísima documentación al respecto. La inmensa mayoría de ello te redireccionará a https://semver.org/. Donde verás en una forma mucho menos gráfica y muchísimo más detallada algo como esto.

Hasta aquí es fácil, solo determinas que tipo de lanzamiento quieres hacer y listo, asignas el valor de acuerdo a ello. La cuestión es ahora, saber que significa sacar una nueva versión, un parche o algo en un punto medio. Es por ello que podría ser necesario saber que casos cubren al númerito indicado.

Las reglas que he notado que son más seguidas y más importante, las que los equipos no suelen olvidar son las siguientes.

Los PARCHES (x.y.0) deben tratarse de correcciones internas a bugs que hayan surgido durante la iteración previa y estén causando un comportamiento no esperado o deseado en el software. En otras palabras, solo se trata de corregir algo que no cambie funcionalidad pero que corriga una no esperada.

Las versiones MENORES (x.0.z) será incrementado cuando alguna funcionalidad del producto ha sido desplazada. Puede ser incrementada cuando se establezca nueva funcionalidad interna y puede incluir la lista de cambios en los bugs. Cada vez que una nueva versión menor surga, el contador de parches debe ser reseteado a cero.

Las versiones MAYORES (0.y.z) surgen cuando se haya creado cualquier cantidad de cambios que resulten incompatibles con la versión anterior. Una versión mayor puede incluir una colección de cambios basados en versiones menores o parches y con una versión mayor los contadores de versiones menores y parches deben ser regresados a cero.

Nota con estas premisas que los contadores no deben tener una relación de dependencia entre ellos para contabilizar los cambios. Esto quiere decir que puedes tener en una sola versión la cantidad de parches que tú quieras, que en una versión menor puedes contar muchísimos cambios acumulados y que una versión mayor podría pensarse como un producto casi nuevo nacido de las bases que el anterior colocó.

Herramientas de versiones

Versionar software es ocasionalmente una tarea complicada y ligeramente tediosa, en muchos casos se trata de algo que descuidamos por el simple hecho no lidiar con una tarea más y menos si «no es algo importante».

Para poder cumplir con esta tarea y trabajar con un versionamiento adecuado te puedo recomendar que le des un vistazo a GitVersion. Una herramienta que te permitirá controlar las versiones de tu producto de manera eficiente.

Conclusión

Implementar un sistema de versionado de software te dará no solo una gran disciplina para trabajar con tus productos sino que demostrará el profesionalismo del equipo que trabajó en ese producto. Además, con todo esto podrás obtenter cinco grandes cosas en particular.

• Tendrás gran comunicación con tus usuarios/clientes
• Podrás establecer un calendario de lanzamientos periódicos (soy muy fan de como Canonical hace eso con Ubuntu).
• Tendrás consistencia y podrás ser predecible con tus lanzamientos, además de darle seguridad a tus usuarios.
• Podrás ser más transparente en los cambios realizados.
• Lo más importante podrás tener RETROALIMENTACIÓN de tus usuarios, clientes y comunidades. No importa cuántas ideas maravillosas podrá tener todo el equipo, habrá siempre alguien más con grandes sugerencias para mejorar a tu producto.

Espero que con este artículo pueda ayudarte a fomentar una mejor cultura de versionamiento y me dejes en los comentarios tu opinión.