Patrones en Gestión de Configuraciones Software (V)

Regression Test

En esta ocasión, el problema a plantear es cómo conocer si el código en un momento determinado durante el desarrollo no habrá empeorado desde los últimos cambios mientras se realizaban otras tareas. La solución pasa por utilizar otros test complementarios a los Smoke Test que tengan otras características diferentes. ¿Cómo son estas pruebas a realizar? ¿Qué politica seguir para su utilización?

Un problema que surge una vez podría darse más veces. Esto es lo que llamamos regresión. Con esta premisa construiremos unos test que tratarán de asegurar estabilidad en el desarrollo: antes de cada release, antes de un cambio particularmente arriesgado, realizaremos unas pruebas que nos permitan tener un cierto nivel de seguridad de que no hemos desandado parte del camino. Estos test se generarán a partir de cambios que ocurrieron en el pasado: hitos, funcionalidades especiales, etc. Se trata de unos test de caja negra que pueden no identificar qué es lo que falla, con lo cual necesitaremos apoyarnos en otros tipos de test, como por ejemplo los unitarios. Son de grano grueso porque prueban funcionalidades completas, comprueban la integración entre diferentes partes, etc.

Los casos que componen estos test pueden ser antiguos fallos detectados por estos mismos test, fallos informados por clientes, fallos detectados por otros tipos de pruebas… Al final habrá un gran número de casos, que nos ayudarán a comprobar que el sistema avanza. Si el sistemas no pasa las pruebas habrá ocurrido una regresión. Nunca se eliminan casos de prueba de este tipo, porque los errores pueden volver. Debido a su tamaño, estos test podrían ejecutarse por la noche, que suele ser cuando menos carga de trabajo se da. Si es posible ejecutarlos en cada operación de protección o check-in (lo cual es complicado debido al tamaño que van adquiriendo  estos test) podremos ver exactamente el punto en el cual el sistema retrocede.

Private Versions

¿Cómo evaluar un cambio complejo, beneficiándose del control de versiones, sin hacer ese cambio público? Pongámonos en el caso de querer probar un cambio localmente, sin correr el riesgo de romper el sistema global. Para ello, podemos establecer checkpoints en ciertos períodos del camino de tal cambio. Recordar que cuando se sube un cambio al control de versiones, el resto de ítems asimila tal cambio al actualizar sus propias revisiones para formar nuevas versiones. Por tanto, es necesario proveer un mecanismo para hacer checkpoints de cambios con la granularidad adecuada que el desarrollador estime conveniente. Esto podría proveerlo un área local de control de revisiones. Sólo los cambios estables van a parar al control de versiones público. Este sistema debería proveer también de un modo de integración para esos cambios inestables con el estado actual del proyecto. El funcionamiento de este área local funcionará como el control de versiones: una vez estabilizados los cambios, éstos se integran en la línea principal del proyecto siguiendo las políticas adecuadas.

Puede utilizarse, para esto, un repositorio local, una rama privada para el desarrollador en cuestión, etc. Algunas herramientas software de gestión de configuraciones proveen mecanismos para esto mediante, por ejemplo, sistemas de permisos del estilo de ACLs (Access Control List o listas de control de acceso, que vigilan el acceso a determinado elementos de un todo; en este caso, artefactos generados en un proyecto y gestionados por el control de versiones). Lo importante es que el programador pueda trabajar cómodamente subiendo los cambios cuando él considere apropiado, sin entorpecer el trabajo de los demás.

Release Line

¿Cómo realizar el mantenimiento de versiones publicadas (releases) sin interferir con el trabajo propiamente de desarrollo? Debería aislarse lo uno de lo otro. Una versión de producción o release evoluciona de forma totalmente diferente a una de desarrollo, ya que necesita mejoras y mantenimiento. Los problemas surgen cuando se detecta un problema en la versión de desarrollo que hay que actualizar urgentemente en la versión de producción: las operaciones de fusión (merge) son complejas.

Para evitar estas situaciones, es recomendable mantener cada versión de release en una línea de producción diferente. Esto permite que tal línea avance a medida que se solucionan errores. Para ello,  se podría crear una rama (o repositorio) para cada versión de producción. Posteriormente se actualizarán las mejoras y repararciones realizadas en la rama o repositorio de cada release de forma periódica, mediante una operación de merge. La línea de desarrollo (línea principal) será la guía, la cual recibirá los resultados de los merge fruto de las mejoras realizadas release a release.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s