Así que pruebe quién cumple en SAP

Podría llamarse la "paradoja del riesgo" en DevOps: Incluso los proyectos de desarrollo más complejos se desarrollan en muchos pasos pequeños. Esto reduce el riesgo por versión, ya que menos cambios de código conllevan lógicamente menos errores.

Por otra parte, los ciclos de lanzamiento individuales son tan cortos que en general hay menos tiempo para garantizar la calidad. Por regla general, un sprint -es decir, una de las muchas fases de trabajo iterativas para desarrollar nuevas funcionalidades-, incluidas las pruebas y la implantación en los sistemas productivos, dura solo dos semanas.

En cambio, en el modelo clásico de cascada, el trabajo de desarrollo va seguido de una larga fase de pruebas, y sólo entonces se aprueba la publicación.

Los desarrolladores y administradores de SAP tienen un objetivo fundamental: garantizar que lo que funcionó ayer funcione mañana.

Esto es tan crítico para el éxito como difícil, especialmente en entornos complejos. Porque aquí hay un número casi infinito de dependencias, de modo que incluso los pequeños errores pueden tener consecuencias devastadoras.

Para que DevOps sea un éxito en entornos SAP, no solo se necesita una cadena de herramientas integrada para la Entrega Continua (CD) y la Integración Continua (CI). Más bien, se necesitan herramientas adicionales para la Prueba Continua. Esto va acompañado de una nueva estrategia de pruebas en cinco pasos:

En primer lugar, el principio de shift-left debe aplicarse también a la calidad. Corregir los errores antes de lanzar una nueva versión no solo garantiza menos fallos e interrupciones del servicio.

Más bien, es posible reducir los costes hasta un factor de 15. Para ello, sin embargo, las pruebas tendrían que realizarse en fases del proyecto más tempranas que antes.

En segundo lugar, esto repercute directamente en el propio proceso de desarrollo. El nuevo código debe probarse varias veces durante un sprint, no solo en cuanto a integridad y funcionalidad, sino también en cuanto a su comportamiento en los entornos de producción.

Las revisiones inter pares, las retrospectivas y las mediciones también forman parte del aseguramiento continuo de la calidad y permiten mejorar continuamente los procedimientos de ensayo.

En tercer lugar, esto significa que las empresas deben integrar la garantía de calidad en sus equipos y procesos multifuncionales de DevOps. No solo los responsables de operaciones, sino también los probadores deben formar parte del equipo de DevOps y participar en todos los pasos de un sprint.

Debido a la complejidad de los entornos SAP, la garantía de calidad amenaza con convertirse en un cuello de botella. Por lo tanto, en cuarto lugar, los equipos de DevOps necesitan el apoyo de herramientas para las pruebas de regresión automatizadas.

Las herramientas adecuadas cubren prácticamente todo el entorno productivo y, por tanto, ofrecen resultados tan próximos a la realidad que el código probado positivamente puede implantarse con un riesgo muy reducido.

En quinto lugar, los clientes actuales de SAP necesitan una estrategia de implantación flexible. Los jefes de proyecto deben poder decidir dinámicamente, en función de los resultados de las pruebas, qué cambios deben transferirse al entorno productivo al final de un sprint y cuáles no. Para ello, también necesitan el apoyo de herramientas de automatización de procesos.

Una de las promesas centrales del concepto DevOps es una mayor calidad del código. Sin embargo, unos ciclos de publicación más cortos no bastan por sí solos para contener el riesgo de errores de código en entornos productivos.

Por lo tanto, los equipos SAP en particular deben hacer de las pruebas una parte integral de sus procesos para llevar a DevOps al éxito incluso en entornos complejos. Sin embargo, esto solo puede lograrse con la ayuda de una cadena de herramientas integrada que incluya herramientas de pruebas altamente automatizadas.