Pourquoi la mise en œuvre de DevOps échoue souvent (et comment y remédier)

Cet article a été initialement publié le DevOps.com. Il a été mis à jour et modifié.

Tout comme « blockchain », « big data » et « disruption numérique », le terme « DevOps » est un autre mot à la mode qui circule actuellement dans les services informatiques des grandes entreprises.

Beaucoup ont reconnu (à juste titre) la nécessité de cycles de développement logiciel plus rapides, d'un processus plus précis, étroitement aligné sur les objectifs commerciaux et permettant un flux de travail et une collaboration plus clairs entre les équipes de développement et d'exploitation. Le DevOps est essentiellement un développement « agile » qui a atteint sa maturité et est prêt à répondre aux exigences en constante évolution et en rapide développement de l'entreprise moderne. Pour les experts en sécurité, il s'agit d'une initiative remarquable : nous pouvons intégrer la sécurité beaucoup plus tôt dans le processus, ce qui réduit les coûts liés à la correction des erreurs et évite des catastrophes potentielles à l'avenir.

Le problème est que seules quelques entreprises réussissent véritablement leur mise en œuvre DevOps. Sans un soutien, un suivi et une compréhension adéquats à l'échelle de l'entreprise, cela peut rapidement devenir un gouffre financier... Vous savez, l'un de ces projets dont on ne parle pas.

Alors, quel est le problème ? Il s'agit d'une discussion intéressante, et il existe plusieurs façons d'aborder le DevOps qui, selon moi, permettront un déroulement beaucoup plus fluide. Un programme efficace va au-delà de quelques nouveaux outils sophistiqués, de titres et de réunions d'équipe. Cela ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de la mettre en œuvre correctement dès le départ) sera beaucoup moins pénible à long terme. En fin de compte, cela permettra d'obtenir des logiciels de meilleure qualité et plus sûrs.

Permettez-nous de vous expliquer cela en détail :

Veuillez détacher les cordons du tablier « Agile ».

Il existe une certaine idée fausse selon laquelle une entreprise doit choisir entre Agile et DevOps et s'engager dans l'une ou l'autre voie sans jamais revenir en arrière.

Le fait est que le processus de développement fonctionne mieux lorsque les deux sont considérés et mis en œuvre comme un tout. DevOps n' est pas une réinvention du développement agile, mais plutôt une extension de celui-ci. Les rouages ont tendance à se gripper lorsque l'on s'attend à ce que le processus soit exactement comme Agile ou complètement différent d'Agile.

Agile soutient le principe des équipes interfonctionnelles, rassemble dès le début les concepteurs, les testeurs et les développeurs, et s'engage à maintenir des voies de communication ouvertes tout au long du projet. L'objectif est de mettre fin à la fourniture isolée et de réduire les doublons. Ces deux aspects constituent également des avantages du processus DevOps. Cependant, DevOps va encore plus loin et intègre les systèmes, la sécurité et les opérations afin d'offrir un savoir-faire solide et cohérent, dont l'objectif ultime est de fournir au client un logiciel complet et fonctionnel.

Au cours des défis inévitables liés à la transition vers un processus davantage axé sur DevOps, le risque d'un développement isolé peut réapparaître. Souvent, l'équipe Agile initiale peut collaborer, tandis que les extensions de sécurité et d'exploitation continuent de trouver leur place dans le système. Personne n'est tout à fait certain de la manière de les intégrer, de ce qu'elles devraient accomplir et des objectifs généraux qu'elles poursuivent.

DevOps ne peut fonctionner sans objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties prenantes. Il y aura bien sûr une phase d'adaptation qui nécessitera une gestion minutieuse du changement, mais mettre tout le monde au même niveau grâce aux améliorations apportées par la fonctionnalité DevOps représente déjà la moitié du chemin.

