Coding practise: Releases régulières, freeze du code, déploiement
Est-ce que cela vaut le coup de définir un peu mieux notre politique de release, sans tomber dans une usine à gaz ?
Plusieurs projets open-source ont pour politique de faire les grosses modifs juste après chaque release … De notre côté, si on fait des releases en début de mois, on pourrait décider d'arriver vers le 15/20 du mois à quelque chose de « stable » au niveau des fonctionnalités d'analyse, et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée.
Et d’ailleurs, est-ce que cela sert de faire tant de releases ? On peut dire oui… si nous en sommes nos premiers utilisateurs : ce serait bien plus stable (et maintenable à long terme) si on reste 1 mois sur la même version sur le serveur. On en est à 7 jours aujourd'hui, on n'a jamais tenu aussi longtemps !
Ce mois de stabilité pourrait devenir une règle, quitte à avoir une config « vidjil-dev » qui lance un autre exécutable Vidjil (et on dirait explicitement aux utilisateurs que c'est une config de test).
« et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée. » oui, si c'est associé avec la config vidjil-dev (et qu'on l'utilise vraiment) pour qu'on se rende compte des problèmes dans la version de vidjil.
vidjil-dev : pas si évident. Il faudrait que ce soit considéré comme un logiciel à part pour le serveur (pour l'instant on a un chemin vers l'exécutable vidjil).
oui, tout à fait. Donc une entrée de plus dans defs.py.
Un jour, nous aurons miTCR, TCRKlass... on doit pouvoir être générique, on commence soft en changeant juste l'exécutable :)
Plutôt que d'avoir une autre constante, il vaut mieux un dico des logiciels dispos et de leurs chemins…
oui (mais à terme, cela demandera aussi un autre controlleur pour miTCR, pas besoin pour l'instant)
« et ne pas publier de release avant d’avoir 1-2 semaines d’habitude sur cette version plus ou moins freezée. » Je suis toujours d'accord avec ça mais on ne le fait pas. Avoir une branche release_candidate qui chaque mois est remise à jour depuis dev. Seules les corrections de bug sont autorisées sur cette branche et la config vidjil-dev sur le serveur devrait être un vidjil compilé sur cette branche-là. Quand on veut faire une release, on la merge depuis master.
ok pour le principe. Sur release-candidate, uniquement des corrections de bug (ce qui veut dire avec test obligé)... mais aussi documentation et tests éventuellement.
Donc trois branches : dev / master / release-candidate ?
Ou peut-on faire avec deux branches seulement : master / release-candidate (on release directement depuis release-candidate) + dev s'il y a des choses qui ne sont pas mûrs pour aller dans master.
J'avais ça en tête évidemment : http://nvie.com/posts/a-successful-git-branching-model/
Ça me fait bizarre de penser que les releases ne seraient pas sur master (au moment où on fait la release, il pourrait s'être passé plein de choses sur master qui ne sont pas dans la release, plus les corrections de bugs qui sont communes).
Oui, exactement pour le modèle. Cela va changer les habitudes de tous (branche principale = dev).
Planning accéléré pour ce coup-ci : ce soir, release-candidate est branché.
release-candidate est branché... il faut tester depuis Jenkins. Est-ce possible sans dupliquer des jobs ?
@nobody