DevOps signifie que les développeurs assument désormais la responsabilité de l'infrastructure et des versions - mais quels sont les moteurs de ce changement?

18

Je vais mettre mes cartes sur la table: je suis développeur et j'ai travaillé à la fois dans des "DevOps" et des non-cultures. Avoir à se soucier de l'infrastructure et des versions et de l'assurance qualité et de la cérémonie associée est une énorme distraction pour écrire un bon code.

Mais l'industrie évolue dans cette direction, alors quelles en sont les raisons? Quels problèmes l '«ancien» modèle de spécialisation des rôles a-t-il engendrés?

process devops

— Ben
source

4

Voulez-vous dire que la qualité de votre code diminue parce que vous faites d'autres choses ou que la quantité de votre code diminue.

— Caleth

1

Retirez vos cartes de la table, s'il vous plaît. Cela se lit comme une plainte telle quelle.

— svidgen

7

@svidgen Si cette question était purement et simplement une diatribe, ce serait différent mais le PO a le droit d'exprimer son opinion et de poser une question parfaitement valable.

— Robbie Dee

1

@robbie bien sûr. vous remarquerez que j'ai répondu quand même ... mais, la partie "opinion" de cette question consomme plus de la moitié du corps, prise en sandwich entre la même question de base réitérée, et elle distrait de la pureté potentielle de la question de base dans ce cas. Mais oui.

— Ça

19

La raison principale est le cloud.

Auparavant, votre code était livré sur disquette, puis sur CD, puis déployé sur un serveur, puis déployé sur deux serveurs (pour la résilience) ... Et tout ce déploiement pouvait être fait manuellement par un humain, donc les humains ont été formés à le faire.

Aujourd'hui, votre code va souvent sur des dizaines ou des centaines de serveurs. L'approvisionnement, la configuration et le déploiement sur ces serveurs ne peuvent pas être effectués de manière réaliste manuellement par un humain. Vous devez que vos administrateurs système connaissent suffisamment de scripts pour automatiser ce processus, car vous utilisez maintenant Chef ou ses proches. Mais franchement, il n'y avait pas assez d'administrateurs système qui pouvaient le faire. Les développeurs ont donc été amenés à prendre le relais.

Et oui, ajouter plus de compétences aux exigences toujours croissantes des développeurs va naturellement réduire leurs compétences ailleurs. L' idée est qu'en permettant au développeur de mieux comprendre le processus de génération / publication, il peut mieux anticiper les problèmes ou avoir l'autonomie pour l'améliorer. L'idée est que la qualité de tout augmente depuis que les victoires de la version dépassent les pertes d'écriture de code.

Je suis sceptique que le compromis en vaille la peine aussi souvent que les gens le prétendent.

— Telastyn
source

2

Vous m'avez perdu à " La raison principale est le cul ".

— tedder42

15

Il existe de nombreuses raisons pour lesquelles diverses organisations passent à DevOps.
J'essaierai d'énumérer ceux qui reviennent souvent.

Réduire le délai de changement de cycle
Il y a souvent beaucoup de temps entre une demande de changement et son déploiement et son utilisation dans l'organisation. Tout d'abord, il est prévu dans l'un des cycles de développement par les développeurs et après sa livraison, il est prévu dans l'un des cycles de sortie des opérations. Les deux cycles incluent des tests et en cas de problèmes détectés, les deux cycles sont réinitialisés. En intégrant les départements de développement et d'exploitation, nous pouvons rationaliser les deux processus.

Problèmes logiciels vs matériels Vous
vous souvenez du dessin animé Bugs Bunny où Bugs et Daffy se disputent s'il s'agit de la saison des canards ou des lapins? Imaginez maintenant que nous l'avons fait avec des développeurs et des opérations où les développeurs soutiennent qu'il s'agit d'un problème matériel et les opérations soutiennent qu'il s'agit d'un problème logiciel. Pour l'utilisateur final, c'est une distinction sans différence. Ils veulent juste que ce soit réparé.
En réunissant les développeurs et les opérations, ils devront résoudre les problèmes. Et il se peut que ce soit un problème logiciel et matériel.

