DevOps est (était) un mot nouveau (pour moi), j'ai un peu cherché ce qu'il signifiait et malgré une certaine dose de buzz commercial, j'ai apprécié le fait qu'il existe.
En effet c'est un mot assez flou désignant une branche de la méthode agile mais qui est bien plus fortement accroché à l'open-source puisqu'elle peut être utilisé aussi pour désigner des groupes de logiciels open-sources utilisés ensemble pour améliorer le cycle de tests des systèmes.
Voici une vidéo exemple:
https://vimeo.com/album/3444365/video/130717121
Si les mots commencent à associer les méthodes de développement avec l'open-source, c'est que le logiciel industriel prend le bon chemin. Pour vous c'est sans doutes une évidence mais je suis souvent très pessimiste.
Cela me fait plaisir qu'il y ait du concret bien palpable prouvant la progression du libre.
# Ma compréhension
Posté par Ph Husson (site web personnel) . Évalué à 10.
Je peux être à côté de la plaque, mais ma compréhension du terme est très différente.
Pour moi, DevOps désigne les administrateurs systèmes qui travaillent comme des développeurs:
Par exemple:
Une configuration est sous git, et faire le git push déploie automatiquement la configuration partout.
Une nouvelle machine à déployer prend quelques minutes au devops.
Il existe des branches master et des branches "stables", les branches master étant les systèmes "en dév"
Et ensuite, il y a des outils de tests continu d'intégration pour vérifier sur la branche master que rien n'est cassé
Il se trouve que les outils les plus couramment utilisés pour ce type de développement est docker, lxc, ou plus basiquement des scripts autour de debootstrap, et il est plus difficile de faire la même chose sur des systèmes propriétaires, donc il se trouve que la majorité des DevOps utilisent des outils libres, mais il n'y a pas de lien dur entre DevOps et libre.
[^] # Re: Ma compréhension
Posté par clownix (site web personnel) . Évalué à 2.
J'ai peut-être fait quelques erreurs, c'est assez flou comme terme…
J'avais justement envie d'en parler pour avoir plus de précision venant de réactions…
[^] # Re: Ma compréhension
Posté par Ellendhel (site web personnel) . Évalué à 3.
Comme probablement d'autre personnes j'ai eu un peu de mal a avoir une définition claire de ce que peut représenter le terme DevOps ; plusieurs personnes ou organisations y vont de leur point de vue.
Suite à une recommandation de Tom Limoncelli (auteur, entre autre, de Admin'sys - Gérer son temps…) j'ai lu le roman "The Phoenix Project" à ce sujet.
Oui, c'est un roman, pas un guide technique, le protagoniste principal se retrouve propulsé responsable informatique et doit gérer une situation de crise sans trop savoir comment s'y prendre et c'est dans ce contexte qu'il découvre et décide de changer les méthodes et les outils utilisés. Le côté "fiction ¹" rend les choses faciles à lire (pour qui lit l'anglais) et l'histoire est assez prenante. L'inconvénient est que l'on se retrouve sans "fiche pratique" et qu'il est plus difficile d'utiliser le livre comme référence par la suite.
Et on voit bien que la méthode DevOps ne concerne pas seulement les outils techniques (virtualisation/containers, tests, gestion de configuration, …) mais aussi la communication entre les membres d'un même équipe et avec le reste de l'organisation.
Je n'ai pas appliqué de méthode DevOps à proprement parler là où je travaille (la structure n'est pas suffisamment importante) mais il y a un certain nombre d'idées que j'ai essayé de mettre en place et certaines ont vraiment apporté des améliorations.
1) si vous avez un peu d'expérience dans le domaine, vous reconnaîtrez certaines situations comme très réalistes
[^] # Re: Ma compréhension
Posté par Krunch (site web personnel) . Évalué à 2.
Je ne comprend pas ton raisonnement. Dans une boîte précédente de 30 personnes on était deux « devops » et ça me semblait tout à fait approprié. Après, le terme est suffisamment flou pour que différentes personnes y voient des rôles et méthodologies qui ont assez peu de rapport les uns avec les autres.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ma compréhension
Posté par Victor . Évalué à 3.
J'avais compris la même chose, voire inclure du développement de logiciel (pas juste l'utilisation de git et d'environnement de dev versus prod) à des fins d'administration mais aussi pour faire marcher les trucs administrés.
C'est en fait un terme qui fait penser à la distinction entre configuration et développement : à partir de quand une activité n'est plus de la configuration (genre modifier httpd.conf) et devient du développement (genre coder des règles de routage métier pour intégrer des applications entre elles).
J'en avais entendu parler dans le cadre du "BigData" : il y a besoin de coder des trucs pour faire transiter de la donnée en grande quantité entre différentes applications (tranformation, filtrage, optimisation, etc), et ce sont les DevOps qui s'occupent de ça.
[^] # Re: Ma compréhension
Posté par clownix (site web personnel) . Évalué à 2.
Donc je croyais à une méthodologie, puis j'ai cru à un groupe d'outils open-sources, la première réaction au journal montre plutôt que c'est un type d'administrateur, et enfin j'ai presque l'impression que c'est un métier se situant entre la configuration, le développement et le test continu.
Le mot a plusieurs facettes.
[^] # Re: Ma compréhension
Posté par Victor . Évalué à 3.
Oui, moi je découvre complètement l'aspect organisationnel derrière le terme, c'est intéressant tout ça :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Exemple concret
Posté par laviestbelle . Évalué à 2.
Il vient tout juste d'y avoir une devOps alloué pour le projet servo de Mozilla (plus besoin de le présenter)
C'est expliqué dans ce blog http://blog.servo.org/2015/05/28/twis-33/
Ou plus précisément en cliquant sur le nom de la devOps qui redirige sur son blog ou elle explique concrètement à quoi elle sert et en quoi elle n'est pas qu'un bullshit marketing :)
Après je comprends rien à l'anglais donc il se peut que j'ai mal compris à coups de Google traductions mais ça me paraît peu probable et sinon oui je trouve ça merveilleux que ça soit bien plus propice à l'open source !
[^] # Re: Exemple concret
Posté par clownix (site web personnel) . Évalué à 2.
En effet le lien:
http://edunham.net/2015/05/20/open_infrastructure.html
est assez intéressant, merci.
# mouvance
Posté par Nico C. . Évalué à 10. Dernière modification le 20 juin 2015 à 17:01.
Devops ne designe pas les outils mais plutot les gens et leur maniere de travailler. Mais en fait, ca designe plus des principes qu'une reelle methode ou un poste défini.
DevOps est la contraction de Developer - Operations (dans le sens "exploitant"). Autrement dit, c'est la reunion des dev et des admins sys grosso modo et ca provient effectivement des methodes Agile.
En fait, il y a un constat depuis longtemps stipulant que c'est bien d'ameliorer la qualité logicielle et d'accelerer fortement les cycles de release mais si les types qui mettent en prod et gerent la prod ne suivent pas, ca sert a rien.
Un autre constat aussi est que bien souvent les dev travaillent dans le monde ou il faut produire vite, changer les choses vite et d'un autre ou la production necessite au contraire de la stabilité. Ainsi les equipes ont tendance a fonctionner en silos ou chacun reste de son coté de la barriere et ne communiquent que via des livrables ou des tickets d'incidents.
Une derniere chose aussi, quand on est une startup, on a souvent peu de ressources et donc ce sont les devs qui font un peu tout donc ils codent mais ils doivent aussi se sortir les doigts pour gerer leur prod. Donc ils ont vite compris que l'integration, les tests de charge/perf/dispo, la doc, le packaging, etc sont aussi importants que les nouvelles fonctionnalités et les corrections de bugs. Et d'un autre coté, celles qui embauchaient des admins sys les integraient au sein des equipes des dev et ils devaient aussi se sortir les doigts pour etre aussi "agiles" que les copains
Bref, tout ca melangé a fait que les equipes de prod et de dev se sont sérieusement rapprochées les unes des autres au point que certains sont à cheval sur les 2. Dans tous les cas, l'idee est que les dev et les ops doivent travailler ensemble et pas les uns "contre" les autres comme c'est trop souvent le cas.
Ainsi, pleins d'outils pour automatiser et provisionner des plateformes entieres (puppet, ansible, etc), faire des contenaires (docker), piloter des solutions de virtualisation par fichiers et scripts (vagrant) sont apparus, les admins sys se sont appropriés Git, etc
Au point qu'aujourd'hui, un devops "code" son infra : il la décrit dans des fichiers comme un dev code ses fonctionnalités. Puis il execute ses outils comme on compilerait du code et il obtient un resultat (une infra avec une configuration specifique) unique et reproductible.
Apres, les principes sont hyper interessants mais les outils sont encore en heavy dev. Autrement dit, ca bouge enormement en ce moment et c'est difficile de se tenir à jour. Et la qualité des outils est parfois variable… Quand on est un admin sys pur souche et qu'on cherche a embrasser cette maniere de faire, c'est parfois un peu rugueux et ca choque de confier son infra a des outils qu'on sait etre encore un peu verts. Et surtout, ca n'ote pas la necessite de bien connaitre et savoir parametrer les services qu'on installe donc ca fait une couche technique supplementaire a connaitre et maintenir.
De plus, cette facon de faire ne s'applique pas partout et dans tous les contextes pro. Ca marche bien quand les devs sont deja en agile avec des technos modernes. Ca marche moins bien quand il y a un vieil existant produit et géré "à l'ancienne" (enfin, ca pourrait marcher mais le ticket d'entrée est tres lourd pour mettre ca en place).
C'est extremement bien adapté au Cloud (type AWS par exemple).
Au final, pour moi, c'est une vraie revolution dans le monde et dans le petit train-train de l'exploitation/production et des admins sys en general. Une revolution équivalente à l'arrivée de la virtualisation, je pense.
C'est vraiment passionnant et ca nous (les sysadmins) oblige a remettre en cause nos manieres de faire et de voir les choses. D'un autre coté, ca force aussi les devs a prendre en compte le cycle de vie entier de leur code et pas s'en laver les mains une fois que le zip a ete balancé a l'exploitation.
Je pense que tout le monde y gagne a se serrer les coudes et travailler ensemble…
Désolé pour le pavé :)
[^] # Re: mouvance
Posté par clownix (site web personnel) . Évalué à 2.
Désolé pour le pavé :)
C'était bien agréable à lire, j'ai bien l'impression que les métiers changent de plus en plus vite, la productivité dans les systèmes complexes augmente assez vite, la formation se fait sans prof, sur le web, de nouveaux mots/concepts sont inventés, encore trop jeunes pour être clair, mais c'est plutôt bon signe, ça bouge…
[^] # Re: mouvance
Posté par dricounet . Évalué à -1.
Bonjour,
Je souhaitais répondre à la partie "révolution", car tu te trompes :
Quand j'ai commencé à travailler, en 1997, le DevOps existait déjà (un mec - ou une fille, hein ! - qui poussait ses développements en production et en assurait l'exploitation), et c'est la qualité qui a cloisonné ce petit monde (ITIL, CMMI et maintenant AGILE).
Comme quoi, comme dirait Big Blue, l'informatique est cyclique.
Même si, je te l'accorde, une grosse différence existe ; Le DevOps d'aujourd'hui s'appuie d'avantage sur des outils de déploiement (Deployt chez nous), mais il assure l'exploitation de ses développements.
Sinon, concernant la virtualisation :
La virtualisation, cela devrait te rappeler le principe des "gros systèmes" du même grand bleu - qui a un gnon d'ailleurs ! ;)
PS : A ce propos, personnellement, ayant travaillé un peu partout en Europe, ce cloisonnement a fortement nuit et aux ingénieurs français qui étaient généralistes - avec un ou plusieurs domaine de prédilection, et qui maintenant se spécialisent davantage à l'instar des ingénieurs anglo-saxons et teutons.
[^] # Re: mouvance
Posté par Nico C. . Évalué à 2.
Non, je ne suis pas d'accord. Dans les DSI avec assez de personnels, les equipes dev et ops etaient deja bien separées a cette epoque. Et meme avant ca encore. Y'avait que les petites boites sans admin sys qui laissaient le(s) dev s'occuper de l'exploitation. A ce niveau, y'a pas grand chose de different avec aujourd'hui. Mais ce dev là n'est pas un "devops" pour autant.
C'est une enorme difference pour moi… Et au dela de l'outillage de deploiement, il y a aussi tout l'outillage de developpement, de test et l'automatisation des worklows. C'est CA la vraie difference entre un dev qui faisait de l'operationnel y'a 20 ans et un devops aujourd'hui.
D'ailleurs, un devops "pur jus" (note les guillemets) est justement là pour travailler sur la partie automatisation (des devs, des tests, de la fabrication des environnements et du deploiement) grace a ses connaissances du fonctionnement interne de l'appli ET du systeme.
Faut arreter, les gros systèmes et la virtualisation n'ont pas grand chose à voir. Oui, l'innovation s'appuie toujours sur ce qui existe déjà, c'est evident et la virtualisation n'est pas sortie du chapeau d'un soit-disant genie en pleine crise de "disruptive innovation". MAIS il n'empêche que la virtualisation a bien plus revolutionné le monde que les gros systemes. Ne serait-ce que par son accessibilité…
Les gros systemes ont toujours ete reservés aux tres grands groupes. La virtualisation est accessible à n'importe qui et touche TOUS les admins systemes aujourd'hui. Le Cloud est le rejeton de la virtualisation, pas des gros systemes.
Moi, je veux bien qu'on cherche à établir des liens entre les differentes grandes phases d'innovation car c'est bien de savoir d'ou les choses proviennent mais faut pas non plus partir dans l'extreme en disant qu'il n'y a pas plus d'innovation aujourd'hui que ce qu'on avait y'a 20 ou 30 ans. C'est une erreur car meme si on ré-utilise des anciens concepts, ce n'est ni de la meme facon, ni pour le meme usage ni pour le meme prix.
Innover en creant de nouveaux concepts est evidemment le plus prestigieux mais faut pas negliger l'innovation sur la maniere d'implementer un concept, sur la maniere de l'utiliser et sur les couts.
C'est toute la difference entre une grande banque avec un gros systeme dans les annees 80 et une startup qui peut centupler de taille en 1 an avec AWS en 2015.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.