Introducción
En mi experiencia, he notado que muchas veces que si bien ya nadie cuestiona que el código debe versionarse, los ambientes de integración y test deben respetarse, al código hay que darle cobertura. Esto termina pasando a un quinto plano, simplemente para dar respuesta a una necesidad dinámica constante del Negocio. En donde predomina que "
la urgencia manda".
¿Que es la Urgencia?
Normalmente, en desarrollo, entendemos por urgencia a un requerimiento que nace salteando todo proceso de desarrollo establecido y se inserta como prioridad uno dentro de nuestro esquema de tareas. Estas tareas de urgencia suelen tener 2 grandes orígenes.
- Falta de Previsión del Negocio
- Dinamismo extremo del Negocio
Cada uno de estos puntos tiene diferentes mecanismos de acción para aminorar el impacto en nuestro equipo de desarrollo.
Si nos ponemos a analizar el 1° tiene un enfoque mas organizacional, donde las acciones a tomar engloban al conjunto de los participantes del Proyecto.
En este articulo, nos vamos a enfocar mas que nada en el 2°, porque que es el que nos pone a prueba como profesionales y que independientemente de las circunstancias, nosotros debemos dar respuesta al negocio, eso es lo que nos vuelve dinámicos.
Analizando esto, imaginémosnos un escenario de alto dinamismo, en mi caso fue una empresa de medios digitales ( un Diario en Internet ).
¿Que pasa en un diario...?
Los hechos de la realidad actual terminan definiendo requerimientos de manera casi ininterrumpida, que para su aprovechamiento deben estar resueltos en el menor tiempo posible y si se puede antes mejor. Es como una constante carrera armamentista entre los diferentes portales, si uno tiene X el otro lo quiere también. Y si se rumorea que la competencia esta por sacar Z, hay que sacar Z antes.
Seguramente verán esto es algo que pasa frecuentemente, no solo en medios, y sabrán que esto pone a prueba todo nuestro ciclo de desarrollo. Pero creanme que cuando no surge una solución a este dinamismo, éste se termina cargando todos nuestras buenas intenciones y practicas.
- Subidas programadas cada x días. Rta: no puedo esperar, tiene que subir Ya...
- Testing para garantizar calidad. Rta: prefiero tenerlo Ya...
- etc... Rta: YA!
Esto nos lleva a que nuestro ideal equipo que aplicaba metodologías ágiles, termine siendo el grupo de monos en una cinta de producción, donde la calidad pasa a un quinto plano. Llevándose hasta la moral de quienes lo integran.
¿Cómo responder al dinamismo sin derrumbar nuestros principios?
El enfoque tradicional al que estamos acostumbrados al desenvolvernos en un equipo de desarrollo es el de las subidas programadas cada 1 o 2 semanas (sprint). El alto dinamismo de estos proyectos vuelve a este esquema inviable. Por lo cual hay que cambiar el sistema de referencia que utilizamos a uno mas acorde a las necesidades, el Proyecto.
La propuesta es la de simplemente cambiar nuestro sistema de referencia, manteniendo el resto intacto. Este esquema nos muestra como adaptar el versionado para cumplir este nuevo enfoque.
.png "SVN Lifecycle for high dynamic projects") |
| Manejo de Proyectos altamente dinámicos utilizando Subversion |
Trunk
Vemos un trunk con muchos proyectos en simultaneo, integrados en el ambiente de Desarrollo. El alto dinamismo que tenemos en este entorno, provoca que halla muchos proyectos en diferentes estados de madurez. Esto vuelve al entorno de desarrollo, en cierta forma, inestable no apto para un testeo exhaustivo. Por eso para grandes proyectos, donde se prevee un impacto masivo, que puede complicar el ambiente de interacción, se puede crear un branch para dar a ese proyecto cierto nivel del aislamiento.
Branch de integración
Vemos un branch intermedio (0.1.x) que funciona como 'padre' de los futuros tags productivos que no debe tener diferencias con el ultimo tag generado.
Cuando se decide subir un proyecto, se toma del trunk las revisiones componen al proyecto desde el Trunk y se lo mergea con el branch de integración.
Entonces ahora se podría decir que "el branch de integración es igual a producción, a lo sumo difiriendo en el nuevo proyecto que queremos subir".
En este estadio se dan las condiciones necesarias para someter al proyecto a un test intensivo, pudiendo o no requerir fixes. Si se requieren fixes, estos se desarrollan en trunk y se llevan al branch de integracion donde el proyecto es nuevamente evaluado. Hasta que el proyecto llega al estado de madurez necesario para ser subido a producción.
Tags Productivos
Una vez que el proyecto en el branch de integracion esta para subirse, se realiza el nuevo Tag desde el branch de integración y se sube.
Conclusiones
En lineas generales, este esquema nos permite reaccionar al dinamismo, dándonos las herramientas para mantener el control sobre el código que generemos. Nos permite rollbackear proyectos, volver a versiones anteriores y mantener en control un código que si no se organiza terminaría en el caos total.
A medida que la presión aumente, se puede hacer cada vez menores controles sobre la calidad e intensidad del testing. Un buen aliado para reducir los tiempos de Testing sin relegar la calidad, seria automatizar el testing de las funcionalides mas criticas del sitio.
Entendamos bien que tenemos que informar y dejar bien en claro que la baja de control de calidad sobre lo que hagamos, debe ser una propuesta de ultimo recurso para achicar los tiempos normales de una desarrollo y cumplir con los objetivos impuestos, y que no podemos tomar por nosotros mismos.
.png "SVN Lifecycle for high dynamic projects")