Desarrollo de software. El peligro de no integrar o de ir demasiado tarde a un 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…

Anuncios

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

A %d blogueros les gusta esto: