Un petit retour d'expérience

47 views
Skip to first unread message

Sebastien Douche

unread,
Dec 3, 2010, 1:01:32 PM12/3/10
to paris-...@googlegroups.com
Hello,
je viens de prendre connaissance par le blog de Laurent de votre
réunion. Je ne sais pas quels sujets vous souhaitez aborder en
particulier sur cette ml mais voici un retour d'expérience. J'espère
être dans le ton.

J'ai la chance de posséder les 2 cultures : je fais du dev depuis
longtemps et de l'admin depuis 10 ans maintenant. Et je dois dire que
cela m'aide *beaucoup* dans mon travail : cela me permet d'intervenir
sur l'ensemble de la chaine de valeur et d'essayer de l'optimiser à
tous les niveaux.

J'ai pu au travers de mon expérience, constaté les dégats occasionnés
par ce découplage strict dev / admin. Ayant travaillé dans le secteur
public (comme EDF ou des ministères) ou de grosses sociétés privés
(comme des banques) en tant qu'admin, dev ou responsable projet, cette
barrière est pour moi, du même acabit que MOE / MOA : destructeur de
valeur et augmentant les couts (temps, personne) de manière
incroyable. Nous retrouvons les mêmes problèmes : des histoires de
pouvoir, d'organisation hierachique, de process lourds et lents, de
non écoute mutuelle. En résumé : une organisation inefficace.

J'ai même rencontré ce problème dans ma boite actuelle, composée de...
30 personnes. Depuis, nous avons revu l'organigramme et cette barrière
a disparue puisque je suis en charge de l'ensemble de la chaine de
valeur 'produire' (du développement à la mise ne prod chez nos clients
donc, mais aussi support et logistique), l'autre chaine étant 'vendre'
(avant vente, vente, formation et support commercial). Voici quelques
exemples de ce que nous avons réussi à mettre en place :

* l'ensemble du labo R&D est virtualisé (KVM, OpenVZ puis LXC). Cela
permet de disposer de plusieurs sondes (nous vendons des appliances)
sur nos serveurs. Par ex: avoir 5 sondes de formation sur 1 machine
physique, disposer de plusieurs versions pour les commerciaux sur 1
machine.

* Plus intéressant encore, l'outil de déploiement continu (Buildbot)
permet de générer une sonde virtualisée (nue ou avec une version N-1
pour test d'upgrade) et deployer simplement une version en cours de
développement (chaque fix ou fonctionnalité est dans une branche Git).
D'ailleurs, tous les jours à midi, une instance Buildbot maitre (nous
en avons 7 pour différentes taches) génère automatiquement une sonde
pour chaque fix ou fonctionnalité.

* Chaque sonde virtualisée est connectée au réseau (nos sondes ont
pour objectifs d'analyser du traffic réseau), ce qui permet de
l'utiliser réellement et de faire des tests fonctionnels (de bout en
bout) avec. La sonde est utilisable pratiquement comme une sonde
réelle.

* La virtualisation permet aussi de créer trés facilement une sonde
pour les besoins des développeurs (moins de 1mn pour créer une sonde).

* Le deploiement (quelques que soit la version, stable comme dev) se
fait en créant un package binaire identique à celui déployé par un
client. Les tests internes reproduisent la chaine complète (production
interne et utilisation client). Nous avons aussi des sondes R&D chez
des clients sur leurs réseaux.

* Le système fait du partie de l'ensemble. Nous versionnons donc les
packages utilisés, la conf système, le noyau... Les upgrades prennent
en compte les changements systèmes.

* L'outil de déploiement en prod est un outil dev (Buildbout, une
sorte de Grail si je suis bien le monde Java) qui permet de développer
des extensions, nous en avons donc écrite plusieurs : test avec un
environnement SGBD maison, intégration de notre sniffer maison codé en
C,

* Le release management intégre code + système

* La R&D développe des scripts pour automatiser le travail de prod
ainsi que des outils système pour faciliter la vie des "admins
utilisateurs".

* Il n'y a pas de séparation dev / prod (tous à la R&D, dans la même piece)

* Je déplois le site web de la société avec Git

Ma vision du devop (erronée ?) est pour moi le prolongement de ce que
nous avons fait avec l'agilité (ex: avant intégration continue,
maintenant déploiement continue) : fusion du dev, du test et de la
prod. Mais malgré de belles avancées, on a encore pas mal de lacunes,
je suis d'ailleurs preneur d'avis et de retour d'expérience.

