Hallo zusammen. Ich bin bei der Entwicklung von Discourse auf ein Problem gestoßen.
Normalerweise klone ich Dateien aus Git,
nehme Änderungen vor,
erstelle ein Commit in Git.
Mein Teamkollege führt ein git pull aus
und erhält alle meine Änderungen.
Wie kann ich etwas Ähnliches in Discourse umsetzen?
Wie kann ich Änderungen so vornehmen, dass andere sie zu Hause installieren können?
Wenn Sie ein Discourse-Theme oder ein Plugin entwickeln, kann beides problemlos in einem Git-Repository untergebracht werden.
Danke für die Antwort. Ja, du hast bezüglich des Themas recht. Wie sieht es mit der Synchronisierung von Komponenten und Einstellungen aus?
Ihr Plugin-Code kann bei Bedarf Migrationen und/oder Seed-Inhalte definieren. Er kann auch sicherstellen, dass die Site-Einstellungen den entsprechenden Wert haben.
Ich möchte meine Installation vollständig klonen
Sie können ein Backup erstellen und bei Bedarf wiederherstellen.
Ich habe es versucht. Beim Wiederherstellen erhalte ich einen Fehler.
Ich verwende gerne S3 für Backups, sodass alle Websites denselben Backup-Satz nutzen können. Wenn Sie dann ein Backup in der Produktionsumgebung durchführen, können Sie es sofort auf Ihren Staging-Sites wiederherstellen, um zu prüfen, ob es mit den aktuellen Daten funktioniert.
Was ist S3? Ich möchte dies verwenden.
Verwendung von Object Storage für Uploads (S3 und Klone) und Einrichten von Datei- und Bild-Uploads auf S3 sind gute Ausgangspunkte. Für reine Backups ist das recht einfach.
Backblaze und Wasabi sind günstig. Auch storj.io hat ein Produkt, das ich für Backups verwendet habe.
Das ist nur meine bescheidene Meinung, und ich möchte die hilfreichen Kommentare zu Backups hier nicht schmälern, aber wenn man einen Schritt zurücktritt: Ich bin wirklich nicht sicher, ob es viel Mühe wert ist, Discourse-Installationen zu synchronisieren.
Es sei denn, Sie planen, Pull Requests in den Discourse-Kern einzureichen – die Entwicklung von Plugins oder Theme Components (TCs) ist der richtige Weg und bietet Ihnen die robusteste und effizienteste Lösung für Anpassungen.
Das Wichtigste bei der Entwicklung von Plugins und Theme Components ist, dass sie auf mehreren Discourse-Instanzen bereitgestellt werden, über die Sie möglicherweise ohnehin keine Kontrolle haben.
Daher ist es völlig in Ordnung, eine leicht abweichende lokale Discourse-Instanz für die Entwicklung zu verwenden (innerhalb vernünftiger Grenzen).
Der zentrale Workflow sollte darin bestehen, das Plugin oder die TC in einem gemeinsamen Repository, höchstwahrscheinlich auf GitHub, aktuell zu halten.
Ich stimme dir völlig zu. Ich habe einige Kunden mit Anpassungen, die nicht (oder nur am einfachsten) anhand ihrer tatsächlichen Daten geprüft werden können, daher möchten sie die Seite unbedingt mit den aktuellen Daten sehen.
Ja, das ist fair. Es kommt darauf an, was Sie erreichen möchten und wer Ihre Zielgruppe ist (ein einzelnes Ziel oder mehrere Kunden?) und wie viel Kontrolle Sie erwarten.
Vielen Dank für euren Rat. Höchstwahrscheinlich werde ich einen PR in den Discourse-Core einreichen. Daher benötige ich die Möglichkeit, das Assembly-Image in Git hochzuladen und von dort auf den Server zu übertragen.
Wenn du einen Pull Request (PR) für das Discourse-Kernsystem einreichst, ist die genaue Konfiguration der lokalen Installation wiederum nicht entscheidend (stell einfach sicher, dass du auf dem neuesten Stand bist), da die Code-Einbringung ohnehin ein sehr kontrollierter Prozess ist, insbesondere mit Testfällen. Daher ist es unwahrscheinlich, dass geringe Abweichungen in den Einstellungen oder Inhalten zu Problemen führen.
Normalerweise würdest du bei gemeinsamen Beiträgen zuerst in das Repository deiner Organisation forken und dort arbeiten, bevor du einen PR einreichst, oder?
Nein, ich arbeite nicht an gemeinsamen Beiträgen. Ich arbeite für den persönlichen Gebrauch.
Ich wollte das nicht so ausdrücken.
Wie kann ich Discourse aus einem Fork von Git installieren?
Ich werde Änderungen im Discourse-Kern vornehmen und sie in mein Git-Repository einfügen.
Ich bin also verwirrt, warum du deine Installationen synchronisieren musst.
Klone einfach deinen Fork mit git.
Normalerweise verwendet man Docker nicht für die Entwicklung, aber wenn du es doch tust, kannst du deinen Container betreten und deinen Fork auschecken.
Zum Beispiel.
Jetzt habe ich Discourse konfiguriert.
Wenn alles bereit ist, aktualisiere ich meinen Build.
Dann setze ich die Entwicklung fort. Ich ändere einige Einstellungen im Kontrollfeld. Es kann viele davon geben.
Wenn ich meinen Build aktualisieren möchte, muss ich auch die Einstellungen aktualisieren.
In diesem Fall muss ich die Einstellungen manuell setzen.
Einstellungen bleiben erhalten, und du arbeitest allein – warum also auf Sicherung/Synchronisation achten?
(Auch der Titel des Themas ist dann verwirrend: Warum „im Team"?)
Beim Klonen oder Checkout wird die Datenbank (in der die Einstellungen gespeichert sind) nicht gelöscht.
Du hast die Kontrolle darüber, wann Migrationen ausgeführt werden (falls welche vorhanden sind). Andernfalls sollte die Datenbank stabil sein.
