Blog

Transition vers un modèle DevOps

par David Shackelford 22 janvier 2015 | 6 minutes de lecture

Nous sommes heureux de republier cet article de David Shackelford . L'article a été initialement publié sur DevOps.com .

À mesure que le rythme du développement et des activités s'accélère, les équipes ont besoin d'un environnement de travail agile et collaboratif pour réussir. Passer à un modèle DevOps est un élément essentiel pour permettre à vos équipes d'ingénierie de réussir, mais cette transition peut s'avérer difficile pour de nombreuses entreprises.

Quel est le problème ? – Pourquoi avez-vous besoin d’un modèle DevOps

Le DevOps est un mouvement du monde du logiciel qui met l'accent sur la collaboration entre les développeurs et les équipes opérationnelles, l'empathie envers les clients et l'automatisation de l'infrastructure. Dans les modèles traditionnels, les développeurs écrivent du code, puis le transmettent aux équipes opérationnelles pour qu'elles le déploient et l'exécutent dans un environnement de production. Cela conduit souvent à un manque de responsabilité entre les deux équipes (« Cela a fonctionné sur ma machine locale ! ») ainsi qu'à un rythme de développement plus lent. Dans un modèle DevOps, en revanche, les deux équipes travaillent en étroite collaboration et vers des objectifs communs orientés client : les développeurs s'approprient leur code même lorsqu'il est en production, et les équipes opérationnelles créent des outils et des processus qui aident les développeurs à écrire, tester et livrer du code plus rapidement et plus facilement.

En brisant les barrières traditionnelles entre développeurs et opérations, le développement se déroule plus rapidement et avec plus d’empathie envers le client, ce qui se traduit au final par une meilleure expérience client et une équipe plus heureuse. Plutôt que de considérer l’autre équipe comme une barrière ou un obstacle, si tout est fait correctement, les développeurs et les opérations se voient comme des coéquipiers qui travaillent pour apporter de la valeur au client et à l’entreprise.

Malheureusement, il n'est pas facile d'introduire la culture et les pratiques DevOps dans votre entreprise. Les grands changements apportés à des silos bien ancrés peuvent générer de la résistance, et les chefs d'entreprise ont souvent peur des coûts qu'implique ce changement. Pour lutter contre ces inquiétudes et ces hésitations, nous avons mis en évidence quelques conseils pour la transition vers un modèle DevOps.

Commencez par la collaboration : qu’est-ce qui fonctionne et qu’est-ce qui ne fonctionne pas ?

Au cœur de DevOps se trouve une collaboration améliorée entre vos équipes d'exploitation et de développement. Mais vous ne partez probablement pas de rien : examinez et discutez des meilleurs exemples de collaboration actuelle entre vos équipes d'exploitation et de développement logiciel. Existe-t-il des groupes de développement/d'exploitation particuliers qui travaillent déjà en étroite collaboration, qui favorisent une excellente communication ou qui effectuent une planification conjointe ? Se concentrer sur ce qui fonctionne déjà et sur la manière de l'améliorer, plutôt que sur ce qui ne fonctionne pas, permet de garder une certaine positivité et d'augmenter les chances de réussite.

Vous pouvez organiser une séance de brainstorming de groupe pour discuter ou avoir des conversations individuelles avec les membres de l'équipe, selon le format qui, selon vous, aidera les gens à s'ouvrir plus facilement. article met en évidence les opportunités de collaboration tout au long du cycle de vie de livraison des applications et pourrait fournir un cadre utile pour poser des questions et identifier les opportunités.

Outre l'état de la collaboration, vous devrez également rechercher les réussites et les échecs des processus dans la manière dont vous déployez et maintenez les applications, les services et l'infrastructure. Identifiez les plus grandes opportunités d'amélioration : vos builds et vos tests prennent-ils des heures ? Vos 20 équipes de développement sont-elles toutes en concurrence pour les mêmes trois environnements de test ? Être capable de quantifier l'impact de ces points faibles peut aider à défendre la transition auprès des parties prenantes de l'entreprise qui n'ont peut-être pas autant de contexte sur le terrain concernant les points faibles de vos équipes.

