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
Euh bonjour, je me présente, je m’appelle… non on a déjà fait les présentations
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
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.
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.
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
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.
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
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.
Pour rebondir sur les process de gros projets open-source équivalent, voilà comment procède Home Assistant:
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”.
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)
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 !
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 ?
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
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!
