Existe-t-il une chose telle que DevOps en entreprise ? Bien sûr.

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.

Et c'est pourquoi DevOps est destiné à tout le monde, surtout aujourd'hui où DevOps 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 3 ans, sont matures et leur adoption est énorme. Cependant, il existe encore une certaine opposition. Et elle vient de tous les côtés de la maison — Sécurité , Développement, Opérations et Tests, chacun avec sa propre saveur de dégoût. La sécurité pense qu'aller plus vite va créer plus de vulnérabilités. Pour le développement, cela n'est peut-être pas suffisamment rationalisé (c'est-à-dire que les opérations existent toujours). Pour les opérations, il y a une crainte de perte de contrôle ; et pour les tests, tester des éléments comme la sécurité plus rapidement signifie généralement plus de problèmes à traiter.

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 est qu’il existe une certaine ambiguïté quant à ce qu’est réellement DevOps. Et cela est dû au fait qu’il existe deux DevOps. Tout d’abord, il y a la fonction DevOps. Cette fonction est assez clairement définie comme les personnes qui dépendent généralement des opérations, mais qui servent les développeurs pour créer et maintenir les chaînes de livraison et fournir l’infrastructure. Cette définition implique des structures organisationnelles, et il est beaucoup plus facile de soutenir que cette fonction ne s’intègre pas dans les 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. La raison est que si vous pratiquez DevOps, vous créez un environnement qui peut également s’adapter facilement. Le manque d’adaptation était un problème fondamental dans les pratiques de développement basées sur la méthode en cascade, de sorte qu’au final, c’est la chaîne de livraison qui dictait l’application et non l’inverse (ce qui devrait être le cas). Le parcours DevOps ne se termine jamais réellement.

L'opposition revient à dire que nous ne voulons 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 d'applications. Le terme DevOps à lui seul peut être frustrant car il existe de nombreux acronymes, mais le mot a un objectif principal. Il nous permet d'avoir une conversation sur DevOps sans 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 semble intuitif pour ceux qui ont des années d’expérience en qualité et en sécurité. Cependant, l’objectif de DevOps n’est pas de briser les processus, mais plutôt de les rendre plus efficaces. Dans des environnements efficaces, la sécurité et la qualité sont en fait plus faciles à mettre en œuvre et meilleures.

Pour répondre aux inquiétudes des professionnels de la sécurité et des tests selon lesquelles la vitesse crée généralement plus de problèmes, la vitesse ne signifie pas moins de tests ou moins de considérations prises en compte. C'est en fait le contraire. Dans une chaîne de livraison DevOps, il y a généralement plus de contrôles et d'équilibres, mais ils se produisent en temps informatique, 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 signifier plus de sécurité et une meilleure qualité logicielle, et non moins.

La beauté de la pratique DevOps

L’avantage de la pratique DevOps est qu’elle ne présuppose pas de structure organisationnelle. Elle ne présuppose pas de structure d’application, et elle ne présuppose pas l’âge ou la maturité de l’adoption. Les organisations n’ont pas besoin d’avoir immédiatement « deux pizzas « Les équipes de développement ne sont pas forcément des applications de microservices basées sur des conteneurs, ni des startups de la Silicon Valley vieilles d’un an. Et pour remédier à la plus grande erreur de langage, les développeurs n’ont soudainement plus nécessairement besoin d’être amis avec les opérations, ou vice-versa. Ils doivent simplement partager les mêmes objectifs.

Prenons une forme extrême du candidat le plus improbable pour DevOps et voyons pourquoi DevOps est toujours utile. Prenons l'exemple de la société XYZ, une organisation de plus de 10 000 employés avec une bibliothèque d'applications monolithiques et 100 développeurs qui les soutiennent. La majeure partie du développement est basée sur l'intégration, où le code personnalisé hérité est un mystère pour tous. Les projets sont initiés par les unités commerciales et pilotés par les chefs de projet et les analystes commerciaux. Supposons que cette organisation hypothétique soit dans le secteur de la construction et n'a pas d'utilisateurs finaux commerciaux, et certainement pas techniques.

Pourquoi l'entreprise XYZ souhaiterait-elle adopter les meilleures pratiques DevOps ? Pour les mêmes raisons qu'elle envisage d'améliorer ses opérations partout : des coûts réduits et une plus grande efficacité. Si une meilleure expérience utilisateur et des versions plus fréquentes finiront par lui être très bénéfiques, elle ne peut nier que la rationalisation du développement et l'amélioration de l'efficacité de son application pour la base d'utilisateurs ne réduiront pas le coût de création de l'application, ne réduiront pas le besoin d'embaucher plus d'employés et ne résoudront pas plus rapidement les problèmes opérationnels. Les projets comporteront davantage de points de contrôle permettant aux utilisateurs finaux de valider ce qu'ils ont demandé, ce qui signifie que le risque d'échec du projet est plus faible et que les dépenses consacrées à ce projet seront mieux utilisées. L'amélioration de la vitesse de publication renforce également la compétitivité, car elle est mieux à même de répondre aux attentes des clients qui changent fréquemment, voire 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 partie intégrante de sa valeur fondamentale plutôt qu'un centre de coûts. La réalité est que même si XYZ n'est pas confrontée aux mêmes pressions en matière d'applications de qualité aujourd'hui, ce n'est qu'une question de temps avant qu'elle ne le soit. Un jour, la technologie fera tellement partie de son activité principale que de meilleures applications seront nécessaires.

Les licornes ne sont pas obligatoires

Il n’est pas nécessaire d’être une entreprise ou une équipe de développement de type « licorne » pour adopter DevOps, car DevOps est la pratique qui améliore l’efficacité de vos opérations et de votre chaîne de livraison, et non la prescription sur la façon de la construire. Les outils de pointe sont là et seront toujours là. Mais pour adopter DevOps, vous n’avez pas besoin de tous les utiliser. Ce que vous devez vraiment faire, c’est : se concentrer sur l'automatisation , la qualité et la réactivité de votre chaîne de livraison de logiciels.