Ciao a tutti. Ho riscontrato un problema durante lo sviluppo di Discourse.
Di solito clono i file da Git,
Apporto delle modifiche,
E creo un commit su Git.
Il mio compagno di squadra esegue un git pull
E ottiene tutte le mie modifiche.
Come posso implementare qualcosa di simile in Discourse?
Come posso apportare modifiche in modo che altri possano installarle in locale?
Se stai sviluppando un tema o un plugin per Discourse, entrambi possono risiedere tranquillamente in un repository Git.
Grazie per la risposta. Sì, hai ragione riguardo all’argomento. E per quanto riguarda la sincronizzazione di componenti e impostazioni?
Il codice del tuo plugin può definire migrazioni e/o contenuti di seed, se necessario. Può anche garantire che le impostazioni del sito abbiano il valore appropriato.
Voglio clonare completamente la mia installazione
Puoi eseguire un backup e ripristinarlo dove necessario.
Ci ho provato. Ricevo un errore durante il ripristino
Mi piace utilizzare S3 per i backup, in modo che tutti i siti possano condividere lo stesso set di backup. Quindi, quando esegui un backup sull’ambiente di produzione, puoi ripristinarlo immediatamente sui siti di staging per verificare che funzioni con i dati attuali.
Cos’è S3? Vorrei utilizzarlo
Utilizzo dell’archiviazione oggetti per i caricamenti (S3 e cloni) e Configurazione dei caricamenti di file e immagini su S3 sono i punti di partenza. Per i soli backup è piuttosto semplice.
Backblaze e Wasabi sono economici. Anche storj.io ha un prodotto che ho utilizzato per i backup.
Solo il mio parere, e senza sminuire i commenti utili qui sui backup, ma facendo un passo indietro: non sono davvero sicuro che sincronizzare le installazioni di Discourse valga la pena di molto sforzo.
A meno che tu non intenda contribuire al core di Discourse tramite PR, lo sviluppo di plugin o TC è la strada da percorrere e offre la soluzione più robusta ed efficiente per la personalizzazione.
Il punto chiave nello sviluppo di Plugin e Componenti di Tema è che verranno distribuiti su più istanze di Discourse, sulle quali potresti non avere comunque alcun controllo?
Quindi avere un’istanza locale di Discourse leggermente unica per lo sviluppo è perfettamente accettabile (entro limiti ragionevoli).
Il flusso di lavoro principale dovrebbe consistere nel mantenere il plugin o il TC aggiornato in un repository condiviso, molto probabilmente su Github.
Concordo pienamente. Ho alcuni clienti con personalizzazioni che non possono essere verificate (o sono più facili da verificare) rispetto ai loro dati reali, quindi apprezzano molto vedere il sito con i dati attuali.
Sì, è giusto. Dipende da cosa stai cercando di fare e da chi è la base di clienti (un singolo target o più clienti?) e da quanto controllo ti aspetti di avere.
Grazie a tutti per i consigli. Molto probabilmente, utilizzerò PRing nel core di Discourse. Pertanto, ho bisogno della possibilità di caricare l’assembly su Git e da Git al server.
Se stai inviando una PR al core di Discourse, la configurazione esatta dell’installazione locale non è critica (basta assicurarsi di essere sull’ultima versione), poiché il contributo al codice è comunque un processo molto controllato, specialmente con i casi di test. Quindi, una leggera variazione nelle impostazioni o nei contenuti è improbabile che rappresenti un problema.
Normalmente, se si lavora su contributi congiunti, si fa un fork nel repository della propria organizzazione e si lavora lì prima di inviare una PR?
No, non sto lavorando su contributi congiunti. Lavoro per uso personale.
Non volevo dirlo in quel modo.
Come posso installare Discourse da un fork di git?
Farò delle modifiche al core di Discourse e le aggiungerò al mio repository su git.
Quindi sono confuso sul perché tu debba sincronizzare le tue installazioni.
Basta eseguire git clone del tuo fork.
Normalmente non si usa Docker per lo sviluppo, ma se lo fai, puoi entrare nel tuo container e controllare il tuo fork.
Ad esempio.
Ora ho configurato Discourse.
Quindi, quando tutto è pronto, aggiorno la mia build.
Quindi riprendo lo sviluppo. Sto modificando alcune impostazioni nel pannello di controllo. Potrebbero essercene molte.
Quando voglio aggiornare la mia build, dovrò aggiornare anche le impostazioni.
In questo caso, dovrò impostare manualmente le impostazioni.
Le impostazioni sono persistenti e stai lavorando da solo, quindi perché concentrarsi su backup/sync?
(inoltre, il titolo dell’argomento è confuso: perché “in un team”?)
Quando cloni o effettui il checkout, non cancelli il database (dove sono memorizzate le impostazioni).
Sei tu a decidere quando eseguire le migrazioni (se esistono). Altrimenti, il DB dovrebbe rimanere stabile.
