DevOps est une culture, pas un rôle!

Le logiciel est partout. Dans le monde d’aujourd’hui, chaque entreprise / organisation majeure est liée au développement de logiciels et doit se comporter comme telle. La pression est plus forte que jamais pour aller plus vite et pour être plus agile sans sacrifier la sécurité ou la fiabilité. Cette pression se manifeste souvent par un projet annulé ou mis en attente. DevOps cherche à résoudre ce problème: comment amener le développement, les opérations et les autres groupes de l’organisation à collaborer autour d’un ensemble d’objectifs communs, afin de fournir des logiciels plus rapidement et de manière plus fiable aux clients et aux utilisateurs finaux? Les pratiques techniques clés qui sous-tendent une initiative de DevOps consistent notamment à obliger les équipes de développement et d’opérations à normaliser un ensemble commun de processus et d’outils agiles pour la fourniture de logiciels. Ceux-ci incluent souvent:

  • Gestion automatisée de la configuration, tests et déploiement d'applications;
  • Contrôle de version du code de l'application et de l'infrastructure pour permettre la collaboration et les restaurations;
  • CI (intégration continue) pour automatiser la génération de code et permettre un retour et une itération plus rapides grâce à des versions plus fréquentes et moins risquées.

DevOps est un point de vue culturel sur la façon dont chacun devrait être engagé pour travailler de la bonne façon. Dans un monde défini par logiciel, une pile de questions apparaît.

Comment pouvons-nous mettre quelque chose en production rapidement et une fois en production? Comment savons-nous que nous avons trouvé la meilleure solution? Combien de temps pouvons-nous appliquer les améliorations et les mises à jour?

DevOps vise à inclure toutes les personnes ayant un intérêt dans le jeu en les impliquant dès le début du processus de collaboration. Pour réussir, DevOps commence par comprendre les principaux avantages commerciaux. Les entreprises sont en mesure de fonctionner plus rapidement avec moins de temps d'arrêt et moins de problèmes de sécurité.

Mike Dilworth, responsable de la transformation Agile et DevOps, a récemment déclaré:

DevOps est une culture, pas un rôle! Toute la société doit faire DevOps pour que cela fonctionne.

Il faut que les hauts responsables apportent leur soutien, mais également que toutes les personnes impliquées dans le produit final soient impliquées, pas seulement les départements de développement et des opérations.

Auparavant, je lisais un livre blanc de Puppet sur la manière de créer une équipe informatique très performante. Et la section A contenait un ensemble de théories et de pratiques intéressantes que je voudrais partager avec vous.

DevOps couvre profondément les secteurs, les tailles d'entreprise et les environnements technologiques. Néanmoins, il est courant que les responsables informatiques conduisent avec succès des transformations DevOps au sein de leurs organisations. DevOps concerne l’apprentissage continu et l’amélioration plutôt que l’état final.

Construire le business case

Comme de nombreux responsables informatiques, il vous est demandé non seulement de fournir plus de produits et de services que jamais auparavant, mais également de le faire plus rapidement et de meilleure qualité, sans que la fiabilité ou la sécurité ne soit affectée. DevOps semble que ça va vraiment aider! Mais… vous rencontrez le scepticisme de votre équipe avant même d’avoir vraiment commencé.

Comment plaidez-vous clairement et de manière convaincante pour DevOps, qui réduit la peur et transforme les sceptiques en champions?

Commencer par la question ci-dessus est en fait un bon début. La constitution d’une analyse de rentabilisation est un élément crucial d’une transformation réussie de DevOps (en particulier dans les grandes organisations). Dans une célèbre conférence TED, Simon Sinek a souligné le dénominateur commun des grands leaders et des catalyseurs de changements positifs:

Les gens n’achètent pas ce que font ces dirigeants, mais pourquoi ils le font.

