Document example of managing multiple environments

[derks]

Common use case in development and deployment is the management of multiple environments, a la development, staging, and production. Might not be a clear way to handle this in Cement directly, but would be feasible to atleast put together an "example" of how one might implement that. For example, with a -E (environment) command line option that triggers a specific configuration file, or something like that.

[derks]

Possibly:

[myapp]
some_param = some value
environment = development

[myapp:production]
some_param = some value that overrides the default if `environment` is `production`

[myapp:staging]
some_param = some other value

[myapp:development]
some_param = some other value

Then:

$ myapp do-something -E production

The purpose of the above would be that you could manage a single configuration file (automated deployments?) rather than multiple myapp-environment.conf files which is annoying.

This probably won't ever be a core feature (not any time soon really) but setting this up with some sub-classing in CementApp should be pretty easy for anyone to get going.

[spinus]

Why not use different files?
I have deployed fey projects like that (some kind of rails apps) when they have devel/prod configurations on the same files. Nightmare, Maybe it's convinient, but when I am logging after a while I am never sure what is running. I need few moments. The second case is, when you have one specific config it's easier to read it.

[derks]

This isn't a feature, so much as an example of how one might do it. I definitely agree that having everything jammed into a single file can be annoying... but it really depends on the use case. My logic is that this same code/example could be used to control multiple target environments (not necessarily production/staging/etc). For example, an app that needs to run against rackspace differently than in digital ocean... where the environment is a target of the app, and not the environment that the app is running in. In that use case, you wouldn't want multiple config files:

$ myapp do-something-in-the-cloud -E rackspace

$ myapp do-something-in-the-cloud -E digital-ocean

$ myapp do-something-in-the-cloud -E aws

Etc.... maybe not the best example, but you know. I guess an even better example might be this: At my $dayjob we've got multiple Rackspace accounts for different purposes (not just production/staging)... and it is a pain in the ass to constantly context switch with apps that don't readily support that (a la Chef). In this use case, all of the params are the same, with different values:

[myapp]
some_param = some value
default_rackspace_environment = infrastructure

[rackspace:infrastructure]
api_user = some-user-name
api_key = XXXXXXXXXXXXXX
region = dfw

[rackspace:some-other-use-case]
api_user = some-other-user-name
api_key = YYYYYYYYYYYYYY
region = ord

Using Chef/Knife as an example, we have to constantly switch accounts using knife-block:

$ knife block use rackspace-infrastructure

$ knife rackspace server list

$ knife block use rackspace-some-other-account

$ knife rackspace server list

With something like what we're talking about above:

# default account/environment
$ knife rackspace server list

$ knife rackspace server list -E some-other-account

The some-other-account isn't used that often, but it really is a pain to have to switch config files everytime I want to talk to it.

[spinus]

I've got your idea. I've never tried to use day-tool like that, even for that I would use separate configs (but maybe it's because of bad trips with other configurations like that). Anyway, it's nice that this project is moving.