Préparation du déploiement de la v1.4

Celle-ci est bonne pour un hotfix… si quelqu'un a une idée de ce qu'il faut y faire

Ça ressemble au genre de chose qu'on avait quand on oubliait de mettre à jour ces requirement quand on testait des trucs de Firm1 avec la GitPython.

Il sont faits automatiquement par le script de deploy.

Je dis pas le contraire, je dis juste que j'ai déjà vu cette erreur quelque part

J'ai rajouté les IDs pour les réseaux sociaux, mais il semblerait qu'on ait un bug (testé uniquement avec Twitter)

Donné qu'actuellement et pour des raisons tout à fait soutenables nous Spacefox a décidé que plus rien ne serait mergé (et je soutiens cette décision à 100%, ça devenait trop dur à suivre pour tout le monde), mais que le développement continue et que la QA a trouvé son propre rythme de croisière, peut-on créer soit :

• une nouvelle branche "en attente pour la v1.5" (ou v2015) où on pourrait merger sans avoir à embêter les DTC ;
• un tag sur Github "mergeable" qui signifierait que la QA a été faite mais que comme on n'a pas les ressources pour merger, on va attendre qu'elles reviennent.

Je suis plus favorable à la seconde option, mais j'aime bien toujours en donner au moins deux pour qu'on puisse avoir le choix.

Heu non pas du tout. Ici j'exposais l'alternative, et vu que tout le monde est motivé ici je lance une release 1.4.

La contrainte étant qu'on a pas 2 semaines mais un peu moins : le 23 au soir, elle doit être MEP ou abandonnée.

En attendant, les merges vers la future v1.5 continuent (d'ailleurs, il y a une milestone à utiliser pour les nouveaux merges dans dev).

Ca serait meme cool si on MEP le 22 pour hotfixer le 23 et etre tranquille le 24

Tous les hotfix ont été mergés et déployés en préprod (v1.4-RC2).

Tous les hotfix ont été mergés et déployés en préprod (v1.4-RC3).

La v1.4 est en prod.

Par contre, maintenant c'est définitif : les développeurs de node.js et/ou npm et/ou bower sont des clowns doublé d'incompétents. En vrac :

• La réinstall qui te dégage la dépendance del (comment c'est possible ? Je ne sais pas)
• Le script d'install qui va directement chercher les releases stables sur Github. Et qui donc t'oblige à ce genre d'horreurs
• Ce qui est fait en préprod n'est pas toujours reproductible en prod. La preuve ce soir (40 minutes de perdues)
• Les niveaux de logs qui sont soit totalement absents, soit tellement verbeux que tu ne peux rien comprendre
• L'installation qui mets 10 ans

Par contre à côté de ça, y'a des curseurs qui tournent des couleurs partout et des pseudo-icônes en UTF-8. Joli sens des priorités les gars.

J'ai beau être très sérieusement d'accord, je vois pas comment on pourrait faire sans npm.

je vois pas comment on pourrait faire sans npm.

Il n'y a plus qu'a espérer que npm se comporte correctement alors. Parce que c'est valable dans l'autre sens : on ne peut pas rester avec un outil aussi incohérent s'il refait ce genre de conneries.

Je rappelle qu'on parle d'un environnement de production là, pas d'un environnement de développement. L'instabilité et les systèmes bloqués 40 minutes parce que l'outil a décidé de faire n'importe quoi et ce de manière non reproductible entre les environnements (j'insiste sur ce point, c'est vraiment ça le problème) ne sont pas des options !

PS : je le reprécise : tant que ça marche, on ne touche rien et on continue à l'utiliser. Par contre, la moindre MEP foireuse avec des différences significatives entre prod et préprod sera la dernière.

Par curiosité (mais peut-être vaut-il mieux un MP) pourquoi ça "bloque" la release ?

Que le build soit long ou foire, normalement une mise en prod de fichiers estampillés "front" ça se limite (une fois que le build est terminé) à une copie de fichier, non ?

Bah ici il faut croire que non… ici j'ai suivi ces instructions pour transformer l'install foireuse de npm de prod (problèmes de droits, etc) en install propre. Sauf que visiblement il n'y a pas de copie de quoi que ce soit : ça a directement dégagé les fichiers servis par le front.

Et après ça a été la misère (cf mon post sur le déploiement) pour les faire re-fonctionner et régénérer ces fichiers. Parce que oui, la procédure je l'avais jouée en préprod et tout avait fonctionné du premier coup !

Mmmh ça me semble pas sain du tout comme façon de builder l'app en prod, ou alors j'ai pas compris.

Pour moi la prod c'est une simple copie de la pré-prod.

Avant une MEP, on build TOUT le projet jusqu'à obtenir tous les fichiers prêts à être copiés (notamment : les fichiers minifiés, les sprites, …). Que tout ça soit foutu dans un zip ou autre.

Le process de MeP devient alors :

• éteindre le serveur

• (mise à jour schéma BDD si besoin, script de migration si besoin)

• copie de fichier (et uniquement ça) (qu'il s'agisse de fichiers Python ou de fichiers front peu importe)

• relancer le serveur

Ça me paraît fou que ce soit npm qui build ET qui fasse la copie de fichier, s'il merde pour une raison X ou Y c'est la cata assurée.

Faut se servir des outils de build style gulp npm c'est clair, mais faut pas qu'ils aillent écrire directement sur la prod, c'est de la folie ??

Je suis assez d'accord…

C'est nginx qui s'occupe de servir les fichiers statiques ? Si oui, pourquoi ne pas simplement le faire pointer sur un autre dossier que dist/, et copier le dist/ à la main ? C'est un truc propre à la prod, je vois pas pourquoi vous ralez après npm pour ça, alors que c'est le comportement normal, et que ce genre de détails, c'est à celui qui mets en prod de régler…

Le script d'install qui va directement chercher les releases stables sur Github. Et qui donc t'oblige à ce genre d'horreurs

Ca serait pas pour css3-mediaqueries-js qu'il fait ça par hasard ? Si oui, je crois savoir pourquoi, et comment régler

Ce qui est fait en préprod n'est pas toujours reproductible en prod. La preuve ce soir (40 minutes de perdues)

Je ne sais pas ce qui a été fait sur preprod ; il me faudrait un accès pour investiguer un peu plus profondément, et pas juste demander de lancer deux trois commandes à travers un forum ou IRC. Je veux bien essayer de régler les soucis, mais la, c'est juste plus possible. Il ya un truc foireux dans l'une des deux install, et je veux trouver quoi.

Les niveaux de logs qui sont soit totalement absents, soit tellement verbeux que tu ne peux rien comprendre

Ca, c'est parce qu'avant il détaillait chaque GET pour chaque dépendances. Sauf qu'avec node, des sous-dépendances, en général t'en a facile quelques centaines, du coup, c'était vite pollué. Du coup, maintenant y'a ce genre de spin, mais il détaille rien. Par contre, certains modules nécessitant un build (genre pour du code C natif), il affiche les logs. Du coup, c'est un peu anarchique. C'est le cas de gulp.spritesmith, qui tente d'installer plusieurs "moteurs" qu'il utilise pour la génération de sprite. Comme la plupart nécessitent au moins une dépendance "autre" (genre Grafikmagick, ou Cairo), ces modules fails pendant l'install, et ca pollue les logs.

L'installation qui mets 10 ans

La, c'est quand même particulier. On t'a fait vider tout le cache NPM, et tout réinstallé. Forcément c'est long. Pour un update, c'est beaucoup plus court

C'est nginx qui s'occupe de servir les fichiers statiques ? Si oui, pourquoi ne pas simplement le faire pointer sur un autre dossier que dist/, et copier le dist/ à la main ? C'est un truc propre à la prod, je vois pas pourquoi vous ralez après npm pour ça, alors que c'est le comportement normal, et que ce genre de détails, c'est à celui qui mets en prod de régler…

Pourquoi ? Parce que je n'ai ni installé ce serveur, ni décidé de la pile logicielle. La procédure d'install n'a pas été documentée.

Aussi parce que la dernière fois que j'ai demandé si c'était normal qu'avec cette pile on génère directement les fichiers en prod, on m'a dit que oui c'est normal. Il faudrait savoir.

Ca serait pas pour css3-mediaqueries-js qu'il fait ça par hasard ? Si oui, je crois savoir pourquoi, et comment régler

Non, c'est jQuery… c'est exactement l'erreur du lien que j'ai cité dans le post qui parle de la MEP.

Je ne sais pas ce qui a été fait sur preprod ; il me faudrait un accès pour investiguer un peu plus profondément, et pas juste demander de lancer deux trois commandes à travers un forum ou IRC. Je veux bien essayer de régler les soucis, mais la, c'est juste plus possible. Il ya un truc foireux dans l'une des deux install, et je veux trouver quoi.

Mon problème est qu'au-delà d'un problème foireux dans l'une des install, il y a un problème dans une reinstall et que des procédures qui ont marché ne fonctionnent pas sans raison logique.

Et le fait que la gestion de dépendances est merdique : ici par exemple le script avait besoin de del mais ne l'a pas réinstallé.

J'ai pas tout lu mais je vais le dire encore une fois : Django a un outil dédié (python manage.py collectstatic) pour faire ça. Ce qu'il faut c'est générer les fichiers statiques du front dans un dossier A puis Django lors de sa compilation (qui comprend aussi les fichiers statiques de l'admin, je sais pas comment ce bordel est servit aujourd'hui) les envoie vers un dossiers B (ça permet norament de les versionner !) et nginx tape dans le dossier B.

C'est beaucoup plus sain…

NB : entre pré-prod et prod vous ne devriez même pas avoir à rebuilder tout les fichiers du front non ? Le seul truc qui pourrait justifier ça à mes yeux c'est des URL en dur et ça m'étonnerait qu'il y en ait.