La capsule du DevOps Leader

Qu’est-ce qui retarde le succès du DevOps dans les entreprises ?

La méthodologie DevOps, née ces dernières années répond à ce phénomène en permettant d’accélérer la façon dont les entreprises développent, testent et déploient ou distribuent les applications. La mise en œuvre de cette méthode est la priorité de la plupart des développeurs et des équipes chargées des opérations qui ne l’appliquent pas déjà.

Ce qu’il faut comprendre c’est qu’une stratégie DevOps repose moins sur les outils que sur la création d’une culture propice. Dans la pratique, la méthodologie DevOps instaure une culture et un environnement permettant de développer, tester et déployer des logiciels avec une fréquence et une fiabilité supérieure. Peu importe qu’une organisation opère entièrement dans le cloud, qu’elle suive une approche hybride ou qu’elle fasse tout sur site, les éléments constitutifs de DevOps ne changent pas seulement la rapidité de déploiement.

De fait les technologies cloud accélèrent les processus DevOps maintenant que des étapes comme celle de l’automatisation sont facilitées par des API basées dans le cloud, que l’accès aux bases de données est plus rapide et que l’évolutivité se fait à la demande. Toutefois, les organisations rencontrent des problèmes quand elles essaient de faire trop à la fois, qu’elles ignorent des éléments clés comme la base de données et qu’elles n’ont pas l’expertise pour mener à bien la transformation vers de nouvelles manières de travailler.

Les conditions de la réussite

Même avec les meilleures intentions, certains facteurs peuvent réduire considérablement les chances de succès d’une métamorphose DevOps.

Le premier facteur de risque est de vouloir faire adhérer à l’approche DevOps tous les membres de l’équipe technique, les développeurs, les chargés des opérations, les équipes de sécurité, les administrateurs de base de données, surtout quand des silos organisationnels sont présents depuis des années, comme c’est le cas dans certaines organisations. Une banque bien connue a, par exemple, tenté de transformer son organisation vieille de 120 ans en voulant appliquer la méthodologie DevOps à 1000 applications couvrant les divisions bancaires professionnelles, privées et les ventes. Malheureusement, la tentative a échoué du fait des divergences de points de vue et de calendrier en interne, en raison d’un environnement hautement réglementé, d’un système IT central strict et de la connaissance limitée des stratégies DevOps et de la technologie sous-jacente. A présent, ils appliquent ces connaissances à des projets au cas par cas, plutôt qu’à l’entreprise dans sa globalité

Le second facteur qui entrave souvent la réussite d’une stratégie DevOps concerne le manque d’attention accordée à la base de données applicative. Si les mises à jour des applications supposent des changements de base de données, le processus DevOps échoue souvent, parce que les bases de données sont depuis toujours développées et gérées différemment en raison de leur complexité, du processus de développement spécifique et de leur nature sensible. De plus, le développement des bases de données néglige souvent les tests et les revues du code, les contrôles du code source et la facilité d’intégration aux processus d’automatisation de build, qui sont des étapes critiques pour prévenir les erreurs impactant les systèmes de production.

Les outils basés dans le cloud peuvent certainement aider à faire tomber les barrières fréquemment associées au déploiement de changements de base de données et à automatiser ces ajustements au sein des processus DevOps existants d’intégration et de déploiement continus. Mais pour cela, il faut que les administrateurs de base de données soient partie prenante de la transformation DevOps, de façon à éviter les goulets d’étranglement inutiles et à faire en sorte que les meilleures solutions possibles soient retenues et avancent.

Les dirigeants d’entreprise qui préparent leurs stratégies DevOps en 2018 devraient considérer cinq facteurs pour s’assurer que leur entreprise demeure agile et qu’elle continue de prospérer à l’ère du digital. 

• La formation : il faut absolument s’assurer que quiconque participe à la mise en œuvre de DevOps, surtout dans le cloud, soit correctement formé aux différentes technologies et puisse communiquer ses connaissances aux autres dans l’entreprise. DevOps constitue un changement culturel et dépend des talents en présence, si bien qu’il est essentiel qu’il y ait une compréhension partagée des tenants et aboutissants pour que les attentes demeurent réalistes. 
• Eviter la bulle du propriétaire : il convient d’éviter que l’entreprise soit liée à un seul fournisseur. Pour que DevOps soit une réussite, les entreprises doivent se montrer aussi ouvertes et flexibles que possible dans le choix des outils étant donné qu’elles devront peut-être modifier les plateformes à l’avenir. Il est bon également d’envisager d’utiliser des conteneurs pour le déploiement d’applications afin d’apporter plus de flexibilité.
• L’intégration du développement de base de données : prévoyez d’intégrer d’emblée le développement de base de données dans vos projets DevOps, sinon cela pourrait créer un goulet d’étranglement qui risquerait de retarder le déploiement des applications.
• Priorité aux tests de performance : c’est rarement le cas avec les déploiements sur site. Avec les services cloud, sur abonnement, les tests de performance sont particulièrement importants pour s’assurer que l’on n’utilise pas plus de ressources cloud que nécessaire.
• Priorité aux recettes automatisées: Il est plus qu'utile d'automatiser les recettes métiers des solutions afin d'avoir une meilleure visibilité sur les regressions des produits et services. Cette activité permet efficacement de les tester sur des environnements hétérogènes afin d'apprécier leurs comportements et ainsi déceler les insuffisances, mener les corrections adéquates ou faire des recommandations d'usage
• Ne pas trop investir : mieux vaut d’abord tester les pratiques DevOps et la technologie sous-jacente sur un projet pilote ou à faible niveau de risque, en tirer des enseignements puis déployer d’autres projets avec la connaissance acquise de ce qui a fonctionné ou pas.