Dentro del ciclo de vida de los componentes software, ya explicábamos en el anterior post, que dentro del enfoque DevOps actual, es necesario incorporar una nueva fase al ciclo de vida de desarrollo, para controlar el rendimiento de los componentes (DevPerOps) y como éstos afectan a los objetivos de negocio, a través de la centralización de todo el flujo de trabajo mediante una Oficina Técnica de Rendimiento (OTR) de continua.

No obstante, antes de que los componentes suban a producción, es posible establecer ciertas reglas de control que aseguren que los componentes software promocionan bajo unos estándares de calidad y rendimiento, política de promoción a producción.

Para que exista una adecuada política de promoción a producción, deben existir dos componentes básicos:

• Calendario de subidas a producción que establezca qué días son los autorizados para promocionar el software.
  • Se establecerán días críticos de acuerdo con negocio en los que no se podrá promocionar ningún software salvo un procedimiento de excepción que requerirá de validaciones adicionales.

• Ejecuciones de los componentes software en un entorno previo fiable a producción, que permita la comparativa de métricas asociadas a rendimiento del componente tecnológico consigo mismo.
  • No es necesario que se cuente con la misma volumetría que producción, pero si con la mayor parte de casuística posible.

Con los anteriores elementos, se puede establecer un procedimiento de subidas a producción que controle los componentes técnicos antes de su promoción a este entorno:

La política de promoción tendrá en cuenta los siguientes elementos y operara de acuerdo a los siguiente información de partida, generando como resultado un OK o NOK a la promoción:

• La aplicación deberá rellenar un Documento con cuestiones técnicas y funcionales, así como adjuntar un mínimo número de ejecuciones en entornos previos con una volumetría representativa lo más fiable posible al entorno de producción.
• Desde un equipo centralizado con conocimientos de rendimiento se revisará que el componente tecnológico sea óptimo en términos de duración y consumo, detectando aquellos cambios de comportamiento respecto a otras versiones del elemento, y aquellas malas praxis que contenga dicho elemento para su corrección previa antes de la promoción.
  • Si todo es correcto, se autorizará a la aplicación a subir el proceso a producción
  • En caso contrario, se deberán realizar las modificaciones oportunas en el software.

• Existirán excepciones al procedimiento en función de negocio. En este caso, deberá existir un compromiso para su corrección en producción, entrando dentro de la garantía del proveedor (se deberá corregir dicho componente en un plazo acordado).

De esta forma nos aseguraremos de que, en la medida de lo posible, los nuevos cambios sobre el software, llegan en las mejores condiciones a producción, para lo cual se debe disponer de unas pruebas lo más fieles posibles a producción.

Además, detectar casos con problemas de rendimiento en entornos previos, conlleva varios beneficios:

• Solución de manera proactiva de las ineficiencias en el software, dónde el mismo se encuentra en periodo de garantía.
• Disminución de los costes debido a la detección temprana de incrementos de consumo.
• Una óptima ejecución de los elementos software tras su pase a producción.
• Detección de las aplicaciones y proveedores de software que tienen mayores incidentes, poniendo especial atención a las mismas.

No obstante, será en producción, dónde se podrá validar toda la casuística posible y como cada elemento impacta a los principales objetivos de negocio de los clientes (Costes, SLA y Tiempos de respuesta), a través de la evaluación una política de revisión de elementos tras su puesta en producción, política de Post-Implantación.