Amélioration du processus d'approbation d'une pre-release

tcharp38 commented 4 years ago

Salut Kiwi

Je suis un peu perdu. Cette derniere release est une regression pour moi. Je note qq points qui ont disparu

Page de config.. aucune de mes dernieres modifs
Page santé... plus de status des démons

Une idée ?

KiwiHC16 commented 4 years ago

Pensez à la cagnotte: http://kiwihc16.free.fr/index.html#cagnotte

KiwiHC16 commented 4 years ago

Tes derniers PR sont dans le master et pas encore dans la stable. Je vais sortir encore une stable demain qu'avec des corrections. Ces dernieres semaines j'ai surtout travaillé sur la stabilisation avant d'ajouter toutes les dernieres évolutions. C'est la branche stabilisationProd.

KiwiHC16 commented 4 years ago

Je pense pouvoir regarder la master pour la stabiliser dans les semaines à venir.

tcharp38 commented 4 years ago

J'ai une suggestion pour la sortie de nouvelles "stables". Il faudrait

definir une branche speciale "release candidate" si n'existe pas deja
avoir un panel d'utilisateurs ayant accepté de jouer avec
et sortir la stable si green light de 80% du panel par ex (comme ca pas de blocage si certains ne regardent meme pas) Un process comme ca permettrait d'avoir une meilleure couverture sans que ca soit tout pour ta pomme.

Bien sur et ca me semble important, il faudrait arriver à sortir des stables + souvent. A ce stade je vois beaucoup de soucis dans les forums qui sont deja traites ou fixés dans le master. C'est dommage du coup de faire du support/debug sur des trop vielles moutures. Perso, je m'y perds.

Tu penses quoi de tout ca ?

KiwiHC16 commented 4 years ago

Oui on peut avoir une "release candidate" qui peut etre la version Beta dans le market. Mais jusqu'à present je n'ai jamais eu (tres peu) de retour sur les beta. Le soucis aussi est que jusqu'a present il y avait des evolutions tres lourdes qui ont provoqué pas mal de soucis. Donc maintenant nous devrions pouvoir sortir des Stable à chaque correction. Si tu as le temps/courage de mettre en place une equipe de beta tester ca serait cool. On peut imaginer, sortir une beta/release candidate toutes les semaines et si au bout d'une semaine beta tester ok on l a sort en stable. Je manque aussi de temps...

tcharp38 commented 4 years ago

Ok je vais reflechir à ce qu'on peut faire. Mais une release toutes les semaines.. c'est beaucoup. J'avais en tete plutot qqch comme une fois par mois max (sauf release urgente). Ca me semble honnete et pas allourdissant. Faut juste que le process soit un peu + robuste pour eviter de sortir des regressions.

KiwiHC16 commented 4 years ago

Je suis d'accord. Actuellement mon soucis est de stabiliser ma propre installation car depuis deux ans je teste les Release Candidate et mon systeme est souvent impacté.

J'ai un systeme de dev (je peux mettre 2 zigate dessus voir plus si necessaire), un systeme de prod (ma propre domotique, 4 zigates dessus), peut etre devrais je avoir un systeme pre-release avec un vrai reseau de test que je ne touche pas car doit être stable come celui d'un utilisateur (avec une zigate car ca doit etre la config la plus standard des utilisateurs).

Combien as tu de reseau ?

tcharp38 commented 4 years ago

Par experience la meilleure couverture est obtenue par le + grand nombre d'utilisateurs. Tu as beau creer des systemes de test specifiques, tu sera toujours dans un cas assez limité, et qui reste specifique à ce à quoi tu as pensé.

Pour ma part j'ai toujours depuis le debut un systeme reel que j essaie de limiter aux "stables" et 2 systeme de test mais qui du coup ne couvrent tres peu. Par ex mes volets... ben ils restent sur le systeme reel. Je n'ai bien sur pas de volets "spare" pour faire joujou avec.

Bref, tout ca pour dire qu'on a besoin de l'aide d'une petite communauté de gens pret à jouer avec une release candidate.

KiwiHC16 commented 4 years ago

Je suis tout a fait en ligne et c est meme la raison d'avoir fait ce plugin en open source et sur le market jeedom car au debut je le faisais dans mon coin...

KiwiHC16 commented 4 years ago

Il semble que la master tourne correctement sur mon systeme de dev. Est ce qu'on essaye de sortir une nouvelle stable ?

tcharp38 commented 4 years ago

Tout à fait partant. Je l'ai mis sur mon systeme actif que ne faisais que du stable et j'ai vu de sacré améliorations de mon côte.

KiwiHC16 commented 4 years ago

J'ai fait appel a des beta tester: https://community.jeedom.com/t/prochaine-stable-appel-a-volontaires-pour-test-beta/33554

tcharp38 commented 4 years ago

Super ! Mais peut etre faudrait il preciser les instructions pour basculer sur une prerelease. C'est jouable sans maitriser SSH ou GIT ?