Nous contre eux
Dans de nombreuses entreprises, la distance entre les testeurs et les développeurs augmentait car ils étaient des départements séparés et le cycle de développement devenait de plus en plus formalisé et standardisé.
Avec l'arrivée d'Agile, les développeurs et les testeurs ont travaillé en étroite collaboration et nous avons commencé à voir le point de vue de l'autre sur le cycle de développement et peut-être même à le respecter.
Quelque chose de similaire doit se produire entre les développeurs et les opérations, car à mesure que les domaines évoluent et que les processus se formalisent et se normalisent davantage, la distance entre ces départements augmente. Ainsi, l'un des problèmes avec le modèle traditionnel est qu'il semble être "nous" contre "eux" pour les développeurs et les opérations. Les deux ne comprennent pas complètement la difficulté des responsabilités de l'autre.

Attentes / avantages
Avec DevOps, les deux spécialités apprendront certaines des compétences traditionnellement exercées par l'autre. Personne ne s'attendra à ce qu'un administrateur système devienne ingénieur logiciel ou qu'un développeur devienne ingénieur réseau, mais les deux devraient assumer certaines des responsabilités de l'autre. Cela signifie que lorsque vous avez vraiment besoin de mains supplémentaires, elles sont là.

Et il y a des avantages certains pour les développeurs: vous avez maintenant plus de contrôle sur vos environnements de test, vous trouverez plus facile de déployer des logiciels pour les utilisateurs et d'avoir plus de personnes dans votre organisation avec qui partager votre amour du métier.

— Miguel van de Laar
source

4

+1 - Parce qu'il s'agit de l'utilisateur final et pas seulement du code.

— JeffO

3

Écrire du code de qualité n'est tout simplement pas suffisant. Vous faites partie du problème ou de la solution.

Pour de nombreux programmeurs, vous écrivez un logiciel payé par un utilisateur final. Écrire du code de qualité est une bonne chose, mais c'est aussi quelque chose que les clients / managers supposent que vous devriez toujours faire et faire rapidement. C'est comme dire qu'un menuisier coupe les planches avec précision, mais est-ce que vous construisez quelque chose pour lequel quelqu'un veut payer?

DevOps donne aux développeurs plus de contrôle et, espérons-le, force leur code à correspondre au résultat final. Qui est le mieux placé pour automatiser le processus d'exploitation? La satisfaction de l'utilisateur final est le principal instrument de mesure. Non seulement vous devez écrire du code de qualité, mais il doit satisfaire le client. Désolé, mais personne ne recommence à utiliser des lignes de code. Ils ne se soucient pas si vous avez construit votre propre cadre ORM à partir de zéro, tout comme l'acheteur moyen ne se soucie pas si vous avez coupé l'arbre et fabriqué vos propres planches. Quelqu'un veut-il refaire tous ses fichiers de configuration parce que votre «mise à niveau» les remet à la valeur par défaut?

Vous voulez montrer vos côtelettes de développeur? Créez quelque chose que les gens veulent acheter et qui inclut toute l'expérience utilisateur. C'est génial que vous écriviez du code de qualité, mais malheureusement, vous ne recevrez peut-être pas de bonus s'il n'est pas publié à la satisfaction du client payant. N'hésitez pas à blâmer l'AQ, mais votre entreprise n'a toujours pas assez d'argent pour vous payer plus.

— JeffO
source

2

Je suis sûr que vous savez combien il est difficile d'embaucher de bons développeurs de logiciels. Et maintenant, nous avons besoin qu'ils soient de bons analystes commerciaux, intéressés par la cérémonie d'AQ et soucieux des processus de publication. Le nombre de personnes qui rencontreront le nouveau bar sera extrêmement faible.

— Ben

2

@Ben: Il n'y a pas de "et maintenant"; ce sont des choses que les bons développeurs faisaient des décennies avant que quelqu'un ne pense que DevOps était une nouvelle chose et a inventé le terme. Votre travail en tant que développeur est de résoudre des problèmes qui vont du besoin d'une solution à quelqu'un pour vous assurer que les personnes qui doivent gérer votre code après l'avoir écrit n'ont pas de mal. Lésinez sur tout cela et personne ne se souciera de la beauté de vos chevilles carrées si elles ont besoin d'un traîneau de dix livres pour les enfoncer dans des trous ronds.

— Blrfl

Cela semble être un argument contre la spécialisation. Qu'une personne devrait être un maître de tous les métiers. Cela n'est suggéré dans aucune autre industrie, vous n'avez pas de couvreurs-briqueteurs-électriciens essayant de comprendre le moindre détail sur la construction d'une maison

— Richard Tingle

2

@RichardTingle: Personne ne dit que vous devez tout comprendre, mais vous devez comprendre les choses que votre produit touchera lors de son utilisation. Un plombier doit en savoir suffisamment sur ce que font les électriciens - ou du moins travailler avec un - pour savoir qu'il n'est pas sûr de faire passer un tuyau d'eau froide à travers une boîte de disjoncteurs, même s'il y a des débouchures disponibles pour le faire.

— Blrfl

Ne prend même pas la peine d'essayer de répondre à la question. -1

— RubberDuck

2

C'est quelque chose qui va de pair avec Agile & Scrum. Il n'y a plus de rôles clairement définis - tout le monde est un "développeur".

Et ce n'est pas seulement des opérations. Les développeurs doivent souvent assumer des fonctions d'analyse commerciale, de test, d'administration de base de données et de gestionnaire de build - la liste est longue.

Au cœur du problème se trouvait ce que l'on pourrait appeler un taux de désabonnement . À mesure que le nombre de rôles différents impliqués dans un projet augmentait, plus il y avait de réunions, de malentendus et de conflits de ressources. Mettre le logiciel devant les utilisateurs rapidement est la fin du jeu et tout ce qui peut éventuellement empêcher cela a quelque peu disparu.

Ce n'est pas entièrement une mauvaise chose. Votre développeur moyen étend ses compétences bien que le bourrage devienne très mince maintenant. Il empêche également les arguments entre les codeurs et les administrateurs de serveur de savoir où se situent les problèmes lors des déploiements. Les développeurs veulent souvent proposer des solutions avec une technologie de pointe et les administrateurs de serveur n'ont souvent aucune idée de ce que cela signifie d'un PDV administrateur jusqu'à ce qu'ils reçoivent l'ensemble d'installation.

Les entreprises plus brillantes et plus avant-gardistes commencent enfin à réaliser que les personnes en forme de T sont une bonne chose. Cependant, il y a une différence entre penser que c'est une bonne chose et s'attendre à ce que cela se produise comme par magie là où une culture traditionnelle avait déjà été adoptée.

— Robbie Dee
source

-1 "ne sont plus des rôles clairement définis - tout le monde est développeur." Cela ne veut pas du tout vrai. Une équipe Scrum est censée être composée d'un ensemble diversifié de personnes, qui comprend des développeurs, des graphistes, des informaticiens, etc. Les rôles ne disparaissent pas, mais l'idée est maintenant qu'ils sont tous dans une seule équipe, pas départements séparés.

— Andy

1

@Andy, je vous suggère de relire le guide Scrum : Scrum ne reconnaît aucun titre pour les membres de l'équipe de développement autre que développeur, quel que soit le travail effectué par la personne; il n'y a aucune exception à cette règle . Les gens se spécialisent bien sûr mais de par sa nature même, il est censé être une entité auto-organisatrice.

— Robbie Dee

Appeler quelqu'un qui a pour spécialité la création de graphiques dans Photoshop, ou quelqu'un qui a un rôle de traduction, un développeur est trompeur car le développeur dans les projets logiciels est universellement compris comme un développeur de logiciels. Le guide de mêlée est tout simplement faux avec cette déclaration.

— Andy

0

