Política de versionado ejemplos y tips

¿Qué es una política? Introducción

Antes que nada, cuando hablamos de políticas o de una política, estamos queriendo significar un conjunto de reglas que gobierna el objeto al que se hace referencia. Así podemos hablar de políticas de nombres, de versionado, políticas organizacionales, etc. En definitiva son reglas de negocio, pero restringido a un ámbito o temática. Otra vez, al hablar de política de versionado estamos hablando de reglas de negocio de versionado.

Las políticas ayudan y guían tus acciones y decisiones dentro de la organización respecto de la temática que tratan.

La política de empresa es un conjunto de normas o reglas establecidas por la dirección de la misma para regular diferentes apartados del funcionamiento de la empresa. 

En algunos ámbitos la política se define como el criterio o directriz de acción elegida como guía en el proceso de toma de decisiones al poner en práctica o ejecutar las estrategias, programas y proyectos específicos del nivel institucional. Siendo así la política empresarial define previamente como quiere hacer las cosas la organización, en otras palabras se diría coloquialmente: "En esta empresa se hacen las cosas de esta manera", y no importa si la empresa es del mismo rubro, del mismo sector o subsector de mercado, sus políticas pueden ser diversas. 

Politicas de versionado

La política de versionado de un producto determinado (o todos en general) deberá estar formada por un conjunto de reglas que provean a la versión del producto de cierta consistencia e integridad, no dejando fisuras en las que permeen problemas asociados con el versionado.

Podemos hablar a diferentes niveles, así por ejemplo podemos hacer referencia a políticas que afectan de las versiones de productos de software, productos de trabajo, de archivos, etc.

Veamos un ejemplo

Especificaciones de formato de versión 1.0 para el versionado de productos de software de nuestra organización.

V<nro_producto>.<nro-funcional>.<nro-correccion>.<nro-recompilacion>

...

Políticas de versionado dentro de nuestra organización.

1. Cada producto de software utiliza como estructura de versión, la especificación de versión 1.0 para el versionado de productos de software, a partir de 01 de marzo del 2014.
2. Cada nuevo producto se inicia con un número secuencial creciente que comienza con el 1, la primera vez. La asignación es realizada por el Área de ventas. 
3. Cada vez que se crea un producto, todas los secciones de la especificación de versión serán 0, excepto el correspondiente al número del producto. El número de producto se incrementa en uno respecto del último número usado.
4. Cada vez que un producto atiende una solicitud de cambio que agrega, modifica o quita funcionalidad se incrementa en un dígito la sección correspondiente a funcionalidad. A partir de esta sección el resto de las secciones que le continúan se inicializan en 0.
5. Cada vez que se corrige un error, la sección correspondiente a corrección se incrementa en un dígito. El resto de las secciones que le continúan se inicializan en 0.
6. Cada vez que el código se compila, este incrementa en 1 dígito la compilación. Si es la primera compilación. Se pone 0.
7. Independientemente de la cantidad o el tamaño de la funcionalidad siempre se incrementa en 1.
8. De cada versión de producto entregada se guarda una linea base.
9. Se debe especificar para cada versión cual es el corrección y se debe especificar que funcionalidad se agrega, cambia o quita. No se específica porque se compila en forma obligatoria.
10. Gerencia es el sector de la organización que determina la discontinuidad de un producto y su correspondiente congelamiento de versión. A partir de esta decisión el producto de software no evolucionará y tampoco se comercializará.

Tips para la definición de reglas de una política de versionado

1. Cada regla debe ser independiente. Cada regla debe entenderse por si misma.
2. Cada regla tiene un identificador.
3. Preste atención a no poner politicas por que si.
4. Tenga en cuenta de explicitar los valores de las secciones cuyos valores dependen de otras secciones. Ejemplo regla 5
5. Realice “mentalmente” un ciclo de vida de cada sección o grupo de secciones, es decir, evalúe cuando nace, como evoluciona y si puede caducar, agotarse  o volverse obsoleta una sección.
6. Se pragmático y no consuma horas de discusión en cosas que no ocurrirán en el largo plazo, sus políticas se ajustaron en el mediano plazo por otros elementos no tenidos en cuenta. 
7. Las políticas se versionan.
8. Las políticas se auditan.
9. No sea purista, es probable que las políticas contengan elementos que no sean reglas de negocio estrictas, si aportan valor y no generan confusión déjelos