KiwiHC16 commented 4 years ago

Ok dans ce cas je fait une branche depuis master, je l appelle "beta-dev". Quand nous aurons fait nos tests, on fera une branche "beta" pour la publier sur le market jeedom pour avoir un retour beta tester. Si on fait des corrections on les fait sur la "beta-dev". Ces corrections ont les portent aussi sur la master. Si on fait des evolutions on les fait sur le master. Quand on a fait des corrections sur la "beta-dev" et qu on pense qu'ils sont assez bons on re-publie une "beta". Quand nous n'avons plus de retour négatif sur la "beta" on la passe en "stable".

Ca te va ?

KiwiHC16 commented 4 years ago

Sur le market ils ont acces soit à la stable soit a la beta si ils sont déclarés beta tester chez jeedom. Je ne suis pas sure de la manip mais il doit suffir de choir la version dans le market lors de l installation. (Il faut verifier)

tcharp38 commented 4 years ago

Ok dans ce cas je fait une branche depuis master, je l appelle "beta-dev". Quand nous aurons fait nos tests, on fera une branche "beta" pour la publier sur le market jeedom pour avoir un retour beta tester. Si on fait des corrections on les fait sur la "beta-dev". Ces corrections ont les portent aussi sur la master. Si on fait des evolutions on les fait sur le master. Quand on a fait des corrections sur la "beta-dev" et qu on pense qu'ils sont assez bons on re-publie une "beta". Quand nous n'avons plus de retour négatif sur la "beta" on la passe en "stable".

Ca te va ?

Ca me semble carré oui

tcharp38 commented 4 years ago

Sur le market ils ont acces soit à la stable soit a la beta si ils sont déclarés beta tester chez jeedom. Je ne suis pas sure de la manip mais il doit suffir de choir la version dans le market lors de l installation. (Il faut verifier)

J'avais vu ca mais j avoue que je ne suis pas allé au bout de la manip. J'ai pas vu comment choisir une version pour un plugin particulier.

KiwiHC16 commented 4 years ago

Je viens de créer la beta-dev J ai aussi mis a jour le fichier configuration.php qui permet de voir dans le plugin la version sur laquelle nous sommes https://github.com/KiwiHC16/Abeille/blob/beta-dev/plugin_info/configuration.php#L53

KiwiHC16 commented 4 years ago

Connais tu un moyen d'avoir dans un fichier texte, le commit en cours ? En gros tu fais un commit, ou tu defini un tag et l info est aussi mise dans un fichier txt. Sans avoir à le mettre manuellement ? Je n ai jamais trouvé la solution. En svn c'était possible.

tcharp38 commented 4 years ago

Il y a un cote GIT, un systeme de "hook" si je me souviens bien. Ca permet d'activer des scripts pour des etapes particulieres. Par ex, il doit y avoir possibilite de mettre un script en "pre-commit". Celui ci pourrait mettre à jour un fichier "version". Ou plutot ca devrait etre fait juste au push (pre-push).

Mais je ne suis pas sur d'avoir tout compris. Tu as un exemple concret ?

tcharp38 commented 4 years ago

Tu veux un fichier texte pour mettre à jour "Version Abeille" de la page config ou pour autre chose ? Avec les hooks on doit pouvoir faire qqch mais il faut etre clair sur ce qu'on cherche à faire. J'imagine que l'idée est d'automatiser la version qui s'affiche dans la page config mais peut etre que je me trompe.

KiwiHC16 commented 4 years ago

Exact. Avoir dans la page config le numero du commit, la branche et la date par exemple

tcharp38 commented 4 years ago

Premier push dans ce sens.

tcharp38 commented 4 years ago

Kiwi Peux tu me dire comment tu procedes pour delivrer une version officielle à Jeedom ? Est ce qu'ils se servent seuls et prennent le dernier tag sur la branche stable par ex ? Merci

KiwiHC16 commented 4 years ago

Ils prennent durant la nuit la branche stable et la branche bêta.

tcharp38 commented 4 years ago

ok donc qu'il y ait un tag ou pas. Ce qui fait qu'il peut y avoir une diff avec les releases tagguées que tu fais. Un simple commit sur stable se retrouve sur le market. C'est bien ca ?

KiwiHC16 commented 4 years ago

Oui le tag n'est pas utilisé par le market jeedom.

Je viens de regenerer la beta-dev a partir du master d aujourd'hui. Je vais la mettre sur mon systeme et si ok faire proposer une beta pour les utilisateurs.

tcharp38 commented 4 years ago

Merci pour les infos. Une autre question: comment mets tu à jour la branche stable ? Tu pousses vers cette branche ou tu ne fais que merger des pull-requests venant d'une autre branche ? En fonction, la mise à jour de la version d'Abeille est differente.

KiwiHC16 commented 4 years ago

Je supprime la branche stable existante. Je crée depuis gihub une branche stable depuis une autre branche. Le plus souvent la stable est une branche (copie) de la beta.

