archivo

Archivo de la etiqueta: entorno de integración

Es cómodo trabajar y probar el programa en tu equipo, lo tienes preparado a tu gusto y tienes todo lo necesario para que el sistema corra.

Sin embargo, cuanto más tardes en integrar tu trabajo con el resto del producto o cuanto más tardes en probar tus desarrollos en un entorno de integración mayor será el coste de resolver las incidencias que te puedes encontrar, es más, si decides entregar el producto sin ni siquiera haber realizado un testing serio en integración estás cometiendo una temeridad (eso del “funciona en mi equipo” mejor ni siquiera mencionarlo).

Y es temerario (porque siempre se suelen dejar cabos sueltos y porque en tu máquina no tiene que coexistir con otros sistemas de información que estarán instalados en el mismo servidor) incluso aunque te hayas esforzado (cosa que no se suele hacer) en utilizar la misma versión de máquina virtual que el sistema operativo del servidor de integración, las mismas infraestructuras que se van a utilizar para instalar la aplicación en el entorno de integración (control de versiones, repositorio de librerías dependientes, sistema de integración continua, etc…), la misma versión del servidor de aplicaciones, la misma base de datos y juego de datos, etc…

Es necesario acudir a un entorno de integración (a ser posible en sede de cliente con una infraestructura tecnológica que sea lo más similar posible a producción), no es ninguna pérdida de tiempo. La pérdida de tiempo (y de dinero) viene después cuando te echan para atrás la entrega ya que al coste adicional de corregir las incidencias hay que sumarle el hecho de que te corta el ritmo de desarrollo ya que no es lo mismo corregir determinadas incidencias leves que se hayan colado en producción a tener que revisar una entrega completa (con su testing correspondiente) independientemente de que los errores estén más o menos localizados además de preparar la entrega correspondiente.

No recomiendo utilizar el entorno de integración como entorno de desarrollo (de diario) porque generalmente se deja “basura” que después termina quedándose en la entrega y que pueden provocar que la misma sea rechazada (al fallar el testing del sistema en un entorno de preproducción) o que la misma, siendo inocua termine llegando a producción y nos encontremos por ejemplo con tablas de base de datos que no sirven para nada, clases que contienen métodos que no se utilizan, etc…

En el artículo anterior vimos las actividades que definían al proceso de implantación y de las consecuencias de que el tiempo necesario para realizar esa actividad superasen unos umbrales admisibles para el proyecto de desarrollo de software en cuestión.

La aplicación de una metodología o enfoque ágil o la utilización, en general, de alternativas iterativas e incrementales suponen por su propia naturaleza una disminución de los tiempos de implantación, sobre todo, una vez que ya se han realizado varias evoluciones del sistema.

Sin embargo, si el tiempo necesario para realizar las implantaciones resulta superior al tiempo de iteración definido tenemos un problema ya que provoca una acumulación de las entregas y que buena parte del tiempo invertido en el proceso de implantación se pierda. Esta situación no debería mantenerse mucho tiempo y para solucionarla sería necesario retrasar una entrega hasta que se pueda subir una acumulación de evoluciones a producción.

Estas situaciones pueden producirse en más ocasiones de las que podemos pensar, ya que lo mismo los trabajos siguiendo metodologías ágiles, parten de una versión del producto avanzada y que no ha sido implantada todavía (o no se han implantado con éxito), los equipos encargados de testing y de paso a producción tienen una carga de trabajo elevada, otras prioridades, etc…

Soy de la opinión de que para poder trabajar de manera adecuada hay que estabilizar la situación, es decir, si la implantación de un producto resulta compleja o está dando problemas, hay que centrar los esfuerzos en ella y adaptar los desarrollos que se están haciendo a esa circunstancia.

Además de la aplicación de enfoques ágiles, ayuda mucho la existencia de unos entornos de integración y de preproducción los más parecidos posibles a los de reales, la aplicación de la integración continua, la utilización de técnicas de desarrollo guiadas por las pruebas (TDD) o al menos la aplicación de una estrategia adecuada de aplicación de pruebas unitarias, para reducir de esta forma la aparición de efectos colaterales y disminuir los tiempos necesarios para las pruebas de regresión y la corrección de este tipo de incidencias.

Además de lo anterior es importante que con carácter previo a la entrega el producto haya sido probado de manera adecuada por el equipo de proyecto (nada de entregas a ciegas o de pruebas superficiales).

También resulta muy adecuado el establecimiento de itinerarios de testing (todas las aplicaciones no requieren el mismo nivel de testing, ni todas las circunstancias son similares), la aplicación de testing ágil, proporcionar a los proveedores información detallada sobre las características de nuestro entorno de producción, la aplicación de una política de prioridades a los equipos encargados del paso a producción acorde a la problemática existente en cada momento, etc…