Nipdev 19 – Les pratiques Devops avec @zepag

Podcast: Téléchargement
174188Pierre-Antoine Grégoire alias @zepag membre des “Mercenaires Devops” nous parle des pratiques Devops et de leur mise en oeuvre dans la vraie vie.

Quelques sites

 Quelques outils

 Des vidéos

 Des conférences

 

3 réflexions au sujet de « Nipdev 19 – Les pratiques Devops avec @zepag »

  1. J’ai un peu de mal à bien comprendre : personnellement, je suis habitué aux postes suivants:
    – reseau
    – systèmes
    – dev
    – moa(spec/test)
    – opérationnel/utilisateurs (client externe ou non)
    Pour faire un poste à cheval, en « pont » entre ces postes c’est difficile à justifier.
    Par-contre, je connais puppet, un outil très puissant utilisé par nos admin systèmes 😉
    Autre chose, en entendant à la fin « devops c’est penser à l’après, aux personnes qui vont deployer… » mais on communique un minimum entre les équipes, sinon on arriverai jamais à mettre en production 🙂

    Pour l’histoire de la « rigidité » de SOAP qui oblige a revalider le schéma à l’ajout de fonctionnalités…
    Pas compris: je ne sais pas si ça vient de la technologie que vous utilisez, mais en php par exemple, je créé un webservice « calculette » avec une méthode somme(), si demain je rajoute une methode soustraction(), je l’ajoute au serveur et ça n’impacte pas mon client qui n’utilise que somme() 😉 (pas besoin de revalider le WSDL ou autre)
    Pouvez-vous développer le problème rencontré et cette histoire de validation de schéma ?

    note: si je puis me permettre, je trouve juste dommage de ne pas vous avoir entendu rire aux blagues de zePag que j’ai trouvé sympa 😉

  2. Salut Mikado,

    Et désolé pour la réponse très tardive, j’avais zappé ton commentaire :p
    Pour ce qui est du premier point, je crois que nous avons bien insisté sur le fait que Devops n’est PAS un poste ou un profil de personne à cheval entre des postes. En revanche, la vision découpée en silos que tu présentes a je pense du plomb dans l’aile. Chaque « profil » existant a je pense vocation à s’hybrider un peu plus.

    Pour ce qui est de la communication avec la production… mouais. Le fait que l’on arrive à destination ne signifie pas que le trajet s’est passé sans encombres, et ne peut pas être (parfois drastiquement) amélioré.

    Quand à SOAP, en effet, on peut le consommer côté client sans valider le schéma, et l’intérêt par rapport à un XML RPC est alors relativement léger. La plupart des librairies et du tooling d’entreprise (la cible de SOAP) utilise la validation. Il en va de même pour les namespaces.
    Vu la manière dont tu consommes SOAP en PHP (que je trouve bonne au demeurant, le client ne devrait valider que ce dont il a besoin), tu gagneras sans doute à utiliser des services REST. Après ce que j’en dis… 😉

    Merci d’avoir écouté le podcast!

    (ze) PAG

Laisser un commentaire