tcharp38 commented 4 years ago

Ha bon ?! Tu supprimes chaque fois l'ancienne branche stable ? Du coup tu fais quoi ? Un truc comme "git checkout -b stable beta" ? Ce qui voudrait dire qu'apres tu dois pousser ta stable vers GitHub. C'est ca ?

KiwiHC16 commented 4 years ago

Je fais tout dans github ce qui est plus conviviale que la ligne de commande. Aujourd'hui je viens de faire:

supression de la beta et de la beta-dev (https://github.com/KiwiHC16/Abeille/branches poubelle rouge)
j'ai selectionné le master ( https://github.com/KiwiHC16/Abeille )
Tu saisies le nom de branche que tu veux par exemple toto Comme elle n'existe pas, il te propose de le créer.
C est ce que j ai fait pour avoir la beta
ensuite dans le beta je change le fichier Abeille/plugin_info/AbeilleVersion.inc

Aujourd'hui, je viens de tester la beta-dev. Comme tout semble ok, j'ai créé la beta en faisant une branche de la beta-dev (donc c'est la meme sauf le fichier Abeille/plugin_info/AbeilleVersion.inc)

Donc si on fait des corrections sur le beta-dev, on ne casse pas la beta dispo pour les utilisateurs. Si on est ok pour pubier une nouvelle beta on delete beta, branche beta-dev en beta et le jour d apres les utilisateurs ont la beta dans le market jeedom.

Si on a le go pour la beta, on delete la stable, on branche la beta en stable et le lendemain les utilisateurs ont une stable sur le market.

Donc demain les utilsateurs auront une beta demain mais j ai trouvé le cas #1214 qu il faudrait qu on corrige pour la beta suivante avant de publier une stable.

KiwiHC16 commented 4 years ago

J ai aussi mis un peu d ordre dans https://github.com/KiwiHC16/Abeille/projects pour essayer de definir les prochaines actions.

tcharp38 commented 4 years ago

Bon dans ce cas ce que j'étais en train de mettre en place pour la mise à jour de la version automatiquement, ne fonctionnera pas pour la stable vu qu'a ce se stade tu ne manipules que sous Github. Je vais finaliser le truc en cours quand meme. Ca sera valide pour les autres branches. Et je reprendrai ensuite pour voir ce qui est proposé coté GitHub.

KiwiHC16 commented 4 years ago

Si tu as un "script" en ligne de commande ca peut être mieux car a chaque fois j'ai tendance a oublier ce que j ai fait avant et il y a toujours des variations. La theorie et la pratique.

tcharp38 commented 4 years ago

Bon j'ai une solution partielle mais deja bien pratique. Un "hook" git, qui met à jour la version (, ) à chaque commit.

Ca donne ça pour l'instant

Je vois encore 2 autres "manquees" au moins

lorsque tu recuperes d'une autre branche.. il faut changer la version (au moins le nom de branche)
je ne sais pas inserer le num de commit car le script est justement appelé pendant un commit, donc le SH1 n'est pas dispo

Je te livre déja ça ?

KiwiHC16 commented 4 years ago

Oui intéressant A tester.

Le 14 août 2020 à 17:46, tcharp38 notifications@github.com a écrit :

Bon j'ai une solution partielle mais deja bien pratique. Un "hook" git, qui met à jour la version (, ) à chaque commit.

Ca donne ça pour l'instant

Je vois encore 2 autres "manquees" au moins

lorsque tu recuperes d'une autre branche.. il faut changer la version (au moins le nom de branche) je ne sais pas inserer le num de commit car le script est justement appelé pendant un commit, donc le SH1 n'est pas dispo Je te livre déja ça ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

KiwiHC16 commented 4 years ago

Je viens de mettre une stable a diposition (dispo demain sur market) qui est basée sur la master du jour. C est la beta d il y a un mois plus qq corrections de dernieres minutes. J ai aligné la beta et la beta-dev sur cette stable.

tcharp38 commented 4 years ago

Oui intéressant A tester. … Le 14 août 2020 à 17:46, tcharp38 @.***> a écrit : Bon j'ai une solution partielle mais deja bien pratique. Un "hook" git, qui met à jour la version (, ) à chaque commit. Ca donne ça pour l'instant Je vois encore 2 autres "manquees" au moins lorsque tu recuperes d'une autre branche.. il faut changer la version (au moins le nom de branche) je ne sais pas inserer le num de commit car le script est justement appelé pendant un commit, donc le SH1 n'est pas dispo Je te livre déja ça ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

Livré (#1248)

piwii commented 3 years ago

Je pense aussi que l'on peut regarder du coté de github action afin d'automatiser / améliorer les process de release et de merge

KiwiHC16 commented 3 years ago

Je fais un beta-dev pour figer le soft et preparer une beta puis une stable.

KiwiHC16 commented 3 years ago

Je clos car nous avons slack maintenant.

KiwiHC16 / Abeille

Amélioration du processus d'approbation d'une pre-release #1186