Entornos, versiones y ciclos de lanzamiento

Es importante recordar que las actualizaciones no son una tarea agradable para la mayoría de los usuarios. Como equipo, siempre debemos brindar la mayor ayuda posible y tener empatía por los usuarios.

Siempre debemos considerar cuidadosamente las razones detrás de cualquier cambio que hagamos. A veces es mejor para nosotros asumir el dolor que de otro modo infligiríamos a los usuarios. Por ejemplo, a menudo elegimos admitir versiones anteriores de Java aunque nos gustaría usar funciones de lenguaje más nuevas nosotros mismos.

Los lanzamientos de parches deben ser reemplazos directos compatibles con API para los usuarios. Solo deben contener correcciones de errores.

Las versiones menores contienen nuevas características. En general, debería ser posible actualizar desde una versión secundaria anterior sin demasiado esfuerzo, siempre que la versión principal no tenga cambios y no se utilicen métodos obsoletos «Deprecated».

Las versiones principales están reservadas para grandes cambios de última hora. Se espera que los usuarios tengan que trabajar un poco al actualizar las versiones principales. Esto es porque la versión mayor se utiliza para hacer cambios que no son compatibles con el API.

Los calificadores son parámetros opcionales que definen la versión actual. Algunos ejemplos:

Las clases y los métodos en desuso deben anotarse @Deprecated de manera que sea claro que en las próximas versiones ya no estará disponible.

Las nuevas funciones deben apuntar a la próxima versión menor y no deben incluirse en las versiones de parches. Los errores deben dirigirse a la versión compatible más antigua, a menos que sean particularmente riesgosos o difíciles de corregir en una rama más antigua. En algunos casos se puede usar la marca <mayor>-<menor> para dar seguimiento global a una versión, por ejemplo v2.0, v2.3.

Los mensajes de confirmación son una herramienta vital cuando se trata de depurar una regresión. Es natural ser descuidado al crear mensajes de confirmación; sin embargo, cuando se trabaja en equipo y siempre que sea posible conviene usar mensajes descriptivos. Lo recomendable es seguir estas 7 reglas:

Además, casi todos los mensajes de confirmación incluyen una referencia a un problema en el Seguimiento de incidencias o una solicitud de extracción (pull request). Referenciamos problemas usando «See», «Fixes» o «Closes» seguido de #NNNN. Por ejemplo:

Vale la pena leer:

En el monorepo UnoSportClub se complementa con la convención type(scope): subject (ej. feat(accounting): close period with equity check).

Etapa durante la cual se desarrolla la aplicación. El entorno de desarrollo suele estar al alcance directo del desarrollador, posiblemente en su propio equipo o en un servidor en su oficina, ya que el desarrollador debe haber realizado las pruebas de primera mano antes de realizar un despliegue a testing. En algunos casos el desarrollador requiere certificados SSL o conexiones VPN para lograr simular un entorno de producción; en esta etapa podría trabajar con entornos de prueba y datos de relleno, pero estos deben servirse cerca y no desde los servidores de despliegue, o se comprometen los tiempos de desarrollo por asuntos de latencia, velocidad o problemas de disponibilidad de los datos. Lo natural es entregar especificaciones claras de las interfaces de datos que maneja el entorno de ensayo y producción, de manera que pueda crearse una caja de arena (Sandbox) mientras se desarrolla el código fuente.

La etapa de pruebas funcionales y unitarias no es un proceso de prueba física de la aplicación, sino de pruebas técnicas al código, que permita examinar si los parámetros de calidad en relación a cada función que debe hacer el Software se puedan comprobar de forma automática. Esto es porque en el proceso de desarrollo de Software los desarrolladores continuamente están compartiendo cambios y fusionando ramas, lo que requiere en primer lugar que cada solicitud de integración sea revisada exhaustivamente antes de unirla a la rama principal (o de desarrollo; en algunos casos se usan dos ramas principales). Este es un proceso prácticamente automático; por lo tanto no debe requerir ningún tipo de intervención, salvo los cambios escritos por el desarrollador al crear las pruebas funcionales y unitarias.

Es común confundir estas pruebas con pruebas integrales al software ejecutadas por un operador; ese tipo de pruebas corresponden a la etapa de ensayo, ya que las pruebas funcionales corresponden a la edición del código fuente y ejecución en el servidor.

El equipo de desarrollo —quien envía la fuente— y el resto del equipo son los encargados de monitorear esta etapa; no es responsabilidad solamente del desarrollador. Enviar código fuente para ser examinado en el servidor de testing debería ser un paso sencillo. Cabe destacar que es totalmente válido configurar el servidor para hacer el despliegue a la siguiente etapa (staging) o fusionar el código fuente.

En el entorno de ensayo, el equipo de calidad puede realizar una revisión de las funcionalidades que están pendientes y que no están registradas en el control de incidencias, y añadir una a una al control de incidencias, que es la herramienta adecuada para garantizar que los objetivos se cumplan. Cabe destacar que el flujo de la aplicación a través de los entornos no incrementa la versión en ninguna manera excepto cuando la aplicación pasa de la etapa de ensayo a producción.

Es el equipo de Calidad quien determina cuándo una versión está terminada y prosigue a iniciar el ciclo de lanzamiento de la versión actual o a continuarlo en caso de que ya esté iniciado previamente. Entendemos que una misma versión tiene varios lanzamientos, y no se crea la etiqueta tag hasta que la versión está terminada. Los tags no se modifican: determinan un estado constante del código fuente que los compone. En este sentido, los tags son para versiones cerradas de modificaciones y las ramas para versiones abiertas a modificaciones, conforme al principio Open/Closed que forma parte de los principios SOLID de Robert C. Martin.

La etapa inicial de la versión debe tener todas las características del requerimiento del cliente; incluye todo lo que se necesita para funcionar, es lo que se espera. Sin embargo todavía debe someterse a una serie de pruebas exhaustivas que determinan cuáles cambios deben hacerse para alcanzar con exactitud el requerimiento del cliente, y en especial para resolver los problemas planteados en la primera exploración de las necesidades del proyecto.

Esta etapa de la versión procura hacer una exploración profunda de la aplicación para conocer posibles fallas, repararlas y corregir alguna que su uso pueda ocasionar en los datos. Es una aplicación que bien se puede usar como definitiva; será liberada de responsabilidad ya que encontrar errores en ella es lo que se espera. Etapa imprescindible para alcanzar el máximo nivel de calidad.

Esta etapa de la versión es prácticamente el producto terminado, listo para usarse; sin embargo se mantiene bajo estricta observación. Debe estar funcionando correctamente en todo sentido, atentos a recuperar todos los datos necesarios para mejorar la aplicación.

Esta etapa de la versión se alcanza cuando se entiende por terminada la aplicación, lista para usar y puesta en marcha definitiva al público en producción.

Una vez puesta en marcha la etapa anterior, y una vez que comienza a usarse sin que su implementación falle, se considerará una versión estable. Servirá para definir las características que se añadirán en la etapa alfa de la siguiente versión.