La même idée se vérifie lors de la construction d'un engagement organisationnel pour une transformation DevOps. Déclarer simplement “Nous faisons DevOps” ne va pas amener les gens à s’engager. Au lieu de cela, vous avez besoin d’une réponse convaincante aux questions «Pourquoi? Et pourquoi maintenant? Tous nos clients veulent aller plus vite sans compromettre la fiabilité et la stabilité de leurs systèmes, des objectifs qui entrent directement en conflit les uns avec les autres dans les organisations traditionnelles. Les développeurs sont chargés de mettre en production les nouvelles fonctionnalités le plus rapidement possible. Les opérateurs, quant à eux, mesurent le temps de disponibilité et les performances des systèmes. Donc, ces équipes deviennent des adversaires au lieu d’alliés. En conséquence, les déploiements en production sont compliqués par des retards et des erreurs, et ils se produisent beaucoup moins souvent que ce dont l'entreprise a réellement besoin.

Intégration de Dev avec DevOps

Des déploiements plus rapides et des boucles de commentaires vont au cœur de la volonté des développeurs: le code passe de leurs ordinateurs portables aux utilisateurs beaucoup plus rapidement et leur diffusion continue permet une itération et une amélioration rapides. Le suivi des améliorations apportées à votre temps de changement au début du projet pilote est un bon point de départ:

  1. À quelle vitesse le code peut-il passer d’un ordinateur portable de développeur à la production?
  2. Comment cela se compare-t-il à vos délais précédents? (Avez-vous automatisé davantage le processus de construction? Avez-vous réduit le nombre de tickets nécessaires au déploiement?)
  3. Combien de fois déployez-vous maintenant vs alors?
  4. Les déploiements deviennent-ils plus faciles et plus rapides?

Obtenir des opérations avec DevOps

Les avantages Ops lorsque les développeurs travaillent en étroite collaboration avec eux. Il peut être utile de commencer par s’accorder sur une chaîne d’outils commune et de faire en sorte que les deux groupes travaillent ensemble pour adopter les mêmes outils utilisés en développement pour l’intégration, le test et le déploiement du code d’infrastructure. Cela amène les développeurs plus activement dans les déploiements et le dépannage, éliminant davantage les anciennes barrières tout en améliorant la vitesse et la fiabilité. Le suivi de plusieurs métriques qui intéressent Ops soulignera les victoires de toute l’équipe, y compris celles de Dev et de QA:

  • Disponibilité / indisponibilité: Êtes-vous mieux en mesure de répondre à vos exigences de niveau de service? Les temps d'arrêt ont-ils diminué?
  • Changer le taux d'échec: les échecs ont-ils diminué?
  • Temps moyen de récupération: Avez-vous réduit le temps nécessaire pour revenir au dernier bon état connu en cas de défaillance?

Commencez petit et grandissez depuis les premiers succès.

Alors, comment commencez-vous à mesurer ces impacts DevOps et à renforcer votre analyse de rentabilisation? Commencez petit avec des tâches et des projets spécifiques. Cette approche s’est révélée très efficace pour Terri Potts (ingénieur et directeur technique du logiciel chez Raytheon)

Vous ne pouvez pas modifier l’ensemble du programme, mais vous pouvez commencer par amener quelques-unes de vos sous-équipes dans la bonne direction. Il peut être utile de faire appel à quelqu'un de l'extérieur pour automatiser quelques tests ou versions et donner à l'équipe des exemples sur lesquels s'appuyer.

Grâce à l’automatisation de ses versions, Raytheon a permis à l’une de ses équipes de passer de deux procédures d’intégration par mois à en exécuter 27 en une seule nuit. C’est une grande victoire pour une seule initiative et cela fait maintenant partie des arguments plus larges de Potts en faveur d’une croissance des DevOps au sein de l’organisation.

Commencez petit avec le changement de culture, aussi - ne vous attendez pas à vendre DevOps à tout le monde à la fois. En fait, en gagnant des groupes plus petits avec des projets spécifiques, vous créerez des ambassadeurs qui pourront vous aider à promouvoir DevOps ailleurs dans l’entreprise, créant ainsi un effet multiplicateur. Pendant que vous construisez votre analyse de rentabilisation, vous devez également rester conscient des obstacles potentiels au succès à long terme de DevOps.