J'ai voulu déployer la v1.7-RC1...

Je ne suis pas content.

J'ai voulu déployer la v1.7-RC1, première étape de la v1.7.

Alors, dans l'ordre :

1. Le update.md ne ressemble à rien.
2. Le nom du paramètre à modifier est ZDS_APP et non ZDS_SITE.
3. Partant du principe que ce n'étaient que des bugs cosmétiques, j'ai quand même lancé la release, parce qu'elle commence déjà à être trop grosse.
4. Vous pouvez voir le résultat en bêta. Très intéressant non ?

Intégralité des logs npm :

1
2
3
4

deploy.sh: ligne49: /usr/local/nvm/nvm.sh: Aucun fichier ou dossier de ce type
npm WARN unmet dependency /opt/zdsenv/ZesteDeSavoir/node_modules/gulp-streamify/node_modules/gulp-util/node_modules/through2 requires readable-stream@'~1.0.17' but will load
npm WARN unmet dependency /opt/zdsenv/ZesteDeSavoir/node_modules/gulp-streamify/node_modules/readable-stream,
npm WARN unmet dependency which is version 1.1.13

Trace de l'un des appels :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Unable to reach Sentry log server: timed out (url: http://sentry.kisai.info/api/2/store/)
Traceback (most recent call last):
  File "/opt/zdsenv/local/lib/python2.7/site-packages/raven/transport/threaded.py", line 159, in send_sync
    super(ThreadedHTTPTransport, self).send(data, headers)
  File "/opt/zdsenv/local/lib/python2.7/site-packages/raven/transport/http.py", line 49, in send
    ca_certs=self.ca_certs,
  File "/opt/zdsenv/local/lib/python2.7/site-packages/raven/utils/http.py", line 62, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 401, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 419, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 379, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1211, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1034, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
timeout: timed out
Failed to submit message: u"ValueError: The file 'css/only-ie.min.css' could not be found with <django.contrib.staticfiles.storage.CachedStaticFilesStorage object at 0x5539c90>."

Je suis comme prévu injoignable jusqu'à lundi soir.

Que ceux qui ont accès à la préprod regardent ce qu'il se passe.

Je suis coupable des erreurs en ce qui concerne le update.md et le mauvais nom de la variable à modifier ! Désolé

1

deploy.sh: ligne49: /usr/local/nvm/nvm.sh: Aucun fichier ou dossier de ce type

Sandhose a apparemment supprimé nvm de la prod et béta mais n'a pas modifié le script de déploiement.

ça a un rapport avec cette PR ?

Ah. Je me disais aussi qu'il y avait un soucis dans le update.md. Je tente à chaque fois de le corriger avec cette PR. Au fait, à propos de ladite PR, je suis paumé, du coup, elle passera en 1.8 (auquel cas je suis OK) ou en 1.7 ? (auquel cas il va encore falloir que je re-re-re-remodifie¹ le update.md )

Bon j'ai fait un tour sur la preprod et voici l'état des lieux :

1. nvm ne s'installe pas sous /usr/local/nvm/nvm.sh en suivant les instructions de base.
2. la version de node du système est en 0.10.27 et npm est à 1.4.2

Je crois qu'il va falloir mettre définitivement une croix sur nvm, car là on est plus iso-prod a ce niveau. A moins qu'on copie notre serveur de prod sur la préprod (mais ça demande du travail de paramétrage en plus - htaccess, anonymisation, etc. - )

Ceci dit, si on se débarrasse de nvm, il faudra mettre à jour les paquet node/npm du système vers les versions actuellement utilisés par ZdS (npm >=2). La conséquence ici, est que la MEP de zds 1.7 risque de durer plus longtemps que d'habitude (install, tests, etc.).

La conséquence ici, est que la MEP de zds 1.7 risque de durer plus longtemps que d'habitude (install, tests, etc.).

On peut le faire avant la MEP avant que le serveur ne soit coupé ?

nvm n'est pas nécessaire sur la préprod puisque node est installé globalement. Donc le fait qu'il arrive pas à charger le script ne fait juste… rien

Ensuite, vu qu'on veut pousser les fichier compilés au lieu de les compiler en prod, je me suis dit que c'était pas la peine de virer nvm au profit de node installé globalement sur la prod. Donc faudrait mettre à jour le script de deploy en mettant en paramètre si on doit build le front ou non (donc si on est sur la prod ou sur la preprod), et virer le chargement de nvm. En attendant, le fait que le script fail n'a aucun impact sur la MEP sur la preprod.

Et du coup comment tu explique que la preprod est down ?

Ca, je n'en sais rien, je sais juste qu'a priori, ça n'a rien à voir avec cette erreur, puisque, pour avoir testé à l'instant, lorsqu'on "source" un fichier qui n'existe pas dans un script shell, ça n'arrête pas le script. Après, peut-être que ça peut venir de la version de node qui semble être en 1.4 (alors que je suis persuadé de l'avoir mis à jour la dernière fois…), ce qui peut être reglé via sudo npm install -g npm.

EDIT: Après relecture du premier post, il s'agit effectivement d'une mauvaise génération du front, à cause de la version de npm. Pour régler ça, npm run build && python manage.py collectstatic

C'est bien la conclusion que j'ai présenté quelques poste plus haut. Sauf qu'il faut hotfixer la release (pour virer nvm et rajouter les actions pour la mise a jour nvm). Ainsi on s'assure que le tout reste cohérent et que le bug soit fixed by code

Je ne crois pas que ça soit au code de deploy de s'assurer qu'il y ai la bonne version de node/npm d'installé… A mon avis, ce qui s'est passé, c'est qu'il y a eu une mise à jour de node depuis les dépots de debian, qui a écrasé la version installée de npm (2.x) pour la version des dépots (1.4.x)

Bref, j'ai quand même fait un hotfix pour virer l'erreur, et pour permettre le déploiement même si y'a pas la bonne version de npm installée https://github.com/zestedesavoir/zds-site/pull/2453

Bon. Ca sent fort le foutage de gueule intégral par ici.

Le update.md ne ressemble à rien.

2 semaines et y'a pas de PR pour corriger.

Le nom du paramètre à modifier est ZDS_APP et non ZDS_SITE.

2 semaines et y'a pas de PR pour corriger.

Bon, vu que c'est de la connerie, je vais le corriger. Mais vraiment, ça me donne l'impression que personne à par moi n'a quoi que ce soit à foutre de ces releases. Et c'est pas comme si y'avait une issue "Régression bloquante".

J'en viens à me demande si ça vaut vraiment le coup que je continue à m'investir dans la maintenance de cette application, côté déploiement et serveurs, vu que visiblement même en laissant 2 semaines et des tickets en rouge et jaune rien ne bouge. Y'a des moments où j'ai l'impression de bosser avec des collègues démotivés et pas avec des gens adultes et responsables qui essaient de faire avancer un projet aussi génial que ZdS.

Pour ceux qui se posent des questions : oui ça me gonfle, et oui c'est complètement un avertissement. La prochaine release, si elle ressemble à ça, ce sera la dernière que je ferai.

J'espère que c'est plus clair comme ça et que je ne serai plus le seul à me sentir concerné ?

@SpaceFox,

Aïe. J'aime pas les coups de g*** à chaud, parce que ça part toujours en sucette. Même quand c'est justifié comme dans ce cas-ci.

Bon. Je crois que le gros problème ici, c'est "communication". Partant du principe que tout le monde est de bonne volonté (ce qui est probablement le cas), j'avais, très objectivement, pas compris que c'était ça qui bloquait la release, sinon je l'aurait fait il y a longtemps (et, même si c'est facile de dire ça, je l'avait déjà fait, même si c'est pas la bonne manière de faire et que c'est absolument hors-scope de ladite PR). J'ai surtout bloqué sur les problèmes habituels de NPM/NVM/whatever (probablement parce que le message d'erreur faisait 3/4 du post initial). Par ailleurs, j'avoue très franchement me limiter à la QA et au dev de la ZEP-12 de ces temps-ci, et donc ne pas fourrer mon nez dans la liste des issues (ce qui est très égoïste de ma part, j'en conviens).

De là, deux constats/solutions:

• Puisque la communication est dégueu, améliorons là. On crée un MP qui rassemble tout les devs, et dans lequel seul toi à le droit de dire des choses en rapport avec les MEPs, que ça concerne la mise en bêta ou en production. Qu'on le lise ou qu'on le lise pas est une autre histoire, mais au moins, on se mange une notif. C'est ça ou la mailing list.
• L'autre problème que je vois, c'est que comme tu le mentionne intrinsèquement, tu es tout seul à le faire. Je ne sais pas pourquoi ni comment (ça doit être lié à de la gestion des droits à un moment), mais il se trouve que comme toute personne avec ce genre de responsabilité, tu pêtes une quille au bout d'un momentn parce que t'as l'impression que personne ne respecte ton travail (alors que sans ça, ZdS est mort coté dev, qu'on s'entende bien). Bref. Trouve une autre personne et switchez une fois sur deux, ça ira surement un peu mieux.

Bref, on t'aime <3

(cet avis n'engage que moi, bien entendu)

Ah c'est pas un coup de gueule à chaud hein. Il a eu 2 semaines pour refroidir celui-ci…

j'avais, très objectivement, pas compris que c'était ça qui bloquait la release, sinon je l'aurait fait il y a longtemps

J'ai fait un ticket taggué "régression bloquante". Je ne sais pas faire mieux. Le problème est sans doute dans cette phrase :

et donc ne pas fourrer mon nez dans la liste des issues

Alors, on me dira que ce ticket renvoyait ici. Certes.

Mais du coup, pourquoi personne n'a posé la moindre question ? En fait c'est une question générale et j'ai l'impression que le problème général est là : je pars en WE prolongé + je suis la crève = je disparaît presque 2 semaines en laissant une release en plan et personne ne semble se poser de question.

Mais là encore c'est pas un coup de gueule à chaud hein. Autant les tickets et les merge ça avance à peu près correctement, autant le reste…

Pour les solutions proposées :

1. Je ne pense pas que le MP soit une solution. Parce que forum + MP + Github on ne s'en sortira pas. Et puis qui est-ce qu'on mets dans le MP ?
2. Oui, il faudrait quelqu'un d'autre, mais qui ?

Bon, j'aurais essayé

Le problème est sans doute dans cette phrase :

et donc ne pas fourrer mon nez dans la liste des issues

Jamais dit le contraire.

Mais du coup, pourquoi personne n'a posé la moindre question ? En fait c'est une question générale et j'ai l'impression que le problème général est là : je pars en WE prolongé + je suis la crève = je disparaît presque 2 semaines en laissant une release en plan et personne ne semble se poser de question.

L'absence de réponse à ce sujet est symptomatique: ou qu'ils sont les gens ?

Mais là encore c'est pas un coup de gueule à chaud hein. Autant les tickets et les merge ça avance à peu près correctement, autant le reste…

Je te dirais bien qu'on ne peut pas le deviner tout seul ce qui ne va pas, malheureusement. Ce qui marche encore bien, c'est de le dire haut et fort Zest'Meeting, en général ce qui s'y dit est suivi d'action. En général. Et étant habitué au couplet "la release c'est mal passée parce que NPM [insérez ici un flot considérable d'injure]", je ne pense pas me souvenir que tu aies dit un jour "la release c'est mal passée parce que les devs font pas les choses correctements".

Fait une liste, chaipas, moi, dit nous ce qui va pas, comment on peut mieux faire … J'essaye de décrypter, moi

EDIT: d'accord, un des points de ladite liste est "lire la liste des issues", bien reçu.

… J'aurais essayé

[HS]Bon, un peu de psycho de comptoir: t'as réussi ton coup, tu menaces de nous planter et je réagi au quart de tour. L'humain est bien fait, quand même [/HS]

En fait, c'est même pas spécialement un 2ème DTC qu'il faudrait mais un chef de projet.

Parce que ce qui me gonfle, c'est principalement de la gestion de projet qui n'est pas faite, et je rappelle que j'ai accepté un poste de direction technique et pas du tout, mais alors pas du tout de gestion de projet.

Moi j'veux bien donner des coups de fouet !!

Concrètement, tu cherche quelqu'un pour faire quoi ?

Le travail de gestion de projet en fait :

• Organiser les Zest'Meeting
• Vérifier que les trucs qu'on a dit qui avanceraient avancent
• Relancer les gens sur les tickets
• Etc…

Aujourd'hui, soit c'est pas fait, soit c'est moi qui le fait et ce genre de chose me sors par tous les orifices. En y réfléchissant, une bonne partie de mes prises de têtes de ces derniers temps, c'est des problèmes de gestion de projet et pas des vrais problème techniques.

Or, si j'en crois les voeux de sortie d'école, la gestion de projet c'est le genre de chose que tout le monde voudrait faire donc j'en déduis que ça ne devrait pas être trop difficile de trouver quelqu'un motivé pour ça ?

Perso je serais pas contre me pencher sur ces aspects plus fonctionnel que technique. J'ai pas vraiment le temps/l'envie de faire du technique en ce moment (a part de la QA pour dépanner ou si je suis d'humeur) mais je veux continuer d’être utile au dev' du projet en parallèle de ma production de contenu. Du coup si personne de plus qualifiés ne veut s'y coller je veux bien m'y mettre

Je laisse juge de mes compétences les gens qui auront bossé avec moi sur la technique de ZdS ou sur les différents import de (très) gros tutos que j'ai mené récemment (arduino + la surprise qui arrive)

Aujourd'hui, soit c'est pas fait, soit c'est moi qui le fait et ce genre de chose me sors par tous les orifices. En y réfléchissant, une bonne partie de mes prises de têtes de ces derniers temps, c'est des problèmes de gestion de projet et pas des vrais problème techniques.

Or, si j'en crois les voeux de sortie d'école, la gestion de projet c'est le genre de chose que tout le monde voudrait faire donc j'en déduis que ça ne devrait pas être trop difficile de trouver quelqu'un motivé pour ça ?

Vu la considération qu'apporte un des membres clés de ce projet à ce type de poste, ça fait pas rêver d’être PM de ZDS…

Moi je pense que la plus grosse difficulté de ce poste c'est la gestion de l'humain (comme souvent ceci dit) : pas facile de faire avancer des tickets à des bénévoles.

Mais si Eskimon est motivé, essayons.