Laurent parle sur son blog de ne se focaliser sur les outils, mais
c'est bien sur les outils que le point de discordre est le plus patant
amha au niveau des "opérationnels". La ou un développeur à besoin
d'outil souple pour le développement, l'admin veut des outils en
rapport avec sa philosophie. Un exemple assez criant se trouve sur les
outils de gestion de composant. Un développeur travail avec Maven
(Java) ou Buildout (Python), la ou l'admin veut du RPM / DEB, qui
s'intégre dans son OS, ses outils classiques de gestion de parc, et
qu'il maitrise. Et apprendre à un admin les outils de dev, c'est le
faire rentrer dans le monde du dev, avec toute sa complexité : outil
de gestion de source (Hg / Git), outil de composant code (Buildout),
fonctionnement des paquets Python (Egg) sont par ex. le minimum vital
qui doit être maitrisé ici. Rien de bien méchant pour un dev, mais un
pas gigantesque pour un admin qui n'a jamais développé de sa vie (à
part modifier quelques scripts Shell ici ou la).

On peut voir cette dichotomie dans la refonte du projet Distutils2, de
mon ami Tarek : l'objectif est de revoir le packaging Python (trop
longtemps délaissé hélas). De longues discussions ont suivis sur les
besoins et exigeances de chacun, et on a pu voir discintement qu'un
admin (admin lambda, responsable de packages Debian...) avait une
vision bien différentes des développeurs.

Un autre aspect intéressant est le cloud : la plupart n'offre plus la
même liberté d'administration, et c'est bien l'aspect développement
qui est mis en avant. J'ai pu tester récemment Heroku, une plateforme
d'hébergement d'application Ruby : on gère ses instances avec un outil
CLI qu'on télécharge sur sa machine puis on met en prod... avec Git.
Le modèle Heroku semble prendre de l'ampleur (naissance de plusieurs
plateformes de ce type en cours). Le cloud change la donne il me
semble (autre ex: GAE).

Enfin, j'ai initié #gitfr (http://blog.gitfr.net, l'objectif est
surtout de faire des formations et des présentations) pour promouvoir
Git en tant qu'outil de gestion de code, car il permet de modéliser le
worflow organisationnel de son choix. Cela demande réflexion dans le
choix des workflows et rigueur dans le suivi mais les possibilités
sont trés intéressantes dans une optique devop (cf exemples ci
dessus).


Voili voilou, si des personnes expérimentées ont des critiques je suis
preneur :)

--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche (agile, lean, python, git, open source)

Philippe Muller

unread,
Dec 6, 2010, 5:03:32 AM12/6/10
to paris-...@googlegroups.com
Salut Sebastien!

Merci pour ton retour d'experience.

Je m'y reconnais un peu, dans la mesure où je suis un admin qui, au
fil des années, s'est mis au dev. Essentiellement pour automatiser son
boulot d'admin, mais en essayant d'apprendre quelque chose de nos amis
développeurs, et de leurs pratiques agiles.
Et si tu peux passer nous voir lors de la prochaine réunion,
j'aimerais m'entretenir avec toi sur la gestion des projets Python
(surtout l'integration continue, le packaging et le déploiement).

A bientot

Philippe Muller

2010/12/3 Sebastien Douche <sdo...@gmail.com>:

Gildas

unread,
Dec 6, 2010, 8:50:05 AM12/6/10
to paris-...@googlegroups.com
2010/12/3 Sebastien Douche <sdo...@gmail.com>:

>
> * Le système fait du partie de l'ensemble. Nous versionnons donc les
> packages utilisés, la conf système, le noyau... Les upgrades prennent
> en compte les changements systèmes.
>
> * L'outil de déploiement en prod est un outil dev (Buildbout, une
> sorte de Grail si je suis bien le monde Java) qui permet de développer
> des extensions, nous en avons donc écrite plusieurs : test avec un
> environnement SGBD maison, intégration de notre sniffer maison codé en
> C,
>
> * Le release management intégre code + système
>
> * La R&D développe des scripts pour automatiser le travail de prod
> ainsi que des outils système pour faciliter la vie des "admins
> utilisateurs".
>
> * Il n'y a pas de séparation dev / prod (tous à la R&D, dans la même piece)
>
> * Je déplois le site web de la société avec Git
>
>

Bonjour Sébastien,

Je dois dire que ne suis pas surpris de te retrouver ici :) Merci
pour ce retour d'expérience qui vient en complément de ton commentaire
sur le site d'Institut Agile.

