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

Cet article a été initialement publié sur 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 actuellement utilisé dans les services informatiques des grandes organisations.

Beaucoup ont identifié (à juste titre) la nécessité d'accélérer les cycles de vie du développement logiciel ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant un flux de travail et une collaboration plus clairs entre les équipes de développement et les équipes opérationnelles. Le DevOps est, par essence, un développement « agile », conçu et préparé pour répondre aux besoins des entreprises modernes, qui innovent constamment et se déploient rapidement. Pour les professionnels de la sécurité, il s'agit d'une initiative remarquable : nous pouvons intégrer la sécurité dans le processus beaucoup plus tôt, ce qui réduit le coût de la correction des erreurs et évite d'éventuelles catastrophes à l'avenir.

Le problème est que peu d'entreprises réussissent réellement à mettre en œuvre le DevOps. Sans le soutien, l'attention et la compréhension nécessaires à l'échelle de l'entreprise, celle-ci peut rapidement devenir un gouffre financier... vous savez, l'un de ces projets dont il est préférable de ne pas discuter.

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

Nous allons l'analyser :

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

Il existe une idée quelque peu erronée selon laquelle une organisation doit choisir entre Agile ou DevOps, en établissant une voie ou une autre, pour ne pas regarder 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 attend du processus qu'il se déroule exactement comme Agile, ou complètement différemment d'Agile.

Agile soutient le principe des équipes interfonctionnelles, car il rassemble dès le début des concepteurs, des évaluateurs et des développeurs et s'engage à ouvrir des voies de communication tout au long d'un projet. Son objectif est de mettre fin au travail en silos et de réduire la double gestion, qui sont également des avantages du processus DevOps. Cependant, DevOps va plus loin et intègre les systèmes, la sécurité et les opérations afin d'offrir un ensemble de compétences solides et complètes dans le but final de fournir un logiciel complet et fonctionnel au client.

Au cours des inévitables difficultés liées au passage à un processus davantage axé sur le DevOps, le risque d'un développement isolé peut réapparaître. Souvent, l'équipe Agile d'origine travaille en équipe, tandis que les ajouts en matière de sécurité et d'opérations continuent de se faire une place dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils devraient faire et quels sont leurs objectifs généraux.

Le DevOps ne peut fonctionner sans objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il ne fait aucun doute qu'une période d'adaptation sera nécessaire, qui exigera une gestion minutieuse des changements, mais obtenir l'adhésion de tous aux améliorations apportées par la fonctionnalité DevOps représente déjà la moitié du chemin.

De plus en plus (heureusement), DevOps met également davantage l'accent sur les meilleures pratiques de sécurité dans le cadre du processus, démystifiant ainsi cette étape et réduisant le fossé entre l'équipe de sécurité et, disons, tous les autres. Comme je l'ai déjà mentionné, il reste encore un long chemin à parcourir avant que les développeurs puissent programmer en toute sécurité dès le début, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle développer les compétences en matière de sécurité de l'équipe de développement.

L'automatisation n'est pas la solution idéale (et 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 de l'intégration continue et de la livraison continue (CI/CD) constituent les fondements de ce concept et, comme vous pouvez l'imaginer, ils dépendent largement des outils.

Les outils sont remarquables, vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison des logiciels, car ils gèrent le référentiel de code, les tests, la maintenance et les éléments de stockage avec une relative fluidité.

Cependant, même si les robots pourraient un jour nous priver de tous nos emplois et nous emprisonner, ils ne l'ont certainement pas encore fait. La forte dépendance aux outils et à l'automatisation laisse une marge d'erreur. Il est possible que les analyses et les tests ne détectent pas tout, que le code ne soit pas vérifié et que cela pose d'énormes problèmes de qualité (sans parler des problèmes de sécurité) à l'avenir. Il suffit d'une seule porte dérobée pour qu'un pirate en profite et vole des données, et renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le « juste milieu » consiste à trouver un équilibre entre les personnes et les outils. Les outils doivent servir d'aide à une équipe en laquelle vous avez confiance pour atteindre les objectifs du projet. Vous devriez :

• Veuillez prévoir suffisamment de temps pour que les personnes se familiarisent avec la chaîne d'outils DevOps choisie.
• Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent la soutenir)
• Veuillez aborder toute lacune dans le processus, qu'elle soit liée aux compétences/connaissances ou aux outils.

En résumé, ne vous contentez pas de « vous préparer » et d'espérer que tout se passe bien.

DevOps n'est pas un terme à la mode, c'est une culture. Cultivez-vous la vôtre ?

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

Il est important de noter que le simple fait de déclarer « adoptons DevOps » et de demander à l'équipe des opérations de changer de bureau ne suffira pas à mettre en œuvre comme par magie un processus efficace. Beaucoup se sentiront désorientés et les membres de l'équipe qui travaillent depuis longtemps seront mécontents. Il est essentiel de communiquer clairement les attentes et de « montrer l'exemple ». DevOps représente à la fois un mouvement culturel et une méthodologie de développement, et une équipe doit incarner une mentalité interfonctionnelle et collaborative.

À quoi ressemble une culture DevOps de qualité ?

• Les personnes ont le pouvoir d'apporter leur expérience à un processus, pas seulement aux dirigeants.
• Communication ouverte, honnête et respectueuse entre les équipes
• Chaque personne assume la responsabilité de l'objectif général qui consiste à intégrer la qualité et la sécurité dans le processus de développement.
• Tous sont d'accord avec la définition de DevOps dans l'entreprise, la feuille de route et le comment, le quoi et le pourquoi du rôle de chaque personne.

Depuis des années, j'insiste sur l'importance de créer des cultures de sécurité positives au sein des équipes de développement, et DevOps ne fait pas exception.

Les outils, les connaissances et le soutien appropriés sont indispensables pour mettre en œuvre les meilleures pratiques en matière de sécurité, réduire le nombre de vulnérabilités découvertes et sensibiliser l'équipe à l'importance de protéger nos données. Avec DevOps, il est essentiel de poser les bases culturelles d'un changement positif : veiller à ce que chacun comprenne son rôle, sa valeur et ses attentes, les objectifs généraux du projet et les étapes du processus.

Avez-vous maîtrisé cela ? Excellent. Maintenant, changeons d'approche, mettons l'accent sur la sécurité et faisons de DevSecOps le plan définitif pour l'excellence logicielle.