Il est également important de comprendre les différentes perspectives que peuvent avoir les équipes d'exploitation et de développement. Si votre organisation a toujours été très cloisonnée, penser aux objectifs des autres équipes lors de la planification et de la priorisation peut être un nouvel état d'esprit. Partager les objectifs de chaque équipe et ce à quoi ressemble le succès pour eux peut aider à développer cette compréhension et cette empathie. Concentrez-vous sur la transparence (un cadre comme OKR (peut aider) à éviter les conflits dus à des hypothèses incohérentes sur les priorités.

Créer un plan

Une fois que vous avez identifié les opportunités d'amélioration de la collaboration et du flux de travail entre les développeurs et les opérations, il est temps de créer un plan spécifique. Choisissez les opportunités clés et identifiez les premières étapes pour faire la différence. Courtney Nash recommande de commencer avec un groupe de personnes réceptives à la vision et de choisir un petit produit ou service comme banc d'essai. Lors de la mise en œuvre de grands changements, il est utile de commencer petit et de progresser à partir de là après avoir prouvé le succès.

Les ingénieurs ne sont pas toujours réputés pour leurs compétences relationnelles, mais la transition vers DevOps est autant une question de personnes que de processus et d'outils. Tout au long de ce processus, vous devrez impliquer les principales parties prenantes de votre équipe et de votre entreprise dans la transition. La gestion du changement peut sembler très corporatiste, mais au fond, il s'agit de s'assurer que vous obtenez le soutien de vos projets et de vos objectifs en recueillant les commentaires des principales parties prenantes : recueillir leurs commentaires et leurs objectifs, partager et remodeler votre plan en fonction de leurs commentaires, et communiquer vos progrès avec elles. Il est toujours plus facile de travailler en vase clos avec des personnes qui sont déjà d'accord avec vous, mais pour un changement durable, vous devrez investir dans le renforcement du soutien entre les équipes et dans toute votre organisation.

Enfin, choisissez des échéanciers et des objectifs réalistes. Il est important de noter que certains effets du changement peuvent prendre plus de temps à se faire sentir à mesure que les employés se familiarisent avec de nouveaux outils et méthodes de travail. Ne sous-estimez pas ou ne négligez pas le temps nécessaire à la formation et essayez de ne pas vous laisser décourager si le premier projet que vous choisissez ne s'avère pas être le bon. Comme le mentionne Courtney Nash, Nordstrom.com a réalisé que son premier projet n'était finalement pas le bon pour commencer. Surtout, ils n'ont pas abandonné, choisissant plutôt une application différente et mieux adaptée.

Mesurer et réfléchir

Bien qu'il soit rare que les échéanciers des systèmes complexes se déroulent exactement comme prévu, il est important de définir un calendrier pour votre travail afin de pouvoir mesurer et réfléchir à son déroulement.

Après l'étape spécifique que vous avez choisie, réunissez les parties prenantes et organisez une rétrospective. Il y a il existe de nombreuses ressources intéressantes pour vous aider à réaliser de bonnes rétrospectives, mais quelle que soit l'approche, assurez-vous de créer un espace intentionnel pour examiner de manière critique vos résultats, célébrer le succès et réfléchir à la manière dont vous aimeriez modifier ou itérer le processus pour l'avenir.

Lorsque vous réfléchissez aux progrès réalisés, il est important d'être franc et honnête tout en supposant que vos coéquipiers ont les meilleures intentions. Vous ferez certainement des erreurs – c'est inévitable avec tout nouveau processus – mais n'oubliez pas (et aidez les autres à s'en souvenir) que vous travaillez tous vers le même but et partagez un ensemble de valeurs et d'objectifs communs.

N'abandonnez pas

Adopter DevOps est un changement important pour une entreprise, et il y aura des obstacles sur la route. Au bout du compte, les bénéfices d’une collaboration plus étroite entre les équipes et d’une culture d’ingénierie plus axée sur l’empathie peuvent être très importants et se refléteront dans la qualité du produit, la rapidité et le moral de l’équipe.

eBook_440_220