Process de dev une fois la v4 sortie (git-flow, branch, tag)

Salut à tous !

On en parlait avec @AlexTrovato et @VonOx, étant donné que la release est bientôt il va falloir changer notre flow de développement afin introduire plus de testing avant chaque release.

Avant de débattre de ce sujet, juste une contrainte que l’on a :

Les builds release d’image Docker pour les plateformes ARM sont extrêmement lent (environ 1h), et on ne peut pas nécessairement en faire en illimité. Je ne connais pas les limites de CircleCI, mais quelques builds par semaine/mois ok, plusieurs builds par jour c’est non.

On ne peut donc pas se dire qu’on build systématique une branche (master? dev?), il faut que ce soit une action manuelle pour dire “on a envie de faire un build DEV pour que tout le monde puisse tester cette pre-release”.

@AlexTrovato Je te laisse la parole si tu as des propositions :slight_smile:

Euh bonjour, je me présente, je m’appelle… non on a déjà fait les présentations :stuck_out_tongue:

Je pense en effet qu’il peut être intéressant d’avoir une branche “testing” ou “pre-release” qui continue en quelques sortes le mode actuel, une version candidate qui doit être testé au max (on sait bien qu’il est difficile de tout tester, surtout quand on se branche à du matériel…).

Bref, on devrait rester dans un mode de génération d’image par nouveau service, avec le maximum de test, pour corriger les retours sans se mélanger les pinceaux.

Je dis “par nouveau service” mais si on trouve assez de testeurs, on pourrait aller jusqu’à 3 services ; mais je pense également que c’est important de limiter le périmètre.

Ce qui signifie qu’on serait à maximum une image par jour (car il faut également du temps pour traiter les retours).

Soit :

  • attendre l’intégration de N nouvelles features (services ou core)
  • générer une image avec un périmètre limité à ces N features (+ autres bugs si bugs)

On peut se rapprocher d’un process Agile + Git Flow :

  • fournir une quantité de travail pour une “durée / périmètre” limité (avec une liste de tâches)
  • intégrer ces nouveautés sur une branche dev depuis les PR
  • faire valider (selon dispo) les nouveautés (listées) une par une
  • quand tout est ok, on rapatrie tout sur master
  • une nouvelle version vient de naître

La réussite vient avec une bonne organisation.

Je parle je parle, mais vos avis m’intéressent.

Salut à vous 2,
Je ne comprends pas totalement ce que vous dites, et c’est normal, je n’ai pas les connaissances en développement informatique.
Par contre, pourriez-vous précisez ce que vous entendez par :

Avez-vous besoin de testeurs pour certaines fonctions, certains matériels avant de les incorporer définitivement à Gladys ?
Si oui, il serait peut-être intéressant de faire une liste des utilisateurs disponibles et du matériel qu’ils possèdent pour pouvoir tester.

1 Like

Cette liste ne rendra pas les gens disponibles, mais c’est une plutôt bonne idée de savoir à qui on peut s’adresser.

Oui j’aime bien l’idée de la liste du matériel.
Je parts dans l’idée que si tu renseignes ton matériel, c’est que tu veux qui’il soit intégré à Gladys et pour cela il faut le tester.

Je suis pour.

Pour le dialogue entre Alex et Pierre-Gilles, moi non plus je ne comprend pas tout. Mais c’est intéressant de lire ce sujet car la plupart du temps ces conversations sont privées et les non développeurs ne peuvent pas participer en donnant leur point de vue.

Ça concerne également de la supervision de projet, donc les chefs de projet ou autres chefs d’équipe peuvent contribuer au niveau organisationnel.

Ce serait effectivement bien d’avoir une branche de tests pour valider les nouvelles fonctionnalités/évolutions avant de les intégrer à la branche principale.
Mais faut-il les détailler par service, je ne pense pas car sinon, on ne testera pas les effets de bord potentiels sur les autres services en développement.

Il serait aussi bien d’avoir une branche pour corriger plus rapidement les bugs qu’on détectera sur la Release => Git flow :+1:

Je suis aussi, pour définir des listes de tâches liées à des PRs, à intégrer par jalon mais je me rends compte qu’il est difficile d’être agile quand on y travaille que le soir…
si on avait un moyen de recaler de façon souple quelles PR seront intégrées à la prochaine Release, en fonction de l’évolution de notre emploi du temps, ce serait top.

Avec cette RC, @pierre-gilles va trouver des investisseurs GAFAM et nous embaucher !

Cool ! :+1:

Sinon, j’ai trouvé un outil sympa de collecte de bugs qui gère node. Il y a un grand article dessus sur le Hors-série Linux mag qui vient de sortir :

Vous connaissez ?

Dans l’idée je suis plutôt pour. Après ce qui me fait peur avec cette approche, c’est que cette branche devienne une branche “fourre tout”, et qu’on arrive à un stade ou par exemple on à 2 features qui sont prête à être merge, et qu’elle soit bloquée par une feature “pourrie” qui empêche le merge.

Par exemple: imagine tu bosses sur la PR Sonoff HTTP, et quelqu’un bosse sur la PR Zigbee2mqtt.

Si ont met les deux en “pre-release”, mais qu’une des deux apporte un bug critique qui met du temps à être fixé, bah la PR Sonoff est bloquée (et tout le flow développement avec). Là ou dans notre approche actuelle, on fonctionne “par branche individuelle par feature”.

