Understanding the development/deployment process

Dev
1

Hi all,
Having decided that Discourse represents the best platform for a new community project I’m launching, I’ve been lurking in the forums for a few weeks now, trying to get my head around how it all hangs together. Even as an experienced .NET and PHP developer, there’s been quite a learning curve in understanding the differences with a Ruby app.

I figured it was time to stop reading and start getting my hands dirty, so I managed to get a local instance running under Docker on macOS and then swiftly realised that there is still much for me to learn as I couldn’t figure out why I couldn’t locate the app.yml file. After some more trawling, I came across this extremely useful post which dispelled some of mental fog I’ve always laboured under with regards to the official Docker install vs the canonical repository: What is the recommended workflow for managing a live Discourse site?

Following this particular lightbulb moment, I believe I now understand that the model I’m accustomed to — where distributed development takes place across independent local dev environments, before being pushed to a test server and up the chain to a QA/staging environment and eventually up to production — doesn’t necessarily apply here. So I’m hoping some of the experienced community members can help to confirm or dismiss some of my current assumptions before I proceed any further:

  1. I initially created a fork of the main repository and cloned that locally, but this approach is only necessary if I’m attempting to develop a plugin of my own or contribute to Discourse itself? For the purposes of simply customising our site by installing a theme/plugins, etc; the typical process would simply involve installing Discourse to a production environment and then potentially creating a second instance for testing new features?
  2. If the above assumptions are correct, then what would be an appropriate workflow to support effective customisation by multiple parties? As this is a collaborative project, there will be other developers who are working on the site and it doesn’t strike me as ideal to have to provide direct access to the hosting environment simply to enable any contributor to make the relevant changes. Would this demand separate hosted environments to enable contributors to work in independent instances or is there a supported workflow that supports local customisations?
  3. In any instance, I’d like app.yml to be source-controlled, which to my mind could be handled by forking the discourse_docker repo and then committing app.yml; is there any argument why this wouldn’t be a wise approach and if so, what would be the advised alternative?

Apologies in advance if any of these questions seem obvious on the face of it. :sweat_smile:

1 Like
2

  1. Yes

  2. Themes live in their own git repo. So you can create a central theme repo in GitHub and everyone can work on that, test locally and push changes upstream. Check Structure of themes and theme components

  3. In normal instance usage, you almost never change the app.yml. However, nothing stops you from putting that in it’s own repo and symlinking the file where launcher expects it.

4 Likes
3

Thank you so much, your answer to #2 helps a lot, but I’m just slightly confused by #3. Isn’t editing app.yml (and rebuilding) the correct way to install plugins in normal usage?

4

Yes, you add a new plugin by editing the app.yml.

However, that is not something you do everyday. After your instance is live and in production, you will be installing plugins maybe once or twice a year in production.

Discourse is a bit different than wordpress here, where you don’t need plugins for basic forum usage.

2 Likes
5

Ah, I follow you. Thanks again for the assistance!