Je trouve que ton exemple démontre bien les éléments à la base du
mouvement devops tels que décrits par Damon Edwards et John Willis [1]
: Culture, Automatisation, Mesure, Partage (CAMS en anglais).

Tu commences par dire :


> cela me permet d'intervenir sur l'ensemble de la chaine de valeur et d'essayer de l'optimiser à tous les niveaux.

et


> Nous retrouvons les mêmes problèmes : des histoires de
> pouvoir, d'organisation hierachique, de process lourds et lents, de
> non écoute mutuelle. En résumé : une organisation inefficace.

[snip]


> J'ai même rencontré ce problème dans ma boite actuelle, composée de...
> 30 personnes. Depuis, nous avons revu l'organigramme et cette barrière
> a disparue puisque je suis en charge de l'ensemble de la chaine de
> valeur 'produire' (du développement à la mise ne prod chez nos clients
> donc, mais aussi support et logistique), l'autre chaine étant 'vendre'

Cela me semble important de le dire et de le redire : devops est un
mouvement qui traite de l'informatique d'entreprise/professionnelle.
Il adresse une problématique "business" par le biais de plusieurs
angles (les fameux CAMS ci-dessus), et par ce fait apporte de la
valeur.

Il n'est pas purement technique mais aussi organisationnel et humain.

D'une certaine façon, ton exemple est un peu un "cas particulier",
d'une part parce que tu as la double compétence, d'autre part parce
que tu travailles dans une petite société avec un produit bien
identifié. Dans ces conditions, l'identification de ce qui apporte de
la valeur est plus facile. Du coup "casser les silos" et lutter contre
les optimums locaux à chaque équipe est plus facile.

Cela dit, nul besoin d'être à la fois d'avoir la "double compétence"
pour faire du devops, même si bien évidement cela facilite les choses
parce que connaître les deux environnements abaisse la barrière de la
communication : il est plus facile de communiquer avec quelqu'un qui
fait le même métier que soi.

De la même façon, même au sein de grands groupes il y a moyen de
mettre en place des équipes dédiées à un projet/service donné. Il y a
des exemples, non seulement pour sociétés dont les approches sont à
l'origine du mouvement devops (telles qu'Amazon que tu cites dans ton
commentaire sur touilleur-express [2]), mais aussi plus récemment chez
National Instruments [3].

> Laurent parle sur son blog de ne se focaliser sur les outils, mais
> c'est bien sur les outils que le point de discordre est le plus patant
> amha au niveau des "opérationnels"

Je ne peux pas parler pour Laurent, mais peut-être son point de vue
était il de dire que la culture doit passer avant la mise en place
d'outils? C'est un avis qui semble partagé un peu partout : avoir la
bonne culture est une étape fondamentale pour bénéficier des retombées
positives d'une approche devops. Sans cela, automatiser à outrance,
mesurer tout et n'importe quoi n'apportera pas forcément grand'chose.

Cela dit, un bon artisan a de bons outils... [4]

Ce qui est prôné au travers de l'approche devops c'est la création
d'outils transverses, utilisables par plusieurs équipes (dev, qa,
exploitation, helpdesk, mais aussi marketing etc!) : gestionnaires de
sources, outils de déploiements, de monitoring/visualisation, etc.

Le monde de l'IT est plein d'exemples d'outils peut-être parfaits pour
une catégorie d'utilisateurs mais très mal adaptés aux autres. Le plus
classique de tous ces exemples étant les frameworks de développement
qui permettent de développer vite mais ne simplifient pas la tâche de
ces fameux "admins utilisateurs" que tu cites à très juste titre.

N'importe quel logiciel d'entreprise possède au minimum 2 classes
d'utilisateurs : les "utilisateurs finaux" au sens couramment entendu,
et aussi les administrateurs. RI Pienaar le dit très bien : les logs
et les fichiers de configuration sont bien souvent les seules
interfaces utilisateurs des administrateurs!

Malheureusement cette dernière catégorie est bien souvent oubliée, ce
qui fait que le fonctionnement normal est le plus souvent "un mode
dégradé" : les logs pleines de stacktraces "normales", les fichiers de
configurations trop complexes, l'utilisation de variables
d'environnements qui s'écrasent les unes les autres, l'absence de
métriques, l'absence d'API permettant de communiquer de façon
programatique avec l'applicatif, etc...

