3 réflexions sur « 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 😉

   Répondre

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

   Répondre

3. Je viens de recevoir ce lien:
   http://newrelic.com/devops-101
   Que vaut le livre blanc en terme de documentation?

   Sinon je recommande le livre/site d’octo sur les géants du web:
   http://www.geantsduweb.com/
   Ca ne parle pas que de devops, mais une partie des sujets évoqués dans le podcast sont aussi mentionnés.

   Très bon podcast, merci pour cette interview.

   Répondre