Comment développer le discours dans une équipe ?

Bonjour à tous. J’ai rencontré un problème lors du développement de Discourse.

D’habitude, je clone des fichiers depuis Git,
je fais des modifications,
puis j’effectue un commit sur Git.

Mon coéquipier fait un git pull
et récupère toutes mes modifications.

Comment puis-je mettre en place quelque chose de similaire dans Discourse ?
Comment puis-je apporter des modifications afin que d’autres personnes puissent les installer chez eux ?

Que vous développiez un thème ou un plugin Discourse, l’un comme l’autre peut tout à fait être hébergé dans un dépôt Git.

3 « J'aime »

Merci pour votre réponse. Oui, vous avez raison concernant le sujet. Qu’en est-il de la synchronisation des composants et des paramètres ?

Le code de votre plugin peut définir des migrations et/ou des données de semis si nécessaire. Il peut également s’assurer que les paramètres du site ont la valeur appropriée.

2 « J'aime »

Je souhaite cloner entièrement mon installation.

Vous pouvez effectuer une sauvegarde et restaurer là où nécessaire.

1 « J'aime »

J’ai essayé. Je rencontre une erreur lors de la restauration.


La copie n’apparaît pas dans la liste, même après 30 minutes.

J’aime utiliser S3 pour les sauvegardes, ce qui permet à tous les sites de partager le même jeu de sauvegarde. Ainsi, lorsque vous effectuez une sauvegarde en production, vous pouvez immédiatement la restaurer sur vos environnements de staging pour vérifier qu’elle fonctionne avec les données actuelles.

1 « J'aime »

Qu’est-ce que S3 ? Je souhaiterais l’utiliser.

1 « J'aime »

Utilisation du stockage objet pour les téléversements (S3 et clones) et Configuration des téléversements de fichiers et d’images vers S3 sont les points de départ. Pour les sauvegardes uniquement, c’est assez simple.

Backblaze et Wasabi sont économiques. Storj.io propose également un produit que j’ai utilisé pour les sauvegardes.

Ce n’est que mon avis, et je ne veux pas minimiser les commentaires utiles ici concernant les sauvegardes, mais en prenant un peu de recul : je ne suis vraiment pas sûr que la « synchronisation » des installations de Discourse vaille beaucoup d’efforts.

Sauf si vous avez l’intention de contribuer au cœur de Discourse via des pull requests, le développement de plugins ou de composants de thème (TC) est la voie à suivre et offre la solution la plus robuste et efficace pour la personnalisation.

L’essentiel avec le développement de plugins et de composants de thème, c’est qu’ils seront déployés sur plusieurs instances de Discourse, sur lesquelles vous n’aurez de toute façon peut-être aucun contrôle.

Avoir une instance Discourse locale légèrement unique pour le développement est donc tout à fait acceptable (dans la mesure du raisonnable).

Le flux de travail clé devrait consister à maintenir le plugin ou le TC à jour dans un dépôt partagé, très probablement sur GitHub.

3 « J'aime »

Je suis tout à fait d’accord. J’ai plusieurs clients dont les personnalisations ne peuvent pas être vérifiées (ou sont plus facilement vérifiées) par rapport à leurs données réelles, ils aiment donc vraiment voir le site avec les données actuelles.

1 « J'aime »

Oui, c’est juste. Cela dépend de ce que vous essayez de faire, de la clientèle visée (un seul destinataire ou plusieurs clients ?) et du niveau de contrôle que vous souhaitez avoir.

1 « J'aime »

Merci à tous pour vos conseils. Très probablement, je vais procéder à une PR vers le cœur de Discourse. Par conséquent, j’ai besoin de la possibilité de télécharger l’assembly dans Git, puis depuis Git vers le serveur.

Si vous faites une PR vers le cœur de Discourse, la configuration exacte de votre installation locale n’est pas critique (assurez-vous simplement d’être sur la dernière version), car la contribution au code est un processus très contrôlé de toute façon, surtout avec les cas de test. Ainsi, de légères variations dans les paramètres ou le contenu sont peu susceptibles de poser problème.

Normalement, si vous travaillez sur des contributions conjointes, vous ne forkerez pas vers le dépôt de votre organisation et travaillerez dessus avant de faire une PR ?

2 « J'aime »

Non, je ne travaille pas sur des contributions conjointes. Je travaille pour un usage personnel.

Je n’ai pas voulu le dire de cette manière.
Comment puis-je installer Discourse à partir d’un fork Git ?
Je vais apporter des modifications au cœur de Discourse et les ajouter à mon dépôt Git.

Alors, je suis perplexe : pourquoi devez-vous synchroniser vos installations ?

Il vous suffit de cloner votre fork via Git.

Normalement, vous n’utiliseriez pas Docker pour le développement, mais si c’est le cas, vous pouvez accéder à votre conteneur et vérifier votre fork.

1 « J'aime »

Par exemple.

Maintenant, j’ai configuré Discourse.
Ensuite, lorsque tout est prêt, je mets à jour ma version.

Je reprends ensuite le développement. Je modifie certaines paramètres dans le panneau de contrôle. Il peut y en avoir beaucoup.
Lorsque je veux mettre à jour ma version, je devrai également mettre à jour les paramètres.

Dans ce cas, je devrai configurer manuellement les paramètres.

Les paramètres sont persistants et vous travaillez seul, alors pourquoi se soucier de la sauvegarde ou de la synchronisation ?

(De plus, le titre du sujet est alors confus : pourquoi « dans une équipe » ?)

Lorsque vous clonez ou effectuez un checkout, vous n’effacez pas la base de données (où les paramètres sont stockés).

Vous contrôlez le moment d’exécuter les migrations (si elles existent). Sinon, la base de données devrait rester stable.

1 « J'aime »