Hola a todos. Me encontré con un problema mientras desarrollaba en Discourse.
Normalmente clono archivos desde Git, hago cambios y luego creo un commit en Git. Mi compañero hace un git pull y obtiene todos mis cambios.
¿Cómo puedo implementar algo similar en Discourse? ¿Cómo puedo realizar cambios para que otras personas puedan instalarlos en sus propios entornos?
Si estás desarrollando un tema o un plugin para Discourse, cualquiera de los dos puede alojarse perfectamente en un repositorio Git.
Gracias por la respuesta. Sí, tienes razón sobre el tema. ¿Qué hay de la sincronización de componentes y configuraciones?
El código de tu plugin puede definir migraciones y/o contenidos de semilla según sea necesario. También puede asegurar que la configuración del sitio tenga el valor adecuado.
Quiero clonar mi instalación completamente
Puedes realizar una copia de seguridad y restaurarla donde sea necesario.
Me gusta usar S3 para las copias de seguridad, de modo que todos los sitios puedan compartir el mismo conjunto de respaldos. Así, cuando realizas una copia de seguridad en producción, puedes restaurarla inmediatamente en tus entornos de staging para verificar que funciona con los datos actuales.
¿Qué es S3? Me gustaría usarlo.
Usar almacenamiento de objetos para cargas (S3 y clones) y Configurar cargas de archivos e imágenes a S3 son los puntos de partida. Para copias de seguridad únicamente, es bastante sencillo.
Backblaze y Wasabi son económicos. Además, storj.io tiene un producto que he utilizado para copias de seguridad.
Solo mi opinión, y sin restar valor a los comentarios útiles aquí sobre las copias de seguridad, pero reflexionando un poco: no estoy seguro de que valga la pena mucho esfuerzo sincronizar instalaciones de Discourse.
A menos que tengas la intención de enviar contribuciones (PR) al núcleo de Discourse, desarrollar plugins o componentes de tema (TC) es lo más recomendable y te ofrece la solución más robusta y eficiente para la personalización.
Lo fundamental al desarrollar plugins y componentes de tema es que se implementarán en múltiples instancias de Discourse, sobre las cuales, en cualquier caso, es posible que no tengas control.
Por lo tanto, tener una instancia local de Discourse ligeramente única para el desarrollo está perfectamente bien (dentro de lo razonable).
El flujo de trabajo clave debería consistir en mantener el plugin o el TC actualizado en un repositorio compartido, muy probablemente en GitHub.
Estoy totalmente de acuerdo. Tengo varios clientes con personalizaciones que no se pueden verificar (o que es más fácil verificarlas) con sus datos reales, por lo que les gusta mucho ver el sitio con los datos actuales.
Sí, eso es justo. Depende de lo que intentes hacer y de cuál sea la base de clientes (un solo objetivo o varios clientes) y de cuánto control esperas tener.
Gracias a todos por sus consejos. Lo más probable es que utilice PRs directamente en el núcleo de Discourse. Por lo tanto, necesito la capacidad de subir el ensamblaje a Git y desde Git al servidor.
Si vas a enviar un PR al núcleo de Discourse, la configuración exacta de tu instalación local no es crítica (solo asegúrate de tener la versión más reciente), ya que la contribución de código es un proceso muy controlado de todos modos, especialmente con casos de prueba. Por lo tanto, es poco probable que una ligera variación en la configuración o el contenido cause problemas.
Normalmente, si trabajas en contribuciones conjuntas, ¿forklearías a un repositorio de tu organización y trabajarías allí antes de enviar el PR?
No, no estoy trabajando en contribuciones conjuntas. Lo hago para uso personal.
No quería decirlo de esa manera.
¿Cómo puedo instalar Discourse desde un fork de git?
Haré cambios en el núcleo de Discourse y los agregaré a mi repositorio en git.
Así que no entiendo por qué necesitas sincronizar tus instalaciones.
Simplemente ejecuta git clone en tu bifurcación.
Normalmente no usarías Docker para el desarrollo, pero si lo haces, puedes entrar en tu contenedor y revisar tu bifurcación.
Por ejemplo.
Ahora tengo Discourse configurado.
Luego, cuando todo esté listo, actualizo mi compilación.
Después, continúo con el desarrollo nuevamente. Estoy cambiando algunas configuraciones en el panel de control. Puede haber muchas.
Cuando quiera actualizar mi compilación, también tendré que actualizar las configuraciones.
En este caso, tendré que establecer las configuraciones manualmente.
La configuración es persistente y estás trabajando solo, ¿entonces por qué la necesidad de centrarse en la copia de seguridad/sincronización?
(también el título del tema es confuso, ¿por qué “en un equipo”?)
Cuando haces clonación o checkout, no borras la base de datos (donde se guarda la configuración).
Tienes el control de cuándo ejecutar las migraciones (si existen). De lo contrario, la BD debería ser estable.
