Typical Structure
For typical use, we don't recommend modifying any of the distributed configuration environments as it makes it easier for you to receive updates to the backend without merging your changes with ours. However, Redwood comes with the full source code so you have ultimate flexibility. If you need to add a config variable or change defaults for the production environment, there's no technical reason not to, just an extra operational hoop to jump through during updates.
With that said, together with flexible customization and inheritance, we believe that the majority of the time you just need to override the value of a configuration variable.
We alluded to how we structure our live games in the inheritance section, but in this section we provide an example what we have used for some of our demo live games.
Your game may require a more complex setup. You may need environments that are specific to different teams, hosted staging environments for release-candidate builds, and more.
Base Configuration Environment
We define a config environment for the game and name that folder just the name of the title. We use this for common attributes for the game that are used in all environments. We typically use this environment directly for testing locally without Kubernetes.
We created this environment in the Getting Started section; our example called this environment project-name.
Kubernetes Configuration Environment
This configuration environment is used for local Kubernetes development, inheriting from the provided kubernetes environment and the base configuration ("parentNames": ["kubernetes", "project-name"]). It defines common values for both local and cloud Kubernetes deployments (e.g. switching realms to the agones game server provider), but is typically used directly for local deployments.
We created this environment in the Deploying to Kubernetes | Deploying Locally section; our example called this environment project-name-k8s.
Production Configuration Environment
This configuration environment is used when deploying to the production hosting environment. This environment uses multiple parent inheritance to inherit from the provided production environment and the Kubernetes configuration ("parentNames": ["production", "project-name-k8s"]). It's where your production-only values go: public hostnames, your managed database, real secrets (via the secrets system), your container registry, and your cluster's kubeconfig.
We created this environment in the Deploying to Kubernetes | Deploying Remotely section.
A staging environment that mirrors production but points at a separate cluster and database is usually just one more environment with "parentNames": ["staging", "project-name-k8s"] (or inheriting from your production environment and overriding the few values that differ).
Local Configuration
Sometimes during development, we want to override a variable to expedite development or force a specific scenario. While one option is to just change the base configuration environment, we have found it useful in some scenarios to define an extra local config environment that inherits from whichever environment you're currently using. Here we can specify just the variables we want to change for testing purposes.
There's nothing special about the local name here; you can name this anything (e.g. temp). You still need to implement proper inheritance to get this to work.
This local configuration environment normally shouldn't be added to source control as it's meant to be temporary/ephemeral. Because of this, it's very easy to forget you changed a variable temporarily without removing it. This can cause headaches later down the road as you may struggle to find why the behavior is modified from the expected scenario and/or compared to other developers, so be wary when using this workflow.