Que celui qui livre dans SAP soit testé !


On pourrait l'appeler le "paradoxe du risque" de DevOps : Même les projets de développement les plus complexes se font en plusieurs petites étapes. Ainsi, le risque par version diminue, car moins de modifications de code entraînent logiquement moins d'erreurs.
D'autre part, les différents cycles de release sont si courts qu'il reste globalement moins de temps pour l'assurance qualité. En règle générale, un sprint - c'est-à-dire l'une des nombreuses opérations itératives de développement de nouvelles fonctionnalités - ne dure que deux semaines, tests et déploiement sur les systèmes de production compris.
En revanche, dans le modèle classique en cascade, le travail de développement est suivi d'une longue phase de test, et ce n'est qu'ensuite que la version est validée.
Les développeurs et les administrateurs SAP ont un objectif fondamental : s'assurer que ce qui a fonctionné hier fonctionnera encore demain.
Ce qui est aussi critique que difficile, en particulier dans les environnements complexes. En effet, il existe un nombre presque infini de dépendances, de sorte que la moindre erreur peut avoir des conséquences désastreuses.
Pour que DevOps soit un succès dans les environnements SAP, il ne faut pas seulement une chaîne d'outils intégrée pour la livraison continue (CD) et l'intégration continue (CI). Il faut également des outils pour les tests continus. Cela s'accompagne d'une nouvelle stratégie de test en cinq étapes :
Premièrement, le principe Shift-Left doit également être appliqué à la qualité. Corriger les erreurs avant même qu'une nouvelle version ne soit opérationnelle ne permet pas seulement de réduire les dysfonctionnements et les interruptions de service.
Au contraire, cela permet de réduire les coûts d'un facteur 15. Pour ce faire, les tests devraient toutefois avoir lieu plus tôt dans le projet que ce n'est le cas actuellement.
Deuxièmement, cela a des conséquences directes sur le processus de développement lui-même. Le nouveau code doit être testé plusieurs fois au cours d'un sprint, non seulement en termes d'exhaustivité et de fonctionnalité, mais aussi en termes de comportement dans les environnements de production.
Les évaluations par les pairs, les rétrospectives et les mesures font également partie d'une assurance qualité continue et permettent d'améliorer continuellement les procédures de test.
Troisièmement, cela signifie que les entreprises doivent intégrer l'assurance qualité dans leurs équipes et processus DevOps interfonctionnels. Non seulement les responsables de l'exploitation, mais aussi les testeurs doivent faire partie de l'équipe DevOps et participer à toutes les étapes d'un sprint.
En raison de la complexité des environnements SAP, l'assurance qualité risque de devenir un goulot d'étranglement. C'est pourquoi, quatrièmement, les équipes DevOps ont besoin du soutien d'outils pour des tests de régression automatisés.
Les outils appropriés couvrent pratiquement tout l'environnement de production et fournissent donc des résultats si proches de la réalité que le code testé positivement peut être implémenté avec un risque fortement réduit.
Cinquièmement, les clients existants de SAP ont besoin d'une stratégie de déploiement flexible. Les responsables de projet doivent pouvoir décider de manière dynamique, en fonction des résultats des tests, quelles modifications doivent ou non être intégrées dans l'environnement de production à la fin d'un sprint. Pour cela aussi, ils ont besoin du soutien d'outils d'automatisation des processus.
L'une des principales promesses du concept DevOps est l'amélioration de la qualité du code. Toutefois, des cycles de release plus courts ne suffisent pas à eux seuls à limiter le risque d'erreurs de code dans les environnements de production.
Les équipes SAP doivent donc faire des tests une partie intégrante de leurs processus pour que DevOps soit un succès, même dans des environnements complexes. Mais cela ne peut se faire qu'à l'aide d'une chaîne d'outils intégrée, qui inclut des outils de test hautement automatisés.