> On peut voir cette dichotomie dans la refonte du projet Distutils2

Tu cites un excellent exemple. Je pense pour ma part que le packaging
est l'exemple type du sujet où devs et exploitants s'affrontent à
tord, et où une approche transverse de type devops peut apporter
quelque chose : même au sein de la communauté devops, il suffit de
voir à quel point le débat "ruby vs. debian" peut être passionné pour
se dire que peut-être on essaie de concilier 2 choses inconciliables.

C'est un long débat et je ne veux pas l'aborder ici, mais j'ai comme
avis qu'il faudrait pouvoir apprendre aux gestionnaires de packages
"traditionnels" l'existence de cet "autre monde" qui est celui des
développeurs. Je serais ravi de l'aborder avec des gens intéressés :)

Cordialement,
Gildas
--
[1] les animateurs du devopscafe http://devopscafe.org
[2] http://www.touilleur-express.fr/2010/12/04/prod/comment-page-1/
[3] http://theagileadmin.com/2010/11/05/our-first-cloud-product-released/
[4] et dieu sait que l'informatique "d'entreprise" est perfectible!

Claude Falguière

unread,
Dec 6, 2010, 12:10:14 PM12/6/10
to paris-...@googlegroups.com

"Philippe Muller" <philipp...@gmail.com> a écrit :

Ononpalui ;-)

A+
Claude
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la bièveté.

Sebastien Douche

unread,
Dec 8, 2010, 1:17:26 PM12/8/10
to paris-...@googlegroups.com
2010/12/6 Philippe Muller <philipp...@gmail.com>:

> Et si tu peux passer nous voir lors de la prochaine réunion,
> j'aimerais m'entretenir avec toi sur la gestion des projets Python
> (surtout l'integration continue, le packaging et le déploiement).

Pas de soucis, quand est ce ?

Sebastien Douche

unread,
Dec 8, 2010, 1:30:02 PM12/8/10
to paris-...@googlegroups.com
2010/12/6 Gildas <3ntr...@gmail.com>:

> Bonjour Sébastien,
>
> Je dois dire que ne suis pas surpris de te retrouver ici :)

Je suis si prévisible que cela ? :)

> pour ce retour d'expérience qui vient en complément de ton commentaire
> sur le site d'Institut Agile.

Effectivement, la réponse sur le blog était une première version.

> D'une certaine façon, ton exemple est un peu un "cas particulier",
> d'une part parce que tu as la double compétence, d'autre part parce
> que tu travailles dans une petite société avec un produit bien
> identifié. Dans ces conditions, l'identification de ce qui apporte de
> la valeur est plus facile. Du coup "casser les silos" et lutter contre
> les optimums locaux à chaque équipe est plus facile.

Bouh, c'est pas gentil de dire ça :). Transformer une organisation
pour être orienté flux n'a rien d'évident. On travaille sur 2
(maintenant 3) produits et la R&D possède 4 profils différents.

> Je ne peux pas parler pour Laurent, mais peut-être son point de vue
> était il de dire que la culture doit passer avant la mise en place
> d'outils? C'est un avis qui semble partagé un peu partout : avoir la
> bonne culture est une étape fondamentale pour bénéficier des retombées
> positives d'une approche devops. Sans cela, automatiser à outrance,
> mesurer tout et n'importe quoi n'apportera pas forcément grand'chose.

Certes, mais les outils sont la modélisation de cette culture. Les
outils dev marquent bien le coté dev, idem pour l'admin.

> N'importe quel logiciel d'entreprise possède au minimum 2 classes
> d'utilisateurs : les "utilisateurs finaux" au sens couramment entendu,
> et aussi les administrateurs. RI Pienaar le dit très bien : les logs
> et les fichiers de configuration sont bien souvent les seules
> interfaces utilisateurs des administrateurs!

Tu penses à quoi d'autres ? Un exploit ne saura jamais comprendre le
fonctionnement d'une application.

> Malheureusement cette dernière catégorie est bien souvent oubliée, ce
> qui fait que le fonctionnement normal est le plus souvent "un mode
> dégradé" : les logs pleines de stacktraces "normales", les fichiers de
> configurations trop complexes, l'utilisation de variables
> d'environnements qui s'écrasent les unes les autres, l'absence de
> métriques, l'absence d'API permettant de communiquer de façon
> programatique avec l'applicatif, etc...

Intéressant, il faudrait que tu détailles ce que tu attends.

Laurent Bossavit

