A mi me funciona

Los expedientes-X existen, fallos que no tienen explicación o razón de ser pero pasan. A veces encuentras la causa,  a veces se arreglan como vienen y otras veces acabas dando un rodeo para solucionarlo. Cuanto más niquelado tengas la plataforma bajan en cantidad y suben en calidad.

Pero lo normal es encontrarse errores típicos y en el caso de errores en aplicaciones necesitas la complicidad de desarrollo y estar seguro de poder descartar hipótesis. Para hacerlo, lo primero es poner orden y establecer unas reglas que simplifiquen a plataforma.

  • Un repositorio central de código fuente versionado y auditable.
  • Entornos de desarrollo, test, preproducción y producción homogeneos e identicos: mismas aplicaciones, mismas versiones, mismos conectores, drivers (incluso versión), misma estructura/plataforma (pj en cluster, con proxys intermedios,bbdd independientes por entorno, usuarios por entorno,etc…). Los entornos de test y los de desarrollo deben ser lo mas parecidos a producción posibles (no siempre es asi, si en produccion tienes 2 balanceadores por valor de 90k euros es complicado tenerlos en test).
  • Un unico proceso de construcción por aplicación. Construcción identica tanto para los entornos de desarrollo, test como producción.
  • Código fuente identico para una aplicación en los diferentes entornos, solo cambia la parametrización del entorno. Aseguras que la aplicación con etiqueta X es la misma aplicación X que probo el usuario, que se subió a preproducción y que generó desarrollo. No hay comportamientos distintos de la aplicación porque el código fuente sea distinto, si se comporta de forma distinta es por la casuistica del entorno (acotas hipótesis).
  • Procesos de construcción automáticos sin intervención manual (o intervención minima al declarar etiqueta X). Te aseguras que nadie mete la pata sin querer y que lo que construye hoy lo construye como ayer y antes de ayer. Y si instala, en los mismos sitios y de la misma forma.
  • Pruebas de integración continua, calidad del software, pruebas de regresión. Todo automático por supuesto, ya tienes las herramientas básicas en los pasos anteriores. Dependes de los programadores para hacer pruebas unitarias y chequeos pero es la forma de detectar errores de regresión (errores ya corregidos que vuelven aparecer en versiones posteriores) .
Seguro que me dejo más, aunque es lo básico y suficiente para tener algo decente. Esto no evita que existan problemas, evita que existan muchos problemas en un entorno en caos.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *