Mises en production pendant la bêta publique

a marqué ce sujet comme résolu.

Bonjour à toutes et à tous !

Voici un topic pour vous prévenir des mises en production pendant la bêta publique (on vous fera sans doute des articles après, c'est à discuter).

Je commence :

MEP du 11 juillet au soir

Le soir, heure française. Je ne sais pas plus précisément. "Quand ce sera prêt", i.e. au moins dans une heure.

Change log :

En prime, la commande pour générer le changelog :

1
git log v1.0-RC3...v1.0-RC4 --pretty=format:'- [%s](https://github.com/zestedesavoir/zds-site/commit/%H)' --reverse | grep -v Merge
+9 -0

J'ai comme l'impression que les fichiers js minifiés n'ont pas été regénérés. En tout cas, dans le main.min.js, le changement du lien vers l'aide markdown complète n'est pas répercuté.

+0 -0

C'est corrigé.

En fait hier soir, il n'y avait pas eu de vraie mise en production, puisque le code ne s'était pas mis à jour correctement… une sombre histoire de gestion des tags avec une vieille version de git, dans laquelle les tags n'étaient pas correctement mis à jour.

Je met à jour les scripts pour que ça ne se reproduise plus !

+2 -0

J'y ai pensé, mais je n'ai pas trouvé de moyen de le faire automatiquement :(

Du coup pendant la bêta, on a tellement de travail à côté que j'ai laissé tomber.

C'est une idée à conserver pour les versions publiques.

PS : Je me dis que seul l'historique des tickets / PR serait même plus digeste que l'historique des commits, d'ailleurs.

+0 -0

Le seul outil que je connais pour les changelogs, c'est Grunt mais je ne l'ai jamais utilisé personnellement et l'utilisation que j'en ai vu, c'est pour les commits.

Donc oui, peut-être à laisser tomber dans un premier temps mais ça aidera sûrement si on rédige des articles plus tard. C'est pas super accessible au grand public des liens directs vers le code source. ^^

+0 -0

MEP dans la nuit du 13 au 14 juillet

Elle s'est déroulée au environ de 03h (heure en Allemagne). Le changelog est celui-ci.

NB : Je précise que cette MEP a une influence dans le module des tutos et résoud pas mal de bug. Cependant, il se peut que les tutos déjà entamés posent certains problèmes (j'ai du réimportés les tutos importés du compte externe pour pouvoir les publier hier nuit).

Il faut donc rester attentif, et si un auteur a ce problème, qu'il n'hésite pas à rebondir ici.

+4 -0

MEP du mardi 22 Juillet

Elle a ete faite à 07h du matin.

Voici son Changelog :

NB : Encore des modifications sur les tutos on été faites, restez donc attentifs.

+2 -0

Tout s'est bien passe sinon ?

Des couac comme d'habitude (je commence a avoir l'habitude avec gulp) et impossible de merger master dans dev (il y'a des conflits, il faudra faire une PR + QA).

Mais globalement ça marche bien.

En fin de journée il y avait des erreurs 500, ce serait lie a cela ?

Non, les erreurs 500 étaient liés à la publication d'un tutoriel (celui de mewtow). Je pense que le nombre d'images présent dans le tuto a ralenti sa publication, et visiblement cette publication à tué un worker de gunicorn. Il faudra trouver un moyen de parametrer gunicorn pour qu'il supporte ses workers supportent la charge. En attendant, il faut publier les gros tutos comme ça, à des heures de faible connexion.

+1 -0

Tout s'est bien passe sinon ?

Des couac comme d'habitude (je commence a avoir l'habitude avec gulp) et impossible de merger master dans dev (il y'a des conflits, il faudra faire une PR + QA).

firm1

D'où le fait d'être un peu plus strict vis à vis du git flow : quand on merge quelque chose dans master, il faut également le merger dans dev (à la main). Si quelque chose arrive dans prod, il faut le merger à la main dans master et dans dev.

Comme ça on garde des branches à jour sans avoir de merge dégueulasses dans tous les sens, jusqu'a plus s'y retrouver et avoir à chaque fois X conflits.

+0 -0

Puisqu'un fixe arrive sur la branche du dessus, que celle-ci part d'une des branches d'en dessous, que ce fixe a été QAisé, alors on peut faire un raccourci comme quoi le fixe est compatible avec les branches d'en dessous. Ça relève même pas du git flow, mais de git tout court en fait.

Y'a donc pas de "porte ouverte aux régressions". Eventuellement des mini-conflits (et encore…) lors du merge sur les branches d'en dessous. Mais en tout cas ça ferme des portes à des plus gros conflits et des merdes comme on en a présentement demandant de faire des PR incestes…

+0 -0

A la rigueur, réouvrir unr PR sur plusieurs champs. Mais y'a peu ou pas de raisons pour qu'il y ait des conflits, ou alors c'est qu'il y a eu une chaussette quelque part (une résolution sur plusieurs fronts, ce qui est mauvais en soit)

+0 -0

Bah regarde l'État des branches dev et prod. Il y'a eu des travaux sur la dev (c'est normal c'était pas du bugfix dédié a la master) et pendant ce temps y'a eu du bugfix sur la master.

Le conflit est arrivé (et ça arrivera encore). Donc il faut faire une QA, et pour ça le seul moyen c'est de faire une PR du truc qui fixe les conflits.

+0 -0

Je viens de voir à l'instant la mise en production du jour et je me pose une question : c'est cool d'avoir Clem sur la page d'accueil par contre le champ de recherche juste à coté ne fait-il pas redondant avec celui qu'il y a en haut à droite ?

+1 -0

Bah regarde l'État des branches dev et prod. Il y'a eu des travaux sur la dev (c'est normal c'était pas du bugfix dédié a la master) et pendant ce temps y'a eu du bugfix sur la master.

firm1

A la rigueur, réouvrir la PR sur plusieurs destinations

Talus

Je complète donc : plusieurs destinations, soit dev, master, … etc. Une fois la PR de base mergée sur la branche visée au départ.

Car, je le répète : merger master dans dev, puis prod dans master (etc), c'est juste du merge inceste - voir pire, c'est un complexe oedipien -. Ce qui est juste dégueulasse. Et énorme source de conflits.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte