Bah alors ?

[Claude Falguiere]

Bonjour à tous (et à toutes des fois que ...)

Je reviens de ma grippe-pneumonie du début d'année et du long tunnel dû à Devoxx France et je me dis j'ai dû louper plein de trucs !

Et là je vois que le dernier meetup sur le site date du mois de décembre ???

C'est gentil de m'avoir attendue, 

ou bien vous avez eu une grosse flemme, ou la grippe ?

ou vous avez décidé de faire des réunions secrètes au fond d'une cave mal indiquée pour partager vos secrets entre vous seulement ? 

Bref, il faudrait peut être qu'on fasse quelque chose avant l'été, le soleil, la mer, les vacances, et la fin des bonnes résolutions, ne serait ce qu'un pot. 

Si vous voulez faire un meetup, je peux fournir la salle chez Valtech et éventuellement le sujet (au choix "Analyser des données avec Incanter et Clojure" ou "Faire du diagnostic de performance JEE avec ses Ops et pas contre", bon c'est ce que j'ai sous la main et pas trop le temps de faire du neuf, et comme l'a si bien dit Seb Douche je radote ;-P)

A bientôt

--
Claude Falguière - @cfalguiere

[Chetan Goswami]

Bonjour Claude,

Je suis intéressé, pour un meetup (ca sera mon premier depuis que j'ai rejoint la groupe)

A bientôt

Chetan Goswami

[Bruno Bonfils]

2012/5/1 Claude Falguiere <cfalg...@gmail.com>:

> Si vous voulez faire un meetup, je peux fournir la salle chez Valtech et
> éventuellement le sujet (au choix "Analyser des données avec Incanter et
> Clojure" ou "Faire du diagnostic de performance JEE avec ses Ops et pas
> contre", bon c'est ce que j'ai sous la main et pas trop le temps de faire du
> neuf, et comme l'a si bien dit Seb Douche je radote ;-P)

Encore quelque chose orienté Java :/ (cependant je n'ai pas dis que
c'était inintéressant, bien au contraire).

Je suis en train de faire un peu de PaaS pour Drupal, et pour le coup,
c'est intéressant de voir tout ce qu'il pour simplifier/automatiser
toute la partie dev et ops.

D'une manière peut être plus générale, ne manquerait il pas de roadmap
/ guidelines pour ce groupe ? cela aiderait peut être à ce que chacun
participe


dans tous les cas, rdv au prochain meetup !

--
http://asyd.net/home/

[Simon-Pierre NOLIN]

Comme pour Chetan, ce sera mon premier meetup donc partant!

Au niveau des sujets, étant plus orienté "processus et méthode de travail" que "outils" le second sujet sur le diagnostique de performance m'interesse plus. Sinon je proposerai bien un brainstorm (sous la forme d'un innovation game ?) autour des rituels et façon de faire DevOps. 

Bien cordialement

Simon Pierre

[Bruno Bonfils]

2012/5/2 Simon-Pierre NOLIN <simon-pie...@alcyonix.com>:

> Au niveau des sujets, étant plus orienté "processus et méthode de travail"
> que "outils" le second sujet sur le diagnostique de performance m'interesse
> plus.

Personnellement, je ne vois pas en quoi ce sujet est moins "outils"
que le premier, c'est juste une question de formulation :)

De plus j'ai quelques difficultés à voir comment peut on parler de
devops avec juste "processus et de méthode de travail", c'est peut
être mon coté antibullshit (désolé du mot, je ne trouve pas mieux),
mais comment dire "devops faut faire ci, ça" sans parler (mais pas
focaliser) de technos / d'outils. Personnellement j'aurais un peu de
mal, mais je ne demande qu'a être converti

> Sinon je proposerai bien un brainstorm (sous la forme d'un innovation
> game ?) autour des rituels et façon de faire DevOps.

cela ne consiste pas qu'a à boire des bières entre dev et ops en étant
pragmatique ? :)

--
http://asyd.net/home/

[HBM]

Ben moi je préfère de loin une présentation sur les performances Java EE qui touche des centaines de milliers de projets. Je pense qu'on pourra s'arrêter longuement sur la partie de ping-pong habituelle entre Ops/Devs/ et Experts :

Incident 1 au jour J :
Ops : Un incident de prod est survenu hier et nous avons redémarré les serveurs.
Experts : Avez-vous pensé à faire un thread dump avant de redémarrer.
Ops : Non, l'exploitant n'y a pas pensé
Experts: Pensez à le faire la prochaine fois car il n'y a rien de significatif dans les logs.

Incident 2 au jour J+x :
Ops : Le problème s'est reproduit hier
Experts : Le thread dump ?
Ops : En PJ
Experts : hmmm... Nous avons quelques pistes, il nous faut un interlocuteur de l'équipe de Dev pour plus de précisions.
Ops : Etes-vous disponibles pour une réunion.
Expert : Oui pour la semaine prochaine

jour J+x+y :
Plusieurs réunions et échanges : Le cp qui défend son équipe, l'architecte qui défend ses choix, l'expert qui joue le détective, le Dev 'intimidé' qui promet de corriger, la MOA qui cherche le coupable et l'ops qui signale que l'incident se reproduit encore et encore.

jour J+x+y+z : MEP de la nouvelle version.

Entre le premier incident et la correction il s'est passé plus d'un mois... :)
Bon techniquement ça se termine là, mais une guerre purement politique et budgétaire commence juste après entre chefs...

Pour toutes ces raisons : +1 pour la prez sur les perf Java EE

A+

Le 2 mai 2012 15:13, Bruno Bonfils <bbon...@gmail.com> a écrit :

--
Hassan
Software Architect

[Richard Coffre]

Très intéressant échange.

Je suis preneur de ce meetup.

Richard

https://twitter.com/#!/RichardCoffre 

2012/5/2 HBM <hassa...@gmail.com>

[Thomas Clavier]

On 02/05/2012 16:22, Bruno Bonfils wrote:
> De plus j'ai quelques difficultés à voir comment peut on parler de
> devops avec juste "processus et de méthode de travail", c'est peut
> être mon coté antibullshit (désolé du mot, je ne trouve pas mieux),
> mais comment dire "devops faut faire ci, ça"

"devops faut faire si ou ça" ... c'est juste pour provoquer ?

Favoriser la bonne collaboration entre équipes ne passe pas forcément
par les même outils, par les même méthodes et ou processus. Illustrer
ses exemples avec des outils c'est une chose, en faire des obligations
j'ai beaucoup plus de mal. S'il y avait une solution pour s'organiser et
travailler ensemble efficacement, tout le monde l'utiliserait. C'est
bien parce-que les équipes sont composé d'humain qu'il n'y a pas de
solution magique. Imaginons que le prochain sujet soit "Échange de code
entre équipes" : échange du code qui décrit l'infrastructure et sa
configuration ou le code source des application, c'est largement
faisable sans parler de git :-) Une des questions qui pourrait se poser
c'est : quel est le code que je peux partager ? en fonction de mon
entreprise celà peut-il jouer sur la sécurité ? comment le faire pour
passer la prochaine audit PCI ? et tout ça sans parler d'outils :-)
Évidemment il serait aussi possible de parler de l'usage de git sur les
postes windows du marketing :-)

