DevOps - Faire tomber les murs

DevOps est l'association du développement de logiciels et de l'exploitation informatique et décrit davantage une philosophie de collaboration qu'une méthodologie clairement définie. De quoi se compose DevOps en général ?

Jörg Landwehr : Il n'y a pas de règles claires qui s'appliquent à DevOps. Il n'existe pas de manifeste DevOps unique qui définirait ce que les équipes doivent faire ou ne pas faire.

DevOps est plutôt une approche de travail flexible qui peut être adaptée aux besoins, aux processus et aux ressources de chaque entreprise.

On m'a dit un jour que DevOps appliquait les principes des processus de fabrication industrielle à la livraison de code. Néanmoins, il existe quelques éléments de base qui soutiennent le passage à DevOps, quelle que soit la situation de départ, à savoir un développement logiciel agile (processus), une culture de collaboration (personnes) et des outils d'automatisation adaptés (technologie).

Il est difficile d'introduire DevOps si l'on ne fait pas au moins de petits progrès dans tous ces domaines. Mais il n'est pas nécessaire d'atteindre 100 % au début. Si des améliorations sont apportées dans un seul de ces domaines, cela peut entraîner d'énormes améliorations, voire même l'ensemble de la transition DevOps.

DevOps est souvent associé à la livraison continue. Quelle est la différence ?

Armée de terre : Beaucoup de gens utilisent les termes DevOps et livraison continue presque comme des synonymes. Ce n'est pas complètement faux, mais il y a quelques différences.

Jez Humble, expert et auteur sur le thème de la "livraison continue", affirme qu'elle est la capacité d'intégrer toutes sortes de modifications dans la production et de les mettre ainsi entre les mains de l'utilisateur, et ce de manière sûre, rapide et durable. Nous y parvenons en nous assurant que notre code est toujours "utilisable".

DevOps peut être considéré comme une approche plus orientée vers le business, car elle englobe beaucoup plus de personnes et de processus. On ne peut toutefois pas parler d'une délimitation claire, car les thèmes se recoupent beaucoup.

Chez SAP, on a l'impression que la livraison continue est un résultat de DevOps. Mais je pense qu'elle est plutôt le résultat d'un objectif après l'intégration de DevOps.

Quels sont les principaux avantages de DevOps par rapport aux méthodes classiques ?

Armée de terre : L'un des avantages clés de DevOps est que les besoins actuels de l'entreprise sont au centre des préoccupations. Cela signifie qu'une entreprise informatique doit être en mesure de réagir aux changements d'exigences, par exemple aux demandes des clients ou à un nouveau concurrent disruptif.

En général, les coûts et les risques sont moindres avec DevOps et les délais de mise sur le marché sont nettement plus courts, ce qui se traduit par des produits de meilleure qualité et des clients nettement plus satisfaits.

Les équipes qui s'appuient sur des approches classiques comme le développement en cascade ne sont pas en mesure de s'adapter aussi rapidement à de nouvelles circonstances. Les problèmes sont généralement découverts plus tard, sont plus difficiles à diagnostiquer et plus coûteux à résoudre.

DevOps apporte en outre des améliorations importantes comme la sécurité et la stabilité des applications et, accessoirement, une augmentation de la satisfaction et de la fidélisation des collaborateurs.

Quels sont les défis qu'une entreprise doit surmonter lors de la mise en œuvre de DevOps ? Comment surmonter le maximum de résistances et établir une nouvelle culture de collaboration ?

Armée de terre : Lorsque nous parlons de DevOps avec des clients, nous nous rendons compte que c'est l'attitude envers les approches de travail et la manière dont les équipes travaillent ensemble qui posent le plus de problèmes, et non la manière dont elles sont "officiellement" constituées.

Toute personne impliquée dans un projet de l'entreprise doit par exemple devenir propriétaire de produits et de processus. Le passage des silos à des équipes interdisciplinaires aux compétences multiples est ici la clé.

Cela ne signifie pas pour autant que toute l'organisation doit être mise sens dessus dessous. Un changement de mentalité et d'approche peut suffire.

Toutefois, la question de l'organisation peut effectivement constituer un défi dans ce cas, et ce lorsque des parties importantes de la gestion d'un système SAP ont été externalisées à des partenaires externes.

Il se peut que les équipes impliquées ne se trouvent pas dans le même pays et n'aient pas non plus le même fournisseur. Cela peut conduire à une situation compliquée, mais qui peut être surmontée par un travail et une communication suffisamment concentrés.

Quelle est l'influence de DevOps sur le taux d'erreurs dans les projets SAP ?

Armée de terre : Les avantages des processus DevOps développés dans un environnement SAP peuvent être énormes. Cependant, il faut toujours garder à l'esprit que de nombreux avantages sont déjà évidents au début, lorsque les processus développés à long terme sont encore difficiles à prévoir.

Nous avons des clients qui ont réduit le taux d'erreur en production de 60 à 70% simplement en utilisant de bons outils et en augmentant l'automatisation. Et ce, avant même qu'ils ne se consacrent sérieusement au développement logiciel agile et à DevOps.

Dans quelle mesure DevOps a-t-il déjà été mis en œuvre dans les communautés SAP ?

Armée de terre : Pour être honnête, nous devons dire que le DevOps pour SAP n'en est encore qu'à ses débuts, si l'on considère le marché dans son ensemble.

Jusqu'à présent, le développement logiciel agile a connu un plus grand attrait. De plus en plus d'équipes constatent que le développement agile fonctionne dans SAP, et j'ai l'impression que ce fait ouvre également les yeux des personnes concernées sur DevOps.