Je serais intéressé de voir comment des gros projets open-source proche de notre use-case font (je pense à Home Assistant par exemple, ils ont beaucoup de contributeurs)

Yes, j’utilise ça sur pas mal de projets. En revanche c’est adapté à des projets cloud, mais pas des projets open-source self-hosted.

1/ Ca envoie toute tes données à Sentry, c’est à l’inverse de la philosophie du projet
2/ Sans parler du pricing/des limitations. C’est pas du tout fait pour notre use case :slight_smile:

Si tu peux on peut parler de la partie error tracking/télémétrie dans un autre sujet. C’est un sujet auquel je ne suis pas opposé, mais qu’il faut faire bien et en prenant beaucoup de précautions pour respecter la vie privée des utilisateurs de Gladys Assistant.

@pierre-gilles j’avoue que la branche multi-features est risquée. On peut alors faire :

  • une feature / service est prête
  • on rassure d’être aligné sur la branche “pre-release”
  • on génère une image
  • on “garantie” que tout fonctionne
  • on merge sur la branche “pre-release”

2ème feature on recommence

Ce sera un peu plus long, mais un peu plus sur.
Le point le plus gênant que je vois (au 1er coup d’oeil) est le dev en parallèle :

  • feature 1 et 2 sont prêtes en même temps
  • on les test
  • les 2 sont OK
  • mais le merge de l’un peut nuire au fonctionnement de l’autre
  • donc il faut reproduire la phase de test de “2” après que “1” soit mergée
    (petite perte de temps, mais gain de qualité)

Ceci dit, vu que les devs ne sont pas à temps plein, on peut considérer que ce soit un cas à la marge.

Pour rebondir sur les process de gros projets open-source équivalent, voilà comment procède Home Assistant:

  1. Une branche “dev” qui est l’équivalent de notre branche master. Toutes les PRs sont mergées dans cette branche, et une fois par semaine, une image “beta” est buildée. J’imagine que certains power user font tourner Home-Assistant beta au lieu de la version de “prod”.

  2. Une branche master, qui est la version de prod. Toutes les 2 semaines, ils rebase la branche “master” sur la branche dev. (master devient le contenu dev qui est normalement en phase de test depuis 1 semaine via le tag beta)

Screenshot 2020-11-05 at 10.41.26

Je trouve ça pas mal, après ma question c’est: qu’est ce qui se passe quand il y a un problème majeure sur leur branche dev?

Aussi, au final je vois peu la différence avec notre flow actuel.

On merge les PR dans master (qui est l’équivalent de leur dev). Ensuite il nous manque juste une tâche CI manuelle pour builder master quand on a besoin (vers un tag Docker dev), et quand on est prêt on fait un tag versionnée pour que ça passe en prod !

Oui en gros c’est pareil, c’est surtout la phase de test et d’approval qui doit être “rigoureuse”.

1 Like

Exactement, une PR ne doit être mergée que si vraiment ça marche nickel.

Tiens d’ailleurs, ça me fait penser ça serait cool que chaque PR fasse au moins un build amd64 dans les tests automatique, pour être sur que l’image docker marche toujours nickel. (je dis amd64 car c’est des builds rapides, si on doit tester des builds ARM ça fait bcp). Actuellement on est un peu à l’aveugle quand on merge sur la partie Docker. @VonOx t’en pense quoi ?

Je suis d’accord mais le gros point bloquant sur les PR c’est la gestion des secrets.

Pour contourner on pourrait construire un ci dédié ( Travis par exemple) ça permettrai d’être plus fin sur qui voit les logs de build.

C’est juste une idée à chaud.

Pour le build amd64 dans les PR je parlais juste d’un build sans push ! Donc pas de problèmes de secret :slight_smile:

On est quasi obligé de faire un login avant de build, il y’a un rate limit meme sur le pull maintenant

Non au final pas sur CircleCI pour l’instant !

Ils ont communiqué sur la question:

CircleCI has partnered with Docker to ensure that our users can continue to access Docker Hub without rate limits. On November 1st, with few exceptions, you should not be impacted by any rate limits when pulling images from Docker Hub through CircleCI.

However, these rate limits may go into effect for CircleCI users in the future. That’s why we’re encouraging you and your team to add Docker Hub authentication to your CircleCI configuration and consider upgrading your Docker Hub plan, as appropriate, to prevent any impact from rate limits in the future.

C’est sûr c’est pas une solution long terme mais pour l’instant ça fait le taff :slight_smile:

Après, pour moi c’est évident qu’ils vont mettre en place une solution pour les projets open-source pour cette histoire de rate-limite parce que pour le coup on sera vraiment pas les seules à avoir ce problème.

Pour l’histoire des builds + push dans les PR je suis 100% d’accord qu’on a toujours le problème des secrets, mais build amd64 uniquement je pense que ça passe!

Ah j’avais pas vu ça ! Du coup oui aucun problème. On peut même exploiter github action sur les PR.

Je résume avant de commencer la PR:

  • @pierre-gilles tu créé une branche dev
  • on build une image docker beta sur cette branche ( on peut utiliser Github Actions pour préserver le quota )
  • On rajoute un build amd64 sur les PR sans push et sans secrets.

PS: S’il faut build des images sur des PR je peux ( avec un Travis par exemple )