--
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk : t...@jabber.tcweb.org
+33 (0)6 20 81 81 30 +33 (0)950 783 783

[Bruno Bonfils]

Envoyé de mon téléphone

Le 2 mai 2012 à 18:18, Thomas Clavier <t...@tcweb.org> a écrit :

> On 02/05/2012 16:22, Bruno Bonfils wrote:
>> De plus j'ai quelques difficultés à voir comment peut on parler de
>> devops avec juste "processus et de méthode de travail", c'est peut
>> être mon coté antibullshit (désolé du mot, je ne trouve pas mieux),
>> mais comment dire "devops faut faire ci, ça"
>
> "devops faut faire si ou ça" ... c'est juste pour provoquer ?
>

Oui, et cela semble porter ses fruits.

> Favoriser la bonne collaboration entre équipes ne passe pas forcément
> par les même outils, par les même méthodes et ou processus. Illustrer
> ses exemples avec des outils c'est une chose, en faire des obligations
> j'ai beaucoup plus de mal. S'il y avait une solution pour s'organiser et
> travailler ensemble efficacement, tout le monde l'utiliserait.

Nous sommes entièrement d'accord et c'est bien cela en quoi j'ai du mal avec les présentations purement non techniques. De part mon expérience, je n'ai vue aucune société fonctionné pareil, alors comment peut t'on présenter une "méthode" devops ?