Quelle qu'en soit la raison, DevOps connaît une croissance rapide. Au cours des douze derniers mois, nous avons constaté une augmentation du nombre d'organisations qui viennent nous voir pour nous demander comment nous pouvons les aider à mettre en place DevOps pour SAP.

Certains d'entre eux sont déjà très avancés sur le plan technique, mais d'autres sont plutôt bloqués. Il est intéressant de noter que même certains utilisateurs traditionnels de SAP réfléchissent maintenant aux avantages que DevOps peut apporter à leur entreprise.

Mais il faudra encore du temps avant que DevOps ne devienne la norme dans les environnements SAP. Il ne fait aucun doute que cette approche gagnera en importance au cours des prochaines années. Les entreprises doivent simplement s'assurer qu'elles utilisent les bons outils et les processus nécessaires pour y parvenir.

Quelles sont les différences entre les PME et les grandes entreprises ?

Armée de terre : DevOps est adapté à toutes les tailles d'entreprises. Et comme pour toute chose, il faut se demander si les résultats en valent la peine. Plus l'entreprise est grande, plus il est probable qu'elle dispose d'un environnement SAP vaste et complexe, dans lequel de très nombreuses modifications doivent être livrées.

Tout le monde peut imaginer que les grandes organisations peuvent obtenir des avantages considérables grâce à DevOps. Dans les PME avec des équipes informatiques légères, l'agilité pour les changements de rôles et les nouveaux processus est beaucoup plus facile et conduit donc plus rapidement au succès.

Les outils DevOps et d'automatisation, tels que nous les proposons à nos clients, peuvent également être très utiles pour les petites équipes, car ils permettent aux professionnels de se concentrer sur le travail vraiment important.

Avec Hana Cloud Platform, SAP a pu développer des microservices au sein du noyau S/4. Le nouveau paradigme de SAP se prête-t-il à la transition vers DevOps ?

Armée de terre : DevOps est très répandu et couvre de nombreux domaines différents du monde informatique. Les améliorations radicales ne peuvent donc pas être attribuées à une technologie ou un concept spécifique.

Toutefois, les services fournis par HCP pour la consommation d'applications permettent de se concentrer davantage sur les développements à des fins professionnelles plutôt que sur les retouches techniques, ce qui est en tout cas conforme à la philosophie DevOps.

Quelle que soit la technologie spécifique requise : Nous constatons que S/4 Hana, HCP, etc. servent de précurseurs à de nombreuses entreprises pour réévaluer la manière dont elles gèrent leurs systèmes SAP.

Ces nouvelles options offrent des possibilités de réflexion beaucoup plus large sur l'utilisation des méthodologies existantes, la constitution des équipes, les outils, etc.

Un très grand client multinational a profité du passage à S/4 Hana pour passer au crible toute sa chaîne d'outils SAP afin d'adopter une meilleure pratique moderne, ce qui a conduit à choisir notre ensemble d'outils DevOps pour soutenir le processus de transition.

Avec le DevOps-Toolset, vous donnez aux entreprises un outil qui simplifie la transition. Quelle est l'importance de ces outils pour DevOps pour SAP ?

Armée de terre : On ne soulignera jamais assez l'importance des outils, principalement parce que l'automatisation est un élément absolument essentiel dans le concept DevOps.

En fin de compte, c'est l'automatisation qui offre la sécurité et la vitesse qui caractérisent DevOps. Pour certaines organisations, cela représente un certain défi.

Si DevOps a déjà été mis en œuvre en dehors de SAP, il est fort probable que des outils (tels que Jenkins, Chef ou Puppet) soient déjà utilisés. On suppose généralement que ces outils et les processus qu'ils exécutent peuvent être facilement appliqués à SAP.

En réalité, cependant, la nature spécifique de SAP exige des outils particuliers tels que notre ensemble d'outils DevOps. Les utilisateurs bénéficient ainsi de l'automatisation spécifique à SAP dont ils ont besoin, comme le séquençage des transports, les vérifications des dépendances, les validations, les déploiements et les fusions entre les différents systèmes.

Il est également important que les outils spécifiques à SAP s'intègrent dans la chaîne d'outils DevOps au sens large. C'est exactement ce que fait notre ensemble d'outils DevOps, qui s'intègre à Remedy, ServiceNow, Jira et d'autres.

Nous soutenons également les aspects plus personnels de DevOps, comme par exemple un tableau de bord central qui peut être utilisé par tous les utilisateurs. L'un de nos clients a récemment décrit cela comme "l'abattement des murs" entre les équipes SAP travaillant dans différents pays.

Quel est, selon vous, le prochain sujet brûlant en rapport avec SAP et DevOps ?

Armée de terre : Pour nous, le testing est actuellement le sujet le plus brûlant. Même dans les organisations qui ont déjà introduit avec succès le DevOps pour SAP, les tests de régression peuvent représenter un véritable défi.

En général, on n'a pas le temps d'effectuer un test de régression complet pour chaque version de SAP, car les systèmes sont beaucoup trop complexes et les changements se font à un rythme trop élevé.

Nous avons longtemps réfléchi à la manière d'aborder ce problème afin de rendre les tests de régression plus pratiques, en particulier lorsque les versions SAP sont livrées très fréquemment.

C'est pourquoi nous avons lancé sur le marché un produit capable d'atteindre cet objectif. Il s'appelle Testimony et utilise une toute nouvelle approche qui élimine les nombreux efforts et coûts des solutions traditionnelles.

Il n'est pas non plus uniquement lié aux environnements DevOps et constitue donc une véritable merveille pour les projets de grande envergure tels que le déplacement de plateformes vers le cloud et a en tout cas le potentiel de soutenir un rythme plus soutenu lors de changements réguliers. Cet outil rend actuellement notre quotidien extrêmement passionnant.