Créer un dépôt Github pour gérer les issues infra

Salut !

Je vois trop souvent des issues sur Github qui ne sont pas liées au développement de ZdS, mais qui sont liées à sa mise en production ou à des réglages du serveurs.

Je vous propose donc de créer un repository vide (ou avec les différents codes shell/script/config du serveur) afin de libérer le dépôt qui contient ZdS-dev des issues qui ne le concerne pas.

En gros, n'importe qui arrivant sur ZdS-dev doit pouvoir résoudre n'importe quelle issue s'il en a les compétences. Or actuellement il y a pas mal d'issues qui nécessitent des droits / ne concernent qu'une petite partie de personnes.

Pour faire ça il faut donc que nohar s'en charge.

Je propose que nous discutions d'abord avant de décider de solutions ; un peu d'ordre, que diable !

Si on résume :

Problèmes

1. On a des tâches qui sont clairement liées à l'infrastructure et son administration. Néanmoins, il faut pouvoir les suivre, les prioriser, les affecter, etc. ; les gérer en somme.
2. On a tout une partie de l'application qui n'est pas sur Git. C'est principalement des fichiers de conf. On me dira avec raison ce n'est que de la conf ; sauf que cette conf peut être complexe, chiante à faire, chiante à reproduire. Aujourd'hui "perdre la conf", c'est plusieurs heures de travail pour tout remettre d'aplomb. Plus les problèmes d'incohérence entre prod et préprod.
   Pour moi cette conf devrait être gitisée, sauf les parties vraiment sensibles (mots de passe, autre chose ?). Outre l'aide et une forme de sauvegarde, ça donne des exemples pour qui voudrait installer un fork / une version locale.
