Patrones en Gestión de Configuraciones Software (IV)

Codeline Policy

Cuando se mantienen varias líneas base para un proyecto, surge el problema de cómo distinguir entre cada una de ellas, en cuál hacer las protecciones, qué pruebas ejecutar, cada cuánto tiempo se debería realizar una protección en esa línea, etc. Cada línea base tendrá un propósito diferente: desarrollo, depuración, soporte a distintas plataformas…; cada una con diferentes características en cuanto a estabilidad. Por ejemplo, una línea de versiones de producción será más estable que una de desarrollo.

Se hace necesario, por tanto, definir políticas para cada línea y comunicarlas al equipo. Para cada rama o línea base, se define una política que determina cómo y cuándo deben hacerse cambios en dicha rama o línea base. Tales políticas deben ser concisas y auditables. Para ello, utiliza nombres con significado y siguiendo una convención, formula un propósito coherente para dicha rama, como ya hemos indicado: tipo de trabajo que contiene, cómo y cuándo se protegen los artefactos (ítems o documentos: elementos sujetos a control de versiones), cuándo y cómo hacer una fusión (merge) , cuándo y cómo crear ramas, etc. Además, deben definirse unas restricciones de acceso, relaciones de importación y exportación con respecto a otras líneas base; tiempo de vida previsto para dicha línea; carga de actividad y frecuencia de integración esperada.

Todo ello se puede resumir en unos pocos párrafos, no hay porqué escribir un tratado. Tampoco es necesario indicar todos los puntos que hemos enumerado; solamente se incluirán aquellos que tienen sentido para cada caso concreto. Siempre que se pueda, ayúdate de tu software de control de versiones para realizar esta tarea.

Un corolario que se podría deducir de todo lo dicho hasta ahora sería lo siguiente: debería crearse una nueva rama cuando existan incompatibilidades entre políticas, puesto que cada rama define una política, la suya propia.

Smoke Test

¿Cómo verificar que el sistema seguirá funcionando después de realizar un cambio? Una solución es generar una serie de casos de prueba a ejecutar antes de realizar una protección en el repositorio. El problema surge ahora a la hora de pensar cómo deben ser tales test. Lógicamente no se puede probar todo porque sería demasiado pesado y el equipo tendería a realizar pocas protecciones; por tanto, un buen Smoke Test podría incluir pruebas de las partes más críticas o más propensas a errores (recordar la Ley del 80 y 20 de Pareto, que aplicada al software sería algo así como “el 20% del código aglutina el 80% de los errores“. No es difícil identificar ese 20%…). Verifica la funcionalidad básica: que la aplicación no se haya roto de un modo obvio. Automatiza tales pruebas, y que simplemente se informe de si el test se ha pasado o no. Posteriormente, veremos a mano dónde falló.

Un apunte muy importante es que los Smoke Test no son ni las pruebas de depuración ni las pruebas que realiza de su código el propio desarrollador. Tanto menos son pruebas unitarias, que se presentan a continuación, cerrando esta entrega.

Unit Test

¿Cómo verificar que un módulo (procedimiento, rutina, función, método o lo que quieran) sigue funcionando como debería después de realizar un cambio? Esto también sirve para nuevos módulos. Comprobar que el estado no cambia nos ayudará a mantener la estabilidad en nuestro desarrollo. Nos permite ver si hay errores y dónde, entre protección y protección, aumentando enormemente la visibilidad del progreso en el desarrollo.

Posteriormente, al realizar los test de integración o los Smoke Test (ver más arriba) es más sencillo saber qué parte falló. Desarrolla, pues, y ejecuta test unitarios que prueben de forma exhaustiva cada módulo.

Al igual que otros tipos de test estos son susceptibles de ser automatizados, lo cual es, además, muy recomendable. Son autoevaluables, de grano fino y aislados en cuanto a dependencias con otros módulos o pruebas. Deberían verificar el contrato entre interfaces (recordar programación por contrato). Debería ser, además, fácil de ejecutar.

Los test unitarios deben ser ejecutados durante la implementación del módulo y antes de hacer una protección. Pueden ser utilizados también cuando se detectan errores a un nivel superior: pruebas de sistema, de integración…

“Si no se pueden identificar pruebas unitarias para una unidad, deberías revisar tu diseño.”

Stephen Berczuk.

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

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