Automatic Deployment to Production Environment
The discussion revolves around automating deployment of Discourse settings and configurations from a staging environment to a production environment. Celso_Teixeira is looking for a solution to achieve this with Discourse installed on two separate Azure VMs.
pfaffman suggests pushing the staging container to a repo and launching it on production using ./launcher start-cmd app. This approach requires migrating the database and precompiling assets. Some settings can be set with ENV variables, while others live in the database.
merefield proposes a lighter-weight strategy by manually transferring non-default settings using the “only show overridden” feature in the Discourse settings. This approach may be simpler but won’t carry across Categories, etc.
Celso_Teixeira inquires about the feasibility of achieving this with a standalone approach or if two containers (one for the database and one for the web) are necessary. pfaffman advises using two containers for zero downtime, but acknowledges that a single container would also work.
Hi,
I have Discourse installed on two separate Azure VMs (staging and production). Is there a way to automatically deploy changes from staging Discourse to production Discourse?
UI changes (theme) will be managed in a Git repository, so shipping them to production won’t be a problem. The main concern lies in automating the deployment of Discourse settings and configurations to the production environment. How can we achieve this?
You can push the staging container to a repo and then launch it on production. The ./launcher start-cmd app will give you the required stuff to crank up the container in Docker.
You’ll also need to migrate the database (perhaps with SKIP_POST_DEPLOYMENT_MIGRATIONS and then again when the new container has started if you want true zero downtime) and precompile assets.
Some settings live the the database. Others can be set with ENV variables like DISCOURSE_SETTING_NAME (e.g., DISCOURSE_TITLE='my great communiyt')
A lighter weight strategy is to use this:
Note the “only show overriden” in top right
That will give you a list of things which aren’t default which you might transfer manually.
Depending on your need this might be simpler. (That said, I’ve got 100 + settings that are not default on my several year old instance.)
app.yml can be partially copied.
Of course that won’t carry across Categories etc.
Can this be achieved with a standalone approach, or do I need to have two containers (one for the database and one for the web)?
If you’re not a hobbyist, I recommend two containers, as you have to shut down the database when you start a new container so you can’t have zero downtime. But it would work with a single container.
