Existe-t-il un DevOps d'entreprise ? Absolument.

Après tout, en fin de compte, DevOps n'est qu'une méthodologie, qui permet des versions de logiciels plus rapides, plus efficaces et de meilleure qualité, ce qui est une bonne chose, que vous soyez une startup avec trois employés ou une entreprise avec 3 000 employés.

C'est pourquoi DevOps est accessible à tous, surtout aujourd'hui, alors qu'il a atteint sa maturité. Laissez-moi vous expliquer…

Pourquoi l'opposition à DevOps persiste

Nous sommes à la maturité phases d'adoption de DevOps . Alors que les pratiques de pointe se multiplient microservices , Kubernetes, etc., volent la vedette. Les concepts fondamentaux de DevOps, vieux de plus de trois ans, sont matures et connaissent une adoption massive. Cependant, une certaine opposition persiste. Et elle vient de tous les horizons. Sécurité Développement, Opérations et Tests, chacun avec son lot de réticences. La sécurité estime qu'aller plus vite engendrera davantage de vulnérabilités. Pour le développement, la rationalisation est peut-être insuffisante (les Opérations existent toujours). Pour les Opérations, la crainte d'une perte de contrôle est présente ; et pour les Tests, tester plus rapidement des aspects comme la sécurité implique généralement davantage de problèmes à gérer.

Non seulement certains acteurs de ces fonctions hésitent encore à l'égard de DevOps, mais ils évoluent également dans une entreprise où les inquiétudes s'accompagnent de l'incapacité de l'entreprise à apporter des changements au même rythme que les startups.

L'histoire de deux DevOps

Le problème réside dans l'ambiguïté de la définition même de DevOps. En effet, il existe deux types de DevOps. Premièrement, la fonction DevOps. Cette fonction est clairement définie comme les personnes qui dépendent généralement des Opérations, mais qui aident les développeurs à construire et maintenir les chaînes de livraison, et à fournir l'infrastructure. Cette définition implique des structures organisationnelles, et il est bien plus facile d'affirmer que cette fonction ne s'intègre pas aux structures existantes que de soutenir que la définition plus large de DevOps s'y intègre.

La deuxième définition de DevOps est la pratique qui pilote le développement – « pilote » étant le mot-clé. Ce n'est pas une fin en soi. En fait, si un environnement DevOps devait « compléter » la mise en œuvre, il deviendrait instantanément un environnement non DevOps. En effet, en pratiquant DevOps, vous construisez un environnement qui s'adapte facilement. Le manque d'adaptation était un problème majeur dans les pratiques de développement en cascade, de sorte que la chaîne de livraison a finalement dicté l'application, et non l'inverse (ce qui est normal). Le parcours DevOps ne s'arrête jamais.

S'opposer revient à dire que nous ne souhaitons pas améliorer nos processus ou nos applications, ce qui ne répondrait pas aux objectifs de la plupart des organisations en matière de développement applicatif. Le terme DevOps peut être frustrant en raison de la multitude d'acronymes, mais il remplit une fonction essentielle : il nous permet d'aborder le sujet sans avoir à le redéfinir à chaque fois.

Pourquoi l'agilité améliore la sécurité et la qualité

Ensuite, nous passons à la préoccupation qui a un certain mérite et un certain fondement tactique : il s’agit de la crainte que les environnements DevOps exposent l’organisation à davantage de bugs et d’exploits de sécurité.

Cela paraît évident pour ceux qui ont des années d'expérience en qualité et sécurité. Cependant, l'objectif de DevOps n'est pas de perturber les processus, mais plutôt de les rendre plus efficaces. Dans des environnements performants, la sécurité et la qualité sont en réalité plus faciles à mettre en œuvre et plus performantes.

Pour répondre aux préoccupations des professionnels de la sécurité et des tests, selon lesquelles la rapidité engendre généralement plus de problèmes, la rapidité ne signifie pas moins de tests ni moins de considérations prises en compte. Bien au contraire. Dans une chaîne de livraison DevOps, les contrôles et les équilibres sont généralement plus nombreux, mais ils sont effectués en temps machine, et non en temps humain. Ainsi, ces contrôles et équilibres sont plus rapides, plus précis et reproductibles. Ainsi, l'agilité, dans ce cas, peut et doit se traduire par une sécurité accrue et une meilleure qualité logicielle, et non une qualité inférieure.

La beauté de la pratique DevOps

L'avantage de la pratique DevOps est qu'elle ne présuppose aucune structure organisationnelle, aucune structure applicative, ni aucun âge ni maturité d'adoption. Les organisations n'ont pas besoin d'avoir immédiatement « … » deux pizzas « Les équipes de développement. Elles n'ont pas besoin d'applications de microservices basées sur des conteneurs, ni d'être des startups de la Silicon Valley vieilles d'un an. Et pour corriger l'idée reçue, les développeurs n'ont soudainement plus forcément besoin d'être amis avec les opérations, ou inversement. Ils doivent simplement partager les mêmes objectifs. »

Prenons une forme extrême du candidat le plus improbable pour DevOps et voyons pourquoi DevOps reste utile. Prenons l'exemple de l'entreprise XYZ, une organisation de plus de 10 000 employés disposant d'une bibliothèque d'applications monolithiques et soutenue par 100 développeurs. La majeure partie du développement repose sur l'intégration, où le code personnalisé existant reste un mystère pour tous. Les projets sont initiés par les unités opérationnelles et pilotés par les chefs de projet et les analystes métier. Imaginons que cette organisation hypothétique évolue dans le secteur de la construction et n'ait pas d'utilisateurs finaux commerciaux, et encore moins techniques.

Pourquoi l'entreprise XYZ envisagerait-elle d'adopter les meilleures pratiques DevOps ? Pour les mêmes raisons qu'elle privilégie les améliorations opérationnelles : réduction des coûts et efficacité accrue. Si une meilleure expérience utilisateur et des versions plus fréquentes lui apporteront d'importants bénéfices, elle ne peut nier que la simplification du développement et l'amélioration de l'efficacité de son application pour les utilisateurs ne réduiront pas le coût de création de l'application, ne réduiront pas le besoin d'embaucher davantage et ne résoudront pas plus rapidement les problèmes opérationnels. Les projets offriront davantage de points de contrôle permettant aux utilisateurs finaux de valider leurs demandes, ce qui réduit le risque d'échec et optimise l'utilisation des fonds. Une vitesse de publication accrue renforce également la compétitivité, car elle permet de mieux répondre aux attentes des clients, en constante évolution, et même de les dépasser.

L'entreprise XYZ n'a pas besoin de reformuler son infrastructure dès le lendemain de son adoption de DevOps. Il lui suffit de rechercher des opportunités d'automatisation et de considérer le développement d'applications comme une valeur fondamentale, et non comme un centre de coûts. En réalité, même si XYZ n'est pas confrontée aujourd'hui aux mêmes pressions en matière de qualité des applications, ce n'est qu'une question de temps. À terme, la technologie sera tellement intégrée à son cœur de métier qu'elle nécessitera de meilleures applications.

Les licornes ne sont pas obligatoires

Nul besoin d'être une licorne ou une équipe de développement pour adopter DevOps. En effet, DevOps est la pratique qui optimise l'efficacité de vos opérations et de votre chaîne de livraison, et non la prescription pour les développer. Les outils de pointe existent et existeront toujours. Mais pour adopter DevOps, il n'est pas nécessaire de tous les utiliser. Il est essentiel de faire… se concentrer sur l'automatisation , la qualité et la réactivité de votre chaîne de livraison de logiciels.