Comme tu le souligne plus bas, des contraintes fortes imposées par - par exemple - PCI DSS vont avoir un grand impact sur le mode de fonctionnement par rapport à un éditeur d'appli web "simple" etc.

Ce que je voulais dire avec mon tact légendaire c'est oui à des retours d'expérience concret en entreprise "méthodes et processus chez moi, retour d'exp" et pas juste "méthode et processus devops". Pour ma part j'ai malheureusement plus de sujets "pourquoi devops n'est possible chez XX" mais c'est encore un autre débat.

[Thomas Clavier]

On 02/05/2012 18:45, Bruno Bonfils wrote:
> Pour ma part j'ai malheureusement plus de sujets "pourquoi devops
> n'est possible chez XX" mais c'est encore un autre débat.

Ha ça j'ai pas ... enfin pas sous cette forme. J'ai : pourquoi nous
avons commencé par ça :-)

[Gildas]

Le 2 mai 2012 18:46, "Bruno Bonfils" <bbon...@gmail.com> a écrit :
> Ce que je voulais dire avec mon tact légendaire c'est oui à des retours d'expérience concret en entreprise "méthodes et processus chez moi, retour d'exp" et pas juste "méthode et processus devops".  Pour ma part j'ai malheureusement plus de sujets "pourquoi devops n'est possible chez XX" mais c'est encore un autre débat.

Je pense au contraire que c'est bien dans le debat! Parler de ce qui d'après toi bloque ou empeche la mise en place d'une demarche devops chez XX peut faire l'objet d'une presentation puis d'un echange.

Tout n'est pas forcement rose en entreprise soit, mais il y a svt plein de facons d'aborder les choses et des axes d'amelioration que l'on neglige ou que l'on ne voit pas, pour tout un tas de raisons.

Creer un cercle vertueux n'est certes pas facile, mais cela est neanmoins svt plus realiste que d'attendre une hypothetique embauche par une societe idylique qui ferait deja "tout bien" (Au passage je conseille la lecture du livre "Lichpin" de Godin).

Il y a tjrs des "low hanging fruit" a cueillir mais des fois a les avoir sous le nez on ne les voit pas.

Gildas (depuis un tel egalement)

[Claude Falguiere]

Bonjour,

Wouah ... et bien vous êtes toujours là en fait. 

1) 

J'ai proposé un sujet pour ne pas laisser à d'autres la charge de faire le boulot. 

Juste pour éclaircir le thème de ma présentation elle est plus problématiques et outils que processus dans le sens où je donne des pistes pas une méthode (j'ai dû écrire une méthode de test de performance pour un client et c'est un cauchemar surtout quand on sait fort bien que le problème réel est la personne en charge de l'activité qui ne fait pas son travail). 

J'ai d'abord voulu faire une présentation technique sur les perf, mais le champ est large et il y a des tas de gens qui ont beaucoup plus d'autorité que moi dans ce domaine. En recentrant de plus en plus le sujet pour le faire tenir en 1h, je me suis rendue compte que j'avais 2 idées principales 

- ce que je constatais sur le terrain était une difficulté de travail en common due à un gap technique sur les technos Web et Java et à une culture différente. Faute d'une base commune de résolution du problème, les Ops ont souvent l'impression que les Devs vont à la pêche. Donc j'ai essayé de combler le gap, un peu comme l'a fait cyrille en présentant JMX, mais de manière un peu plus large en présentant des concepts sur la limite dev/prod et divers outils que je trouve utile 

- un problème de stratégie qui fait que les gens (en particulier les développeurs) attaquent le problème par un peu n'importe où (et en général leur code dans Eclipse) ce qui n'est pas toujours le bon endroit si c'est un problème de capacité. Du coup, il devient aussi assez difficile de travailler en commun sans plan de travail commun. J'ai essayé de ranger les symptômes en plusieurs catégories que vont entraîner des démarches différentes 

La pres a été faite pour des JUGs, donc c'est du JEE, mais ça n'est pas non plus un cours Java.

Je serais assez preneuse d'un débat sur le diagnostic de problèmes en production, ce qui est en fait le sujet central de ma présentation, et c'est une question qui amène loin (comment faire une application administrable, les informations à monitorer, comment faire des logs ...). L'inconvénient est que les Ops auront probablement l'impression de radoter ("mais enfin c'est évident !" ;-) ) et les Devs qu'on ne leur donne pas le temps de mettre en place ces choses sur leur projet. Mais je pense lister formellement ces choses fait partie des actions utiles pour un groupe devops.

2)

J'ai l'impression qu'il a beaucoup de nouveaux, donc il faudrait peut être faire une session assez générale sur les objectifs de Devops.

En particulier beaucoup de gens de la communauté Agile sont en train de reprendre le sujet. C'est bien d'une certaine manière parce que ça apporte le tiers manquant dans DevOps qui est le product owner, mais c'est aussi une vision plus théorique des choses (voir point 3)

On a déjà discuté du fait que DevOps était beaucoup orienté outils de gestion d'infra et pas trop gestion des problèmes communs ou Ops et aux Devs. Là je pense que le problème va se compliquer encore avec des attentes de nature différentes.

3) 

Je suis d'accord avec Bruno sur la notion de processus mais si je ne suis pas aussi radicale. 

Je déteste ce qu'est devenu Agile (en particulier SCRUM). J'ai des discussion à mourir de rire (ou de désespoir je sais pas trop) dans les after de user groups de devs où ils m'expliquent qu'ils appliquent (tous les trucs de) SCRUM et que leur projet ne va pas mieux et qu'ils ne peuvent pas en discuter au boulot parce que le chef de projet (enfin ça doit être le SCRUM master) n'est jamais là. 

Je pense qu'il y a des choses utiles à faire dans DevOps pour identifier des points qui font mal et fournir des réponses (outillées ou pas) à certaines questions que l'on à traiter (ce qu'à fait XP en son temps). ça peut être des guidelines assez génériques référençables dans les documentation d'architecture (oui je sais personne ne les lit mais aussi parce que souvent ils ne contiennent rien d'utile). 

Et ça ne passe pas forcément par la définition d'un processus ou d'une méthodologie DevOps, mais bon ça arrivera (voir point 2, et oui je sais ça s'appelle une boucle infinie et c'est pas bien, mais c'est juste pour embêter les Ops)

4) 

innovation game 

je ne sais pas bien à quoi pense Simon-Pierre. Personnellement je ne vois pas bien quel rituel DevOps on pourrait jouer, mais bon je veux bien d'une formation sur les bières ;-)

Si l'idée est de rejouer un des jeux Agile qui apprennent aux gens que c'est difficile de travailler ensemble sur un projet, c'est cool, mais ça ne servira à rien. Les équipes de dev sont relativement homogènes et le client et le projet sont tous les deux impliqués dans la réussite de ce projet précis. 

Le problème pour le moment est que les Devs et les Ops ne reçoivent pas les mêmes objectifs généraux (gestion transverse / gestion d'un projet) et doivent arriver à quelques chose de commun sur quelques unes de leurs activés. On est dans une coopération de jeu de rôle, chacun est complémentaire, mais avec ses objectifs propres et coopère pour une durée limitée dans le temps pour le profit de chacun. On peut jouer à WoW ou SWTOR, c'est une bonne école, mais je ne suis pas sûre qu'on a besoin de se réunir pour ça.

Pour revenir à quelque chose de plus sérieux, on pourrait monter des ateliers 1Dev-1Ops pour faire une mini appli en pair-programming et la déployer sur un Cloud. Chacun pourrait expliquer les problèmes que telle ou telle action ou demande de l'autre lui pose. On peut la monter en coopération avec Duchess France, on a l'habitude de monter ce type d'ateliers pour faire du code et on a des Dev sous la main (pas sure qu'il y en a beaucoup ici). Pour moi ce serait plutôt un coding-dojo en parallèle des sessions du groupe.

5) 

action

il me semble que le "rituel" était un mercredi et plutôt en début de mois. Je vois les réservations pour la grande salle pour début juin. 

d'ici là on fixe le sujet

- DevOps vers l'infini et au-delà

- PaaS Drupal 

- diagnostic de perf

- innovation game 

A bientôt

Claude

[Gilles Di Guglielmo]

Hello,

Dimitri et moi pouvons refaire un bis de notre prez Devoxx si ca int�resse.

http://devoxx.fr/pages/viewpage.action?pageId=6128509

G.

PS: on aimerais 30 min pour prolonger un peu la d�mo

On 5/3/2012 2:55 PM, Claude Falguiere wrote:
>
> d'ici l� on fixe le sujet
> - DevOps vers l'infini et au-del�

> - PaaS Drupal
> - diagnostic de perf
> - innovation game
>

> A bient�t
> Claude
>
>

[Stephane RIOS]

Idem, Bertrand et moi m�me pouvons refaire la prez' qu'il avait faite a
Devoxx sur ce qu'on a fait chez Fasterize au niveau d�ploiement infra &
appli

http://devoxx.fr/display/FR12/Continuous+deployement+++Rackspace%2C+Chef+et+capistrano+en+action

Le 03/05/12 15:10, Gilles Di Guglielmo a �crit :

--
St�phane RIOS - fasterize.com - 06 30 26 44 80

[Claude Falguiere]

c'est un quickie (allongé à 30mn si je comprend bien) et un tools in actions (donc 30mn si vous gardez le format)  c'est bien ça ?

Claude

Le 3 mai 2012 15:41, Stephane RIOS <s...@fasterize.com> a écrit :

Idem, Bertrand et moi même pouvons refaire la prez' qu'il avait faite a Devoxx sur ce qu'on a fait chez Fasterize au niveau déploiement infra & appli

http://devoxx.fr/display/FR12/Continuous+deployement+++Rackspace%2C+Chef+et+capistrano+en+action

Le 03/05/12 15:10, Gilles Di Guglielmo a écrit :

Hello,

Dimitri et moi pouvons refaire un bis de notre prez Devoxx si ca intéresse.

http://devoxx.fr/pages/viewpage.action?pageId=6128509

G.

PS: on aimerais 30 min pour prolonger un peu la démo

On 5/3/2012 2:55 PM, Claude Falguiere wrote:

d'ici là on fixe le sujet
- DevOps vers l'infini et au-delà

- PaaS Drupal
- diagnostic de perf
- innovation game

A bientôt
Claude

--
Stéphane RIOS - fasterize.com - 06 30 26 44 80

--
Claude Falguière 

@cfalguiere / +Claude Falguiere

blog : http://cfalguiere.wordpress.com/ 

[HBM]

Mon point de vue :
DevOps ne signifie pas forcément "outils de cloud".
Un meetup ne signifie pas forcément "vendre l’utilité de son outil préféré auprès d'un public".
Pour motiver les gens à se déplacer le soir après une longue journée de travail, il faut plus qu'une démo ou un tutoriel d'un outil, il faut 'du lourd', sinon les gens ne reviennent jamais.
Un meetup est intéressant quand on parle de rex et de chiffres issues de vraies expérimentations d'outils, de process et de solutions chez des clients.

[Alexandre F]

De mon cote, ca sera aussi le premier meetup, et tres interresse par
les 2 bis de devoxx

- l'amélioration de la gestion des paramètres de configuration d'une
application
- Continuous deployment chez Fasterize (etant donne que je fais a peu
pres la meme chose avec les technos concurrentes Puppet, EC2, Puppi et
mcollective/capistrano)

On May 3, 5:04 pm, Claude Falguiere <cfalgui...@gmail.com> wrote:
> c'est un quickie (allongé à 30mn si je comprend bien) et un tools in
> actions (donc 30mn si vous gardez le format)  c'est bien ça ?
>
> Claude
>
> Le 3 mai 2012 15:41, Stephane RIOS <s...@fasterize.com> a écrit :
>
>
>
> > Idem, Bertrand et moi même pouvons refaire la prez' qu'il avait faite a
> > Devoxx sur ce qu'on a fait chez Fasterize au niveau déploiement infra &
> > appli
>

> >http://devoxx.fr/display/FR12/**Continuous+deployement+++**
> > Rackspace%2C+Chef+et+**capistrano+en+action<http://devoxx.fr/display/FR12/Continuous+deployement+++Rackspace%2C+C...>

>
> > Le 03/05/12 15:10, Gilles Di Guglielmo a écrit :
>
> >  Hello,
>
> >> Dimitri et moi pouvons refaire un bis de notre prez Devoxx si ca
> >> intéresse.
>

> >>http://devoxx.fr/pages/**viewpage.action?pageId=6128509<http://devoxx.fr/pages/viewpage.action?pageId=6128509>

[Henri Gomez]

> Mon point de vue :
> DevOps ne signifie pas forcément "outils de cloud".

Absolument, il y a parfois confusion dans l'esprit des gens.
Il n'y a aucune obligation d'être sur du Cloud pour faire du DevOps,
ça marche aussi en mode 'on-premise'

En plus c'est aussi une approche culturelle différente, notamment en
sortant des relations inter-silos comme c'est trop souvent le cas.

[Claude Falguiere]

Bonjour,

Tout le monde veut faire son event avant l'été donc c'est un peu chaud pour les salles

J'ai deux slots à confirmer rapidement :

- le jeudi 7 juin (pas mercredi mais première dispo)

- ou le mercredi 13 juin 

La seule salle disponible est la salle du conseil qui a 36 places assises.

Le doodle pour choisir, je clos lundi

http://www.doodle.com/kb5p77rtyypsuaez

Pour les sujets, je propose 

- un retour Devoxx "à chaud" avec les 2 pres de 30 mn

- une discussion d'une heure environ sur les thèmes qu'on veut aborder et ce qu'on veut faire dans les sessions suivantes (j'amène les post-its :o) )

