installiert, und zwar gemäß diesem Leitfaden. Hier entwickle ich Discourse, Themes und Plugins.
Außerdem habe ich eine Discourse-Installation auf einer virtuellen Maschine mit Docker, ebenfalls gemäß diesem Leitfaden.
Diese Installationen funktionieren hervorragend.
Ich verstehe nicht, was Docker ist und warum die Dateien auf der virtuellen Maschine anders sind als die auf dem lokalen Computer.
Was passiert, wenn man Docker auf einer virtuellen Maschine mit dem Befehl d/shutdown_dev stoppt?
Wie kann ich diese beiden Installationen mit Git synchronisieren?
Kann ich Docker auch auf einem lokalen Computer installieren, und wofür wäre das?
Lass mich versuchen, den Ablauf zu veranschaulichen:
Arbeite an deiner Codebasis (innerhalb von /discourse).
Kompiliere deine Codebasis in einen Docker-Container.
Stelle diesen Docker-Container auf deinem Produktionsserver bereit.
Ein Anwendungsfall für die lokale Ausführung von Docker ist das Testen deines neu kompilierten Docker-Containers, bevor du ihn auf deinem Produktionsserver bereitstellst.
Die An- oder Abwesenheit von Docker ist für die Entwicklung fast aller Plugin- und Theme-Komponenten eher irrelevant. Das ist ein separates Anliegen. Ich führe in der Entwicklung keine Docker-Instanz aus.
Bei der Entwicklung von Add-ons für Discourse sollten Sie sich nicht über die exakte Version oder Konfiguration Ihrer Entwicklungsinstanz im Vergleich zur Produktionsinstanz den Kopf zerbrechen, da Sie ohnehin meist keine Kontrolle über die meisten Instanzen haben, auf denen Ihr Plugin landen wird, wenn es Open Source ist. Das Wichtigste ist, bewährte Praktiken zu befolgen, um Ihr Add-on robuster gegenüber Änderungen im Discourse-Kern zu machen. Selbst wenn Sie nur für Ihre eigene Discourse-Instanz entwickeln, haben Sie keine Kontrolle über Änderungen im Discourse-Kern, daher gilt derselbe Ansatz.
Leicht unterschiedliche Versionen sollten Ihr Plugin oder Ihre Theme-Komponente im Allgemeinen NICHT zum Scheitern bringen. Das kann passieren, ist aber nicht konsistent. Meine Plugins und TCs können monatelang ohne Änderungen auskommen, auch wenn die Kern-Commits Monate auseinanderliegen.
Ich aktualisiere meine Entwicklungsinstanz normalerweise auf den neuesten Master, wenn ich an Plugin-Änderungen (Fehlerbehebungen oder Erweiterungen) arbeite, um eventuelle brechende Änderungen einzufangen. Das wird einfach durch ein git pull, bundle install und db:migrate erreicht.
Produktionsinstanzen sollten einfach über die Benutzeroberfläche oder den Befehlszeilen-Rebuild aktualisiert werden.
Mein Rat wäre, ein Plugin öffentlich verfügbar zu machen, Nutzer anzuziehen und mit der Erfahrung die Stolpersteine der Reise zu lernen. Zögern Sie nicht zu lange: Machen Sie es! Und machen Sie sich keine Sorgen über Fehler, denn sie helfen Ihnen beim Lernen.
Solche Fragen würdest du am besten im Docker-Entwicklungsthema stellen. Im Moment würde ich die Standard-Skripte zur Verwaltung der Docker-Entwicklungsumgebung nicht ändern, es sei denn, du hast einen sehr guten Grund. Vermutlich sind sie dort, um dir zu helfen.