Bonjour à tous.
J’ai installé Discourse sur mon ordinateur local via http://localhost:4200/
en suivant ce guide. Ici, je développe Discourse, des thèmes et des plugins.
J’ai également installé Discourse sur une machine virtuelle en utilisant Docker, conformément à ce guide.
Ces deux installations fonctionnent parfaitement.
Je ne comprends pas ce qu’est Docker et pourquoi les fichiers sur la machine virtuelle diffèrent de ceux sur l’ordinateur local.
Que se passera-t-il si vous arrêtez Docker sur la machine virtuelle avec la commande d/shutdown_dev ?
Comment puis-je synchroniser ces deux installations à l’aide de Git ?
Puis-je installer Docker sur une machine locale, et dans quel but ?
Travaillez sur votre base de code (à l’intérieur de /discourse).
Compilez votre base de code dans un conteneur Docker.
Déployez ce conteneur Docker sur votre serveur de production.
Un cas d’usage pour exécuter Docker localement consiste à tester votre nouveau conteneur Docker compilé avant de le déployer sur votre serveur de production.
La présence ou l’absence de Docker est largement indifférente pour presque tous les développements de plugins et de composants de thèmes. C’est une préoccupation distincte. Je ne fais pas tourner d’instance Docker en développement.
Lors du développement d’extensions pour Discourse, vous ne devriez pas avoir à vous soucier excessivement de la version exacte ou de la configuration de votre instance de développement par rapport à celle de production, car vous n’avez généralement aucun contrôle sur la plupart des instances où votre plugin finira par être déployé, surtout s’il est open source. L’élément le plus important est de suivre les bonnes pratiques afin de rendre votre extension plus résistante aux changements au sein du noyau de Discourse. Même si vous ne développez que pour votre propre instance Discourse, vous n’avez toujours aucun contrôle sur les modifications du noyau, donc la même approche s’applique.
Des versions légèrement différentes ne devraient généralement pas entraîner l’échec de votre plugin ou de votre composant de thème. Cela peut arriver, mais ce n’est pas systématique. Mes plugins et mes composants de thème peuvent rester plusieurs mois sans nécessiter de modifications, même en travaillant sur des commits du noyau espacés de plusieurs mois.
Je mets généralement à jour mon instance de développement vers la dernière version de master lorsque je travaille sur des modifications de plugins (corrections ou améliorations), afin de prendre en compte tout changement breaking. Cela se fait simplement par un git pull, suivi de bundle install et db:migrate.
Les instances de production doivent simplement être mises à jour via l’interface web ou la commande de reconstruction en ligne de commande.
Mon conseil serait de publier un plugin en public, d’attirer des utilisateurs et d’apprendre les aléas de la route grâce à l’expérience. Ne procrastinez pas trop : faites-le ! Et ne vous inquiétez pas de faire des erreurs, car elles vous aident à apprendre.
Merci beaucoup pour votre réponse.
Je vais essayer de développer.
C’est-à-dire que je peux supprimer « git clone /github…docker » du fichier app.yaml ?
Et le reconstruire ?
Je poserais ce type de questions sur le sujet dédié au développement Docker. Pour l’instant, je ne modifierais pas les scripts par défaut utilisés pour gérer le développement Docker, sauf si vous avez une très bonne raison ; ils sont probablement là pour vous aider.
