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 ?
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.
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.
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.
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.
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.
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 ?
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.
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.