Discussion :

[Engiwip]

Ah la la, merci tout le monde!

Donc en gros ça serait pas un frein pour repartir dans le monde du dev pur?

ah c'est sur tu ne vas pas faire de la POO et çà risque d'etre moins creatif ( encore que...)

mais tu peux etre assez malin pour tout scripter et il y a de quoi jouer avec tout et (surtout) n'importe quoi.

Bon allez je te dis la vérité : Pour moi les VRAIES differences

c'est que tu risques de commencer à bosser à partir 18h ou quand tous le monde part en we.
et tu n'auras plus d'amis dev et tu ne seras pas encore assez pote avec les sysadmins mais tu seras peut etre le seul a faire la difference entre un fichier source et un fichier binaire .
tu devras reapprendre à te servir d'une souris plutot que de jouer du piano sur ton clavier. çà peut etre un avantage...

ah et tu ne seras plus une réelle valeur ajoutée. On se demandera meme ce que tu fais vraiment pour cette société.
voilà faut aimer

( je suis désolé fallait que je t'avertisse )

[javain]

Tu as mis le doigt sur un autre truc qui me fait peur aussi.

Je me dis qu'entre un dev et un devops, le plus indispensable c'est le dev, non?

Disclaimer: si tu es devops et que tu passes par là, sache que je n'ai aucune haine contre toi

[foetus]

Je me dis qu'entre un dev et un devops, le plus indispensable c'est le dev, non?

Factuellement ce sont tous les 2 des Bac+3 (technicien) : donc professionnel en informatique, jeune diplômé, reconverti, alternant, chômeur, chômeur de longue durée, ... tout candidat "scientifique"/ "passionné" peut-être pris [formé].
dev, devops, ... c'est juste un titre dans un contexte informatique précis avec un périmètre d'actions + ou - défini.

Mais les ESNs ont du mal à recruter (à ce que j'ai compris ) des devops, parce qu'aucun administrateur ne veut coder et aucun développeur ne veut administer.

[javain]

PLus je lis de messages, plus je déprime

C'est quoi le débouché après devops? La cybersécurité? Vu que c'est max de réseau.

[foetus]

La cybersécurité? Vu que c'est max de réseau.

La formation ParisCode avec la mairie de Paris, c'est juste lire des trames Wireshark et installer des pares-feu ("firewalls") : donc tu sais niveau notion réseau, c'est proche zéro

[javain]

La formation ParisCode avec la mairie de Paris, c'est juste lire des trames Wireshark et installer des pares-feu ("firewalls") : donc tu sais niveau notion réseau, c'est proche zéro

Mais dans les ESN, particulièrement les grandes, c'est plus poussé non?

[Marco46]

Bon allez je te dis la vérité : Pour moi les VRAIES differences

c'est que tu risques de commencer à bosser à partir 18h ou quand tous le monde part en we.
et tu n'auras plus d'amis dev et tu ne seras pas encore assez pote avec les sysadmins mais tu seras peut etre le seul a faire la difference entre un fichier source et un fichier binaire .
tu devras reapprendre à te servir d'une souris plutot que de jouer du piano sur ton clavier. çà peut etre un avantage...

ah et tu ne seras plus une réelle valeur ajoutée. On se demandera meme ce que tu fais vraiment pour cette société.

Tu confonds Ops et DevOps.

Le Ops gère l'infra et les applis installées dessus et souvent il y a une section dédiée à gérer exclusivement preprod et prod.

Le DevOps automatise (programme donc) leur déploiement depuis un registre de binaires.
Il automatise aussi le build des Dev vers le registre.

Ce n'est pas son rôle de manager concrètement les environnements, il fournit les outils pour le faire.

La plus value du DevOps est énorme, tout va plus vite et est plus simple. On build un livrable et on le déploie dans l'environnement voulu en quelques clics, on rollback une version foireuse en quelques clicks, etc ...

Dans ce contexte, le DevOps a les mêmes horaires que la team et devrait d'ailleurs être intégré aux features teams mélangeant devs, fonctionnels, CdP, etc ...

[Marco46]

Mais les ESNs ont du mal à recruter (à ce que j'ai compris ) des devops, parce qu'aucun administrateur ne veut coder et aucun développeur ne veut administer.

Non c'est parce qu'il faut beaucoup de compétences transverses à tous les métiers de l'IT et qu'il faut beaucoup d'expérience (il faut avoir vu des projets de bout en bout pour connaitre le cycle de vie d'un projet).

Mécaniquement il s'agit d'une ressource rare.

[fiftytwo]

Bonjour les enfants , vu qu'on parle de devops , je pose mes co**lles sur la table

Bonjour à tous!

J'ai une opportunité qui s'ouvre actuellement en tant qu'ingé devOps SAUF que je ne comprends vraiment pas le métier.

Quelqu'un peut m'expliquer? Est-ce qu'il y a une bonne part de code? Par exemple si je veux arrêter devops un jour, c'est facile de devenir développeur?

Pour faire ultra simple , devops c'est une philosophie et une maniere de faire les choses a cheval entre dev et ops , comme explique par marco46

Tu as une idee des technologies utilisees dans cette boite/equipe ?

Les soucis du devops en 2019

1. peu de vraies ressources competentes (dans le sens aussi a laise en dev qu'en ops)
2. les boites s'imaginent que devops est le mot magique qui va transformer du caca en google
3. beaucoup de boites ne sont pas pretes pour cela , et rome ne s'est pas faite en un jour avec des chants lyriques
4. comme dit plus tot = ops et dev bossent ensemble sans trop se melanger , dans les grosses boites c'est pire
5. demander 3 ans sur des softs qui existent depuis 5 ans et ne sont vraiment utilises a grande echelle en entreprises que depuis 2/3 ans
6. chaque boite fait sa sauce , donc la liste des competences requises va varier d'un bout a l'autre

sinon va voir cette discussion , peut etre que les questions que tu te posent ont deja recues une reponse

https://www.developpez.net/forums/d1...tant-adminsys/

Je me dis qu'entre un dev et un devops, le plus indispensable c'est le dev, non?

Non , en fait les deux sont necessaires


pas d'ops = pas de systemes pour heberger ton app
pas de dev = pas de nouveau logiciel et personne pour lentretenir

tu vas me dire que le dev peut mettre en place les systemes = oui sauf que sa connaissance est limitee , il droit au but (pas comme marseille cette saison) sans considerations/conaissances pour les aspects securite/fiabilite

PLus je lis de messages, plus je déprime

C'est quoi le débouché après devops? La cybersécurité? Vu que c'est max de réseau.

Non , cybersecurite c'est autre chose , quand tu fais du devops , tu dois aussi avoir des connaissances en securite pour au moins eviter de faire de la m*rde et appliquer quelques normes du metier

Il y a aussi du devsecops , cest donc a cheval entre les 3 , je ne sais pas ce que ca pese , mais on dira devops avec une grosse poudree de securite

[Engiwip]

Tu confonds Ops et DevOps.

Le Ops gère l'infra et les applis installées dessus et souvent il y a une section dédiée à gérer exclusivement preprod et prod.

Le DevOps automatise (programme donc) leur déploiement depuis un registre de binaires.
Il automatise aussi le build des Dev vers le registre.

Ce n'est pas son rôle de manager concrètement les environnements, il fournit les outils pour le faire.

La plus value du DevOps est énorme, tout va plus vite et est plus simple. On build un livrable et on le déploie dans l'environnement voulu en quelques clics, on rollback une version foireuse en quelques clicks, etc ...

Dans ce contexte, le DevOps a les mêmes horaires que la team et devrait d'ailleurs être intégré aux features teams mélangeant devs, fonctionnels, CdP, etc ...

ah non je confonds rien du tout , je lui dis ce qui se passe en pratique !

En pratique presque aucune chaine n'est automatisée ! le devops reste une promesse d'infra dans 80 % des cas !

et surtout rien n'est vraiment standardisé et les premieres étapes c'est de rajouter de la dette technique au milieu de la chaine par l'intermediaire d'un mec qui a tout pouvoir sur les mises en production : le "devops"

C'est aussi le gars qui bouscule les habitudes de "pépère l'admin Robert" en venant lui fourguer de nouveaux outils avec des agents qui doivent avoir des droits speciaux sur certains environnement , voir carrement de revoir les procédures ..

j'invente rien par exemple
un des concepts comme jenkins ( et ses 1400 plugins ) permettent de faire tout et n'importe quoi , mais quand l'admin Jenkins n'est pas là ...tous le monde est dans la mouise

d'ailleurs on surnomme l'admin jenkins le jenkinstein dans certains endroits ...
https://thenewstack.io/devops-world-...ative-jenkins/

alors je ne dis pas qu'il n' y a pas des progrès fulgurant dans le domaine de l'automatisation des tests , etc. , l'arrivée de docker partout qui bouscule encore les façons de faire
mais le combo "click click suivant suivant terminé allez zou je pars en we " ....hum. pas vraiment.

il y a quelques pipelines qui se font de maniere automatique mais faut pas se leurrer , à la fin le devops doit assurer que les derniers binaires de prod match avec les dernieres données de prod

parce que le devops au niveau de la base de données c'est pas çà du tout.
a moins que tu sois dans un groupe de competition style Netflix, FB ou Orange et encore
alors c'est bien joli les concepts mais tu te barres jamais en meme temps que les dev
un devops dans une boite moyenne c'est plus un admin ++ que du dev.

[Marco46]

ah non je confonds rien du tout , je lui dis ce qui se passe en pratique !

En pratique presque aucune chaine n'est automatisée ! le devops reste une promesse d'infra dans 80 % des cas !

En pratique dans ton organisation.

Comme le dit fiftytwo, DevOps c'est une culture et une orientation, un but à atteindre.

et surtout rien n'est vraiment standardisé et les premieres étapes c'est de rajouter de la dette technique au milieu de la chaine par l'intermediaire d'un mec qui a tout pouvoir sur les mises en production : le "devops"

C'est aussi le gars qui bouscule les habitudes de "pépère l'admin Robert" en venant lui fourguer de nouveaux outils avec des agents qui doivent avoir des droits speciaux sur certains environnement , voir carrement de revoir les procédures ..

j'invente rien par exemple
un des concepts comme jenkins ( et ses 1400 plugins ) permettent de faire tout et n'importe quoi , mais quand l'admin Jenkins n'est pas là ...tous le monde est dans la mouise

Ça c'est quand t'es noyé quelque part entre l'étape 0 et l'étape 1 de l'évolution DevOps.

Donc oui forcément.

alors je ne dis pas qu'il n' y a pas des progrès fulgurant dans le domaine de l'automatisation des tests , etc. , l'arrivée de docker partout qui bouscule encore les façons de faire

En fait ça me fait penser que pour un poste DevOps regarder les compétences attendues et un vrai indicateur de niveau d'avancée de la culture dans l'entreprise. Si on te demande seulement Jenkins, attention danger. Si on te demande Jenkins + Docker + Kubernetes + Ansible / Puppet / ... ça peut être très sympa.

Mais c'est aussi à ce stade qu'il faut un niveau de compétence très élevé.

mais le combo "click click suivant suivant terminé allez zou je pars en we " ....hum. pas vraiment.

Perso je l'ai connu et sans containérisation. T'avais des jobs jenkins dans lesquels tu sélectionnais les tags à build puis à déployer dans un environnement que tu sélectionnais aussi. Et tout était automatique.

Clairement ça fait gagner un temps monstre.

[fiftytwo]

edit = desole jai supprime le contenu par accident

[Marco46]

ca cest windows ca ! la belle epoque , cela me manque ! mais devops ce nest pas cela du tout , je suis tout a fait daccord

Ya une incompréhension fondamentale, pour lui le DevOps c'est celui qui gère les livrables et les environnements. Il l'a interprété comme étant celui qui fait cliclic zou c'est déployé.

Sauf que non. Le DevOps c'est lui qui développe l'automatisation et qui mets à disposition des équipes les outils permettent de faire clic clic zou la version 1.2.3 est déployée en recette-28. Et ça peut tout à fait être un chef de projet qui effectue le déploiement.

[Engiwip]

Ya une incompréhension fondamentale, pour lui le DevOps c'est celui qui gère les livrables et les environnements. Il l'a interprété comme étant celui qui fait cliclic zou c'est déployé.

Sauf que non. Le DevOps c'est lui qui développe l'automatisation et qui mets à disposition des équipes les outils permettent de faire clic clic zou la version 1.2.3 est déployée en recette-28. Et ça peut tout à fait être un chef de projet qui effectue le déploiement.

hum non , c'est gentil de penser à ma place mais juste non.

je suis fondamentalement d'accord avec vos explications et que la culture d'entreprise autour du partage de la connaissance , de l'ouverture d' esprit et de la stack technique est primordiale pour l'integration d'une equipe devops.

j'avertis juste que le devops en pratique et selon les organisations n'est pas forcément le bonbon rose que tu décris.

et qu'une des plus grande qualité du devops ce n'est ni de savoir faire du dev , ni de l'admin mais bien d'accepter les consensus !

[fiftytwo]

j'avertis juste que le devops en pratique et selon les organisations n'est pas forcément le bonbon rose que tu décris.

Donc , on est donc daccord que cela depends de la boite

une des plus grande qualité du devops ..... accepter les consensus !

que veux tu dire par consensus ??

Si par consensus tu entends accepter la daube que la boite fait en pensant faire du devops , alors ce type de ''consensus'' est universel et n'as rien a voir avec devops

[Marco46]

hum non , c'est gentil de penser à ma place mais juste non.

Désolé, je pensais que c'était ce que tu pensais

j'avertis juste que le devops en pratique et selon les organisations n'est pas forcément le bonbon rose que tu décris.

L'avancement de la culture DevOps est variable certes, mais le rôle du poste DevOps est bien cela : Automatiser le processus qui va du merge du commit du développeur dans la branche de collaboration cible vers l'environnement cible (build + config + déploiement).

et qu'une des plus grande qualité du devops ce n'est ni de savoir faire du dev , ni de l'admin mais bien d'accepter les consensus !

Pareil que fiftytwo, je rajouterais cependant que l'avancement de la culture DevOps dans une organisation n'est ni un compromis ni consensus ni une négociation, c'est un état de fait.

Quand on prend des DevOps, j'entends par là quand on ouvre des postes de DevOps dans une organisation, c'est bien pour faire avancer cette organisation dans cette culture. Et ça suppose de vaincre la résistance au changement. Il y a plusieurs manières de faire, certains préfèrent constituer des noyaux de personnes avec cette culture, d'autres avec des instructions "top to bottom", dans tous les cas c'est comme pour la transformation agile, il faut l'appui de la hiérarchie, ça veut dire qu'à un moment il faut fesser les récalcitrants.

[Engiwip]

quand je parle de concensus je pense à l'evolution des mentalités et des process , c'est ce qu'il y a de plus dur à "bouger"

si la hierarchie et les décisionnaires n'appuient pas un mouvement de changement , le mouvement devops au sein d'une boite est mort dans l'oeuf et çà devient souvent une querelle entre service pour une lutte d interet politique ou inter service dans le choix de la stack technique.


et meme si il y a une reelle demande dans ce domaine il y a toujours un existant à automatiser , donc casser forcément ce qui a été fait.
car c'est le but de l'amelioration continue !

en ce sens savoir menager les susceptibilités entre services , jongler avec les process et souvent en ajoutant en plus des equip dev et ops : l'equipe QA pour le recettage et l'equipe sécurité ( dev-sec-ops) la promesse de l'automatisation "full devops" devient chimère.


d'ailleurs quand tu cites un peu plus haut sur un des mes commentaire que çà peut etre un probleme "d'architecte" ce n'est pas tres culture "devops" de rejeter la faute sur l'autre .
là encore il faudra opérer en douceur ou traduire les propos du "referent " technique pour essayer de passer une idee , une stratégie d'infra qui nous semble bonne pour l'organisation souhaitée..

[fiftytwo]

d'ailleurs quand tu cites un peu plus haut sur un des mes commentaire que çà peut etre un probleme "d'architecte" ce n'est pas tres culture "devops" de rejeter la faute sur l'autre .

et surtout rien n'est vraiment standardisé et les premieres étapes c'est de rajouter de la dette technique au milieu de la chaine par l'intermediaire d'un mec qui a tout pouvoir sur les mises en production : le "devops"

Jai deux questions a ce sujet

1. qui dirige la standardisation , fais en sorte de dessiner les grandes lignes de l'architecture de l'entreprise (si celle ci est dune taille assez consequente) ??
2. qui autorise le mec au milieu de rajouter de la dette technique a l'existant ??

Si cest la faute du management qui debarque et impose son idee de faire du devops parce que ca sonne cool et que cest a la mode , daccord je veux bien retirer mes propos

Sinon je maintiens ma declaration

[Engiwip]

Jai deux questions a ce sujet

1. qui dirige la standardisation , fais en sorte de dessiner les grandes lignes de l'architecture de l'entreprise (si celle ci est dune taille assez consequente) ??
2. qui autorise le mec au milieu de rajouter de la dette technique a l'existant ??

Si cest la faute du management qui debarque et impose son idee de faire du devops parce que ca sonne cool et que cest a la mode , daccord je veux bien retirer mes propos

Sinon je maintiens ma declaration

je comprends tes interrogations mais je pense selon moi qu' elles sont plus pernicieuses que pertinentes... en fait ce sont des questions pièges qui ne rendent service à personne au final .

car si on est dans la recherche d'un coupable quand çà ne fonctionne pas le devops est tout désigné ! c'est pour cela qu'il a tout interet à embarquer tous le monde bien avant dans le meme bateau ( voir dans sa galère pour certain )

et il y a un paquet de monde à rassurer :

- le management pour rassurer que les buzzwords qu'ils ont bullshité en reunion peuvent prendre une allure concrete , puis bon c'est eux qui filent la prime de noel.
- l' architecte ou référent pour le rassurer sur ses orientations techniques ( relatif a ses competences et à son melon hein , on n'a pas tous des Richard stallman dans les bureaux )
- les admins parce que la stabilité est leur credo
- les dev parce qu'ils sont convaincus que sans eux la terre s'ecroule.
- les Qa parce que selon eux ce sont les seuls à comprendre les clients
- la sécurité parce que grace à eux on a evité "le fameux audit qui ferait couler la boite ."


bref le devops est là au milieu, à essayer d'automatiser des chaines entre services et si le bateau prend l'eau , peu importe l'avarie ll y a de grandes chances pour qu'il boive au minimum une bonne tasse.

donc au dela de la stack technique voulue par l'architecte , des competences de chacun, une bonne dose d'empathie et un soupçon de consensus permet d'eviter pas mal de pb. humains et donc techniques.

[Invité]

Tu as oublié le dba qui va éviter que la mise à jour des données prennent seulement 3 minutes au lieu de 3 heures à cause d'un curseur maladroit