unread,
Dec 8, 2010, 2:09:15 PM12/8/10
to paris-...@googlegroups.com
Salut Séb,

>> logs [et] fichiers de configuration sont bien souvent les seules


>> interfaces utilisateurs des administrateurs!
>
> Tu penses à quoi d'autres ? Un exploit ne saura jamais comprendre le
> fonctionnement d'une application.


Ooh, bel exemple du type de préjugé qu'il faut casser. :)

Un exploit' pourra par exemple légitimement se pencher sur un schéma
de base de données, voire sur la logique de certaines requêtes, dans
la mesure où ça peut avoir un fort impact sur les dimensionnements du
hardware nécessaire à faire tourner une appli... et s'il propose une
solution qui divise le nombre de serveurs par 5 qui va s'en plaindre?

Le développeur qui refuse de voir autre chose qu'une machine
virtuelle, pour laquelle les questions d'optimisation ne se posent
pas, peut représenter un risque... Il faut bien que ces préoccupations
soient prises en compte par *quelqu'un* dans l'équipe - mais on se
fout de savoir *comment on appelle* le rôle en question: ça peut aussi
bien être un dév un peu plus cultivé que les autres sur ces questions
de ressources, ou un admin qui a pris la peine d'apprendre à lire du
code.

Après tout ce ne sont que des fichiers texte... :)

A+
Laurent Bossavit
lau...@bossavit.com


Gildas Le Nadan

unread,
Dec 11, 2010, 8:06:11 AM12/11/10
to paris-...@googlegroups.com, Sebastien Douche
On 12/08/2010 07:30 PM, Sebastien Douche wrote:
> 2010/12/6 Gildas<3ntr...@gmail.com>:
[snip]

>> D'une certaine façon, ton exemple est un peu un "cas particulier",
>> d'une part parce que tu as la double compétence, d'autre part parce
>> que tu travailles dans une petite société avec un produit bien
>> identifié. Dans ces conditions, l'identification de ce qui apporte de
>> la valeur est plus facile. Du coup "casser les silos" et lutter contre
>> les optimums locaux à chaque équipe est plus facile.
>
> Bouh, c'est pas gentil de dire ça :). Transformer une organisation
> pour être orienté flux n'a rien d'évident. On travaille sur 2
> (maintenant 3) produits et la R&D possède 4 profils différents.

Non effectivement. Ta remarque est pertinente et je ne voulais en rien
minimiser l'ampleur de ce que vous avez réalisé, bien au contraire.
C'est un formidable exemple qui prouve la faisabilité de ce type
d'approche et ce qu'elle apporte en termes de valeur et de compétitivité
accrue pour l'entreprise qui la met en oeuvre.

Depuis le temps que je défends les approches de type devops, j'ai
tellement été confronté au scepticisme de personnes me disant que cela
ne marche pas pour de grandes entreprises, etc, que je finis par
apporter des précautions oratoires même lorsque cela n'est pas nécessaire.

>> Je ne peux pas parler pour Laurent, mais peut-être son point de vue
>> était il de dire que la culture doit passer avant la mise en place
>> d'outils? C'est un avis qui semble partagé un peu partout : avoir la
>> bonne culture est une étape fondamentale pour bénéficier des retombées
>> positives d'une approche devops. Sans cela, automatiser à outrance,
>> mesurer tout et n'importe quoi n'apportera pas forcément grand'chose.
>
> Certes, mais les outils sont la modélisation de cette culture. Les
> outils dev marquent bien le coté dev, idem pour l'admin.

Tout à fait, d'où l'importance de créer des outils communs, qui cassent
l'effet "optimisation locale" et facilitent le travail des uns ET des
autres.

Oui oui, c'est faisable et non non cela n'est pas un doux rêve!

>> N'importe quel logiciel d'entreprise possède au minimum 2 classes
>> d'utilisateurs : les "utilisateurs finaux" au sens couramment entendu,
>> et aussi les administrateurs. RI Pienaar le dit très bien : les logs
>> et les fichiers de configuration sont bien souvent les seules
>> interfaces utilisateurs des administrateurs!
>
> Tu penses à quoi d'autres ? Un exploit ne saura jamais comprendre le
> fonctionnement d'une application.

Je pense que tu te trompes. Je ne suis pas vraiment développeur, mais je
comprends certains concepts de développement, et je suis à même de lire
du code lorsque celui-ci est disponible et "abordable", afin d'essayer
de comprendre comment certaines choses marchent lorsque cela ne se passe
pas comme on peut l'attendre [1].

De plus, je suis d'accord avec le commentaire de Laurent, il s'agit du
genre d'écueil dans lequel il faut éviter de tomber. D'autre part, si le
fonctionnement d'une application n'est pas clair pour un exploitant,
peut-être manque-t-il de la documentation, ou peut-être le
fonctionnement est-il trop complexe?

Je vois mal comment un exploitant pourrait intervenir sur une
application dont il ne comprends pas le fonctionnement, et encore moins
comment il est à même de vérifier si elle fonctionne, de l'optimiser
etc... Cela dit je suis d'accord, c'est comme cela dans la majorité des
cas, et ce fonctionnement quasi systématique en "mode dégradé" est bien
le problème!

>> Malheureusement cette dernière catégorie est bien souvent oubliée, ce
>> qui fait que le fonctionnement normal est le plus souvent "un mode
>> dégradé" : les logs pleines de stacktraces "normales", les fichiers de
>> configurations trop complexes, l'utilisation de variables
>> d'environnements qui s'écrasent les unes les autres, l'absence de
>> métriques, l'absence d'API permettant de communiquer de façon
>> programatique avec l'applicatif, etc...
>
> Intéressant, il faudrait que tu détailles ce que tu attends.

Ok, j'essaierais de faire l'exercice de détailler plus avant ce que
j'attends. En attendant, je vous propose la lecture du James White
Manifesto https://gist.github.com/161265 (hé oui, les ops aussi
utilisent git ;)).

Cordialement,
Gildas
--
[1] d'oû l'importance à mes yeux de l'opensource : une documentation est
toujours incomplète/fausse. Le code source, lui, est à jour (pour peu
que l'on soit à même de retrouver celui qui tourne en prod/a servi à
compiler le binaire, ce qui est une autre histoire...).

Sebastien Douche

unread,
Dec 11, 2010, 1:24:19 PM12/11/10
to paris-...@googlegroups.com
2010/12/8 Laurent Bossavit <lau...@bossavit.com>:

>> Tu penses à quoi d'autres ? Un exploit ne saura jamais comprendre le
>> fonctionnement d'une application.
>
> Ooh, bel exemple du type de préjugé qu'il faut casser. :)

Je parlais de code métier, déja que les dévéloppeurs eux mêmes ont du
mal à s'y retrouver, je vois mal un admin (et encore moins un exploit)
capable de comprendre le coeur d'un code maison. Non seulement il faut
comprendre la techno et le langage, mais en plus le métier et bien
connaitre l'historique du projet.

> Un exploit' pourra par exemple légitimement se pencher sur un schéma de base
> de données, voire sur la logique de certaines requêtes, dans la mesure où ça
> peut avoir un fort impact sur les dimensionnements du hardware nécessaire à
> faire tourner une appli... et s'il propose une solution qui divise le nombre
> de serveurs par 5 qui va s'en plaindre?

Tu parles de SGBD, dont les interfaces sont parfaitement normalisées.
Et encore, quand je vois la gueule de nos requêtes (long comme mon
bras), j'ai des doutes.

C'est bien parce que j'ai conscience de l'impossibilité de rentrer
dans le projet que j'ai voulu normaliser le plus possible la gestion
extérieure.

> Le développeur qui refuse de voir autre chose qu'une machine virtuelle, pour
> laquelle les questions d'optimisation ne se posent pas, peut représenter un
> risque...

Hors propos, je parlais coté admin (et cf mon mail initial pour voir
comment nous fonctionnons)

> Il faut bien que ces préoccupations soient prises en compte par
> *quelqu'un* dans l'équipe - mais on se fout de savoir *comment on appelle*
> le rôle en question: ça peut aussi bien être un dév un peu plus cultivé que
> les autres sur ces questions de ressources, ou un admin qui a pris la peine
> d'apprendre à lire du code.

Je suis d'accord, mais "apprendre à lire du code", ca met des années
avec une personne correctement cablée. La est amha, la faille de ton
raisonnement, tu laisses le point le plus difficile de coté :). J'ai
pas mal de potes qui codent pour les projets Debian, FreeBSD ou NetBSD
par exemple et qui sont admin (le monde du libre donnent beaucoup
d'exemples). Mais ceux sont des gens qui aiment coder et qui le font
depuis des années. Rien a voir à prendre un admin et l'apprendre à
coder.

Reply all
Reply to author
Forward
0 new messages