De plus en plus (heureusement), DevOps accorde également de l'importance aux procédures de sécurité éprouvées dans le cadre du processus, démystifie cette étape et comble le fossé entre l'équipe de sécurité et toutes les autres. Comme je l'ai déjà mentionné, il nous reste encore un long chemin à parcourir pour permettre aux développeurs de programmer de manière sécurisée dès le début, mais la mise en œuvre réussie des méthodes DevOps constitue une excellente base sur laquelle les compétences en matière de sécurité peuvent être développées au sein de l'équipe de développement.

L'automatisation n'est pas la solution à tout (et elle n'est pas la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement logiciel. Les principes d'intégration continue et de déploiement continu (CI/CD) sont les piliers de ce concept et, comme vous pouvez probablement l'imaginer, ils dépendent fortement des outils.

Les outils sont remarquables, c'est indéniable. Ils peuvent accélérer le processus de déploiement logiciel de manière sans précédent et faciliter la gestion du référentiel de code ainsi que des éléments de test, de maintenance et de stockage.

Les robots pourraient certes nous priver de tous nos emplois et nous emprisonner un jour, mais ils n'en sont certainement pas encore là. La forte dépendance aux outils et à l'automatisation laisse une grande marge d'erreur. Les analyses et les tests peuvent ne pas tout détecter, le code peut rester non vérifié, ce qui entraîne par la suite d'énormes problèmes de qualité (sans parler des problèmes de sécurité). Il suffit d'une seule porte dérobée à un pirate pour exploiter les données, et le fait de renoncer à la composante humaine dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le juste milieu consiste à garantir un équilibre entre les personnes et les outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

• Veuillez prévoir suffisamment de temps pour permettre aux collaborateurs de se familiariser avec la chaîne d'outils DevOps sélectionnée.
• Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent y contribuer).
• Comblez toutes les lacunes du processus, qu'elles soient liées aux compétences, aux connaissances ou aux outils.

En résumé, il est préférable de ne pas se contenter de mettre à niveau et d'espérer que tout se passe bien.

DevOps n'est pas un simple mot à la mode, c'est une culture. Développez-vous la vôtre ?

La gestion du changement est, dans le meilleur des cas, difficile. La crainte de l'inconnu peut empêcher même les membres les plus brillants d'une équipe d'élargir leurs compétences et d'élargir leurs horizons.

Vous voyez, le simple fait de dire « Passons au DevOps » et d'amener l'équipe opérationnelle à déplacer ses bureaux ne suffira pas à mettre en œuvre comme par magie un processus efficace. Beaucoup seront déconcertés et les membres de longue date de l'équipe se sentiront contrariés. Il est essentiel de communiquer clairement les attentes, tout comme il est important de « suivre son propre chemin ». DevOps est autant un mouvement culturel qu'une méthodologie de développement, et une équipe doit adopter et mettre en pratique une approche collaborative et interfonctionnelle.

À quoi ressemble une excellente culture DevOps ?

• Les individus sont encouragés à apporter leur expertise dans un processus, et pas seulement les cadres supérieurs.
• Communication ouverte, honnête et respectueuse entre les équipes
• Chaque personne assume la responsabilité de l'objectif global de qualité et de sécurité des bâtiments dans le processus de développement.
• Tous sont d'accord sur la définition de DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chaque personne.

Depuis de nombreuses années, j'insiste sur l'importance de développer une culture de sécurité positive au sein des équipes de développement, et DevOps ne fait pas exception.

Les outils adéquats, les connaissances appropriées et le soutien nécessaire sont indispensables pour mettre en œuvre des procédures de sécurité éprouvées, observer une diminution des failles de sécurité détectées et sensibiliser l'équipe à l'importance de la protection de nos données. Avec DevOps, vous devez créer les bases culturelles nécessaires à un changement positif : assurez-vous que chacun comprenne son rôle, sa valeur et ses attentes, ainsi que les objectifs généraux du projet et les différentes étapes du processus.

Avez-vous maîtrisé cela ? Excellent. Passons maintenant à autre chose, examinons de plus près l'aspect sécurité et faisons de DevSecOps le plan ultime pour l'excellence logicielle.