I’m trying to figure out a good workflow for managing a live Discourse site and have a few more questions:
1. Development Environment
I have Discourse running on my laptop (Ubuntu 16.04), but the cloned Github repo is missing files like app.yml. Some of the tutorials here in the forum mention that I should edit the app.yml file, but it doesn’t exist in my development versions. How do people manage that difference on production sites? Are the local development versions always different codebases than the live site? Is there a recommended way to have a staging environment for the live codebase too?
2. Backups and Server Migration
I put an experimental Discourse forum online to test workflows before migrating my main site. When I backup the site through the UI, I get the database and uploaded files. How do people generally backup the rest of the site? What else needs to be backed up if I want to rebuild the site on a new server in the event of a disaster (like getting hacked) on the original server? Do I need to backup app.yml or any other files to rebuild it?
3. Upgrades
How do I upgrade a live site? If I click the upgrade button, the live site upgrades, but my local development version doesn’t update. Should I update the sites locally with Git and then push the changes to the live server by creating another remote setting in a fork of the main Discourse repo and working in a custom branch? Or do people generally have a development version that is a completely different installation of Discourse?
4. Plugins
Is it correct that I should write my plugins in separate repos, clone them to the live server, and then symlink them in the plugins directory? Or should I use app.yml to install them? Different posts in the forum here seem to suggest different things.
I think most of the confusion here comes from the fact that there are two repositories:
One that contains the ruby + emberjs code - the canonical Discourse codebase. I’m assuming this is what you’re running when you’re talking about development environments. For development in discourse or on plugins, it’s faster and easier to work from here.
Then there’s the official discourse install that’s used for site deployments, through docker. The app.yml file is one of those, in common installs taken from the samples/standalone.yml template. It’s a convenient wrapper for docker that allows for easy deployment and configuration.
Backups - The app.yml file should also be backed up as that is your install’s configuration, which includes plugin details and email credentials. Other than that, the only thing you should need is the backup tar.
Before I waste my breath leading you down the wrong path, I’d be curious to know what you’re using a dev install for, as I would recommend staying away from maintaining a fork - If it’s to develop your own plugins, then keep on trucking with a dev env! If it’s to test out updates or develop themes, you can do that with a mirrored environment deployed under docker, in the exact same way that your production is.
Thanks, that helps. I’m trying to avoid ending up with a live install that is difficult to manage. If I can create a identical installations with just the DB backup and the app.yml file, then that should work.
On the production site, should I install the plugins with the app.yml file while using a symlink in the plugins directory on the development version during plugin development?
Yes that’s it exactly - through the docker/production install, you shouldn’t need to do any sort of filesystem maintenance, as it is a config for any plugin installs in your app.yml. Under the hood, plugins are cloned into the plugins directory on build.
In a dev env where you want to have control and build, develop, or alter your environment, use symlinks.
(Hi by the way, I think I recall that we ran into each other on University a little while ago )
Small world – it must be, because I’m over in the Au Coquelet area a few times per week. Was it through the programming meetup group?
(My main testing forum is a private one for our local meetup groups. A migration of my other, main site is happening this week, so I’m trying to make sure I deploy it correctly.)