3. Certaines issues (comme la #1337) semblaient être ouverte à tous, mais en fait il faut, en l'état, un accès serveur pour la résoudre. D'autres, comme la #1338, semblaient nécessiter un accès serveur alors que ce n'est sans doute pas le cas. Quelle que soit la solution retenue, on doit pouvoir trancher ces cas.

Solutions envisageables

Je pars du principe, qui reste discutable, qu'il faut versionner un maximum de choses et donc qu'on va y rajouter des conf serveur.

Un dépôt Github et un gestionnaire de ticket / d'incidents / appelez-le comme vous voulez

• Le dépôt ne contient que le code et sa documentation
• Plus d'issues dans Github, elles sont toutes gérées proprement dans le gestionnaire
• Nécessite plus d'administration
• Évite de lier au code des issues qui n'y sont pas directement liées

Deux dépôts Github : le code / la config et le BO

• Permet de bien séparer les issues qui sont gérables par tout le monde des issues nécessitant un accès spécial…
• … mais comment gérer les issues qui changent de camp ? (n'est pas un problème si Github permet de déplacer des issues entre des projets)
• Si bug est trouvé, où le déclarer ? (on a pas toujours de règle simple qui permette de décider si un bug va dans telle ou telle catégorie avant d'avoir commencé à l'étudier).
• Pose des problèmes de cohérences de droits entre les différents dépôts
• Si le 2ème dépôt contient des données (config etc), ça complexifie encore plus le processus de mise en production (et en admettant qu'il ne contienne que des trucs inutiles en dev) : il faut les maintenir synchronisés.

Un seul dépôt Github, un dossier pour la conf, des tags pour différencier les issues nécessitant des droits

• Tout est centralisé : aucun risque de désynchronisation d'aucune sorte
• Les tags permettent de savoir rapidement si l'utilisateur lambda peut traiter l'issue ou non. Les personne avec des droits spéciaux devraient prendre en priorité les issues tagguées
• Très facile de gérer des issues incertaines (simple tag à changer dans le gestionnaire)
• Le Github gère donc l'application et non plus seulement le code
• Moins facile à comprendre pour l'utilisateur débutant

Pour l'instant, la solution 1 me paraît trop compliquée. Entre la 2 et la 3, je ne sais pas encore. La 3 risque d'être bordélique, mais offre de gros avantages sur la 2.

Le Github gère donc l'application et non plus seulement le code

Rien que pour ça, non. Le but de ma proposition c'est de bien distinguer le code du projet (ce qui intéresse les développeurs) de ce qui concerne la mise en production de ce code.

De la même façon qu'on a séparé la gestion du Markdown et de Git, il me paraît logique de séparer l'admin sys. du dev à proprement parler.

Du coup, je suis très franchement pour la 2 : deux dépôts.

mais comment gérer les issues qui changent de camp ?

Suffit de fermer, et de rouvrir en faisant un lien vers l'ancienne issue.

Si bug est trouvé, où le déclarer ?

Sur zds-dev, si c'est le serveur en lui-même qui est en cause, ceux qui le peuvent se chargeront de le déplacer (fermer et créer une nouvelle issue donc).

Pose des problèmes de cohérences de droits entre les différents dépôts

Je ne comprends pas ce point. Sur Github tu peux faire des groupes et donc tu peux dire que ce même groupe a des droits sur plusieurs repos, tout comme on peut pick que certaines personnes (la preuve avec les repo Git et Markdown). Pour moi ce point n'est pas un problème.

Si le 2ème dépôt contient des données (config etc), ça complexifie encore plus le processus de mise en production (et en admettant qu'il ne contienne que des trucs inutiles en dev) : il faut les maintenir synchronisés.

Les deux dépôts, s'ils sont bien organisés, ne seront pas dépendants l'un de l'autre. Y mettre la configuration est un choix qui me semble judicieux, mais qui ne doit pas devenir contraignant non plus.

Il y a aussi une 4ème solution qui est appliquée dans de nombreux projets:

1. Tout dans le même repo
2. Mais avec un subtree split en lecture seule ne contenant pas le code spécifique au déploiement ou autre (après je sais pas trop comment ils les maintiennent à jour, peut être manuellement ou avec un webhook. Je sais pas)

Je vais remonter ce sujet en ajoutant un argument de poids à cette création :

dans ce repo, il pourra être mis les différents fichiers nécessaires à notre CI et qui sont actuellement hébergés sur les Dropbox de différents développeurs (il y a LaTeX, des polices, et certainement d'autres trucs).

"CI" ?

Ah je croyais avoir répondu ici (mais il faut croire que non).

Moi je pense qu'il faudrait éviter d'utiliser Github pour faire des trucs pour lequels il n'a pas été spécialement conçu. Créer un dépôt uniquement pour faire du ticketing dessus, je trouve ça un peu overkill.

Je pense que c'est le moment de faire une demande pour du Jira gratuit. Ça évite de pourrir les issues Github avec issues qui ne sont pas traitables par les devs.

Pour nos ressources, idem trouver un hébergeur de ressources fiable (Google drive ?) appartenant a l'asso et qui nous permet d'héberger ce qu'on veut dessus.

C'était mes 2 cents.

"CI" = service d'intégration continue, ici Travis ou Shippable, etc. C'est vrai que c'était pas clair (c'est peut-être même un acronyme qui n'est pas bon).

C'est vrai que passer sur un service d'hébergement dédié à ZdS c'est pas con non plus, mais du coup c'est pas open… c'est pour ça que je suggérais un repo : tout le monde peut mettre à jour LaTeX ou la font ou je ne sais quoi via une PR, alors qu'un compte fermé type Google Drive, Dropbox, etc. c'est pas trop dans cet esprit là.

Du coup, si on combine le tout : on a un repo qui sert à la fois à mettre des ressources utiles de façon globale ou à l'admin sys (et donc potentiellement re-prenable par quiconque souhaite lancer un site similaire) on y mettrait par exemple le script de déploiement dont on se moque sur le projet en lui même, ainsi que les différents fichiers de configurations qui ne sont que sur la prod et sont un mystère pour l'ensemble des développeurs hormis firm1 et peut-être SpaceFox, même si on a déjà pu voir des incompréhensions et autres.

Jira, je dois avouer ne pas connaître mais pourquoi pas. Après, est-ce que ça apporte vraiment quelque chose ? N'est-ce pas overkill comme outil par rapport à nos besoin ? Ne le connaissant pas, je ne peux pas juger. Tout ce que je vois comme avantage c'est qu'on a sans doute la possibilité des droits en lecture et donc parler de problèmes critiques sans que tout le monde ne le voit.