Thanks for the reply. Yes, you are right about the topic. What about the synchronization of components and settings?
Your plugin code can define migrations and/or seed contents as necessary. They can also ensure that site settings have the appropriate value.
I want to clone my installation completely
You can take a backup and restore where needed.
I tried it. I get an error when restoring
The copy does not appear in the list after even 30 minutes
I like to use S3 for backups and then all sites can share the same backup set. Then when you do a backup on production, you can immediately restore it on your staging sites to see that it works with the current data.
What it is S3? I would like to use this
Backblaze and wasabi are cheap. Also storj.io has a product that I’ve used for backups.
Just my 10 cents, and not to take away from the helpful comments here on backups, but stepping back a bit: I’m really not sure if ‘synchronising’ installs of Discourse is worth much effort.
Unless you intend on PRing into Discourse core, developing plugins or TCs is where it’s at and gives you the most robust, efficient solution for customisation.
The key thing with developing Plugins and Theme Components is they will be deployed to multiple instances of Discourse over which you may not have control in any case?
So having a slightly unique local Discourse instance for development is totally ok. (within reason)
The key workflow should involve keeping the plugin or TC up to date in a shared repo, most likely on Github.
I totally agree. I have a few clients with customizations that can’t be checked (or are easiest checked) against their actual data, so they really like to see the site with the current data.
Yes, that’s fair. It depends what you are trying to do and what the client base is (single target, or multiple customers?) and how much control you expect to have.
Thank you all for your advice. Most likely, I will use PRing into Discourse core. Therefore, I need the ability to upload the assembly to the git, and from the git to the server
If you are PRing to Discourse core, then again, exact config of local install not critical (just make sure you are on latest), because code contribution is a very controlled process anyway, especially with test cases., so a little variation in settings or content is unlikely to be an issue.
Normally, if working on joint contributions, you’d fork to your org’s repo and work on there before PRing?
No, I not working on joint contributions. I work for personal use
I didn’t to put it that way
How can I install a discourse from a fork of the git?
I will make changes into Discourse core and add them to my repo on git
So I’m confused why you need to sync your installations?
Just git clone your fork.
Normally you would not use docker for development but if you are you can enter your container and check out your fork.
Now I have Discourse configured
Then, when everything is ready, I update my build.
Then I continue the development again. I’m changing some settings in the control panel. There can be a lot of them.
When I want to update my build, I will need to update the settings as well
In this case, I will have to manually set the settings
Settings are persistent, and you are working alone, so why the need to focus on backup/sync?
(also the title of the Topic is confusing then, why “in a team”?)
When you clone or checkout you do not wipe the database (where the settings are held).
You are in control of when to run migrations (if any exist). Otherwise the DB should be stable.
My question name is " How to develop discourse in a team?"
I want the settings to be the same in the local Discourse of my teammates
Point taken, but I don’t think it’s critical to what you are trying to achieve.