As your simple Rails app grows into a larger system or set of systems, using simple constants and Yaml files for configuration may no longer suffice. The meaning of 'configuration' expands to include business logic alongside the customary hostnames and timeout intervals; the rate at which configuration changes are required increases; non-engineers begin to require the ability to make configuration changes themselves; different environments require different configurations. This presentation will examine several patterns that can be applied to handle these issues, keeping iteration team high and reducing the burden on your engineering team. We'll create and iterate on a simple game as a case study to illustrate the value of these principles in practice, and also look at a few open source projects that integrate some of these concepts.
* moving configuration values out of source
* sharing configuration across multiple applications/services
* working with sensitive configuration data (eg API keys)
* dynamically updating configuration without deployments or restarts
* cascading/overlaying configuration values based on environment and context
* running experiments and A/B tests
* change control
* testing and multi-stage deployment of configuration changesets
* allowing non-developers to change configuration values
Help us caption & translate this video!
Rails Conf 2013