J'ai noté les autres sujets, on les planifiera en juillet s'il y a des courageux ou pour la rentrée

 

Est ce que ça vous convient ? 

A bientôt
Claude

[HBM]

Donc en gros c'est celui qui propose les locaux qui a le droit de choisir les sujets ? C'est bien ça ou j'ai mal compris ?

[Claude Falguiere]

Bonjour,

@Hassam

J'ai décidé de ne pas me mettre sur le dos l'organisation de la session et une pres. Et oui j'ai fait un choix de proposer le sujet, sur la base des réponses, et puis regrouper les 2 sujets courts ça permet de garder les sujets plus longs pour une session complète. 

Il est urgent de fixer la date pour que je puisse réserver la salle. Pour le sujet, la discussion reste ouverte, le sujet alternatif est la présentation de Bruno sur Cloud et Drupal, et si j'ai raté quelqu'un et bien désolée

@Gilles et @Dimitri 

le 13 ne m'arrange pas trop non plus, le pars à Lannion jeudi matin et je suis au Breizhcamp vendredi

A+
Claude

[Bruno Bonfils]

>
> Il est urgent de fixer la date pour que je puisse réserver la salle. Pour le
> sujet, la discussion reste ouverte, le sujet alternatif est la présentation
> de Bruno sur Cloud et Drupal, et si j'ai raté quelqu'un et bien désolée

Je pense qu'un début "devops est-il applicable dans toutes les
entreprises" intéressaient sans doute plus de monde que mon histoire
de drupal :)

[Claude Falguiere]

On en rediscute après les pres. 

J'ai réservé la salle pour le 7 juin. 

Je dois avoir les droits sur le github pour mettre à jour la page. Par contre je ne sais pas trop qui a crée le compte Eventbrite. Est ce qu'il est possible d'ajouter mon compte Eventbrite (cfalg...@gmail.com) dans le multiuser access ? Sinon quelqu'un qui a les droits le crée.

A+
Claude