Je suis sûr qu'il y a plus que quelques bonnes raisons pour les développeurs de gérer également les opérations et le contrôle qualité (parfois). En voici trois:

Intérêt
Certains développeurs souhaitent réellement travailler tous les aspects du produit. S'ils sont bons dans ce domaine et s'ils comblent un vide dans l'équipe ou fournissent un bon soutien aux membres de l'équipe existants dans d'autres rôles, il n'y a peut-être aucune raison de les arrêter.
Coût Les
grandes entreprises peuvent se permettre des employés spécialisés. Les petites entreprises ne le peuvent parfois pas. Certains de ces endroits peuvent embaucher 1 ou peut - être 2 ou 3 développeurs qui doivent être en mesure de simplement obtenir des informations pratiques.
Taille du projet
Tous les projets ne sont pas des projets à plusieurs personnes. Si vous créez une "petite" application, il peut être tout simplement exagéré de demander à plus d'une personne de la faire fonctionner. Plus encore, les petits projets avec de nombreuses personnes occupant des rôles spécifiques font peur . Personne n'a assez de travail à faire - même si vous pouvez vous permettre de les garder tout autour pour tourner leurs pouces pendant 6 mois, les bons ne resteront pas. S'ils ne s'ennuient pas, ils auront peur, ou vous vous rendrez compte que vous payez pas mal pour rien. Quoi qu'il en soit, vos bons employés partiront et diront à tout le monde de rester loin de vous.

... Et pour d'autres raisons, j'en suis sûr.

— svidgen
source

0

"Le fait de devoir se soucier de l'infrastructure et des versions et de l'assurance qualité et de la cérémonie associée est une énorme distraction pour écrire un bon code"

En son cœur, je pense que DevOps dit que se soucier de l'infrastructure et des versions et du QA EST d'écrire du bon code.

Dans les rôles précédents opérant dans des cultures non DevOps, j'ai eu de nombreux problèmes qui, sans doute, une culture DevOps aurait pu empêcher; problèmes de performances liés au code développé sur des plates-formes non représentatives, problèmes de codage de caractères où les développeurs ignoraient les codages de caractères utilisés par un client, instructions de déploiement codées à la main et insuffisantes pour l'équipe Ops sans un certain degré de conjecture -travail.

Maintenant, vous pourriez faire valoir que la spécialisation accrue des côtés Dev et Ops nous permet de surmonter certains d'entre eux, mais encore beaucoup ne peuvent être résolus que par un certain partage des connaissances et du travail entre nos équipes.

— freake mat
source

0

DevOps ne doit pas signifier "Dev maintenant faire aussi Ops". Le terme signifiait à l'origine "les gens Dev et Ops travaillent ensemble étroitement dans une seule équipe". Il ne signifie pas que les gens ont besoin Ops pour devenir plus comme Devs, parce que l' automatisation des choses exige une sorte de programmation, et l'ancienne façon manuelle ne coupe pas (voir les autres réponses pour l' élaboration plus détaillée sur ce point).

De Wikipédia :

DevOps (un composé coupé de développement et d'opérations) est une culture, un mouvement ou une pratique qui met l'accent sur la collaboration et la communication des développeurs de logiciels et d'autres professionnels des technologies de l'information (TI) tout en automatisant le processus de livraison de logiciels et les changements d'infrastructure

Donc, à mon avis, en fait, si vous, en tant que développeur, avez les mêmes anciennes responsabilités et en plus maintenant des responsabilités opérationnelles, cela semble être un mauvais calcul de la part de la gestion. En automatisant les choses, il est tout à fait possible que vous ayez besoin de moins de personnes Ops et donc il y a réellement des économies de coûts. Mais DevOps ne signifie certainement pas "Débarrassons-nous de toutes les personnes Ops et laissons les Devs faire le travail supplémentaire".

Comme si souvent avec Buzzwords, une diffusion sémantique se produit, et tout à coup les gens pensent "Faisons aussi des devs des Ops, et je suppose que nous pouvons économiser de l'argent ..."

— jhyot
source