librelist archives

Configuring Tir for different environments

Configuring Tir for different environments by Matt N
- Re: [mongrel2] Configuring Tir for different environments by joshua simmons

Configuring Tir for different environments

From:: Matt N
Date:: 2011-01-30 @ 19:32

>> - I wish I had a better way to configure a PROD vs DEV environment.  
config.lua might be the right place for this, but i've spent the last two 
weeks learning Lua.  Very little time learning tir.
> 
> Can you lay out what you might want on this?  There's not much to
> configure in Tir itself, so I haven't ran into needing a difference
> except for unit tests.  There's some gear for it, but not the best for
> doing automated deploys and such.
> 


I usually have settings that are dependent on one of two things:
- the machine: (laptop, test-server, prod-server, etc.)
- the mode:(DEV, PROD, UNITTEST, etc.)

After giving it some though, I can imaging something like:

require 'environment.machine.constants'
require 'environment.mode.constants'

local baseURL = environment.machine.constants.baseURL

where on the laptop, baseURL is "localhost:6767"
but on the test-server, baseURL is "beta.example.com"
and on prod-server, baseURL is "example.com"

similarly, 

local dbindex = environment.mode.constants.dbIndex

for DEV, dbindex is 1, and filled with garbage data.  just a sandbox.
for PROD, dbindex is  0, which contains actual production data (or a copy 
if on the laptop)
but for mode UNITTEST, we use dbindex 15, since we would be constantly 
flushing that particular db to get it to a known state.

Just my ideas though and certainly specific to my workflow.  Don't get too
hung up on my semantics, but I'm curious if this type of organization 
would be useful.

Lastly, despite the example, you wouldn't necessarily be limited to 
constants.  It seems perfectly reasonable that a function like 
connectToDB() might have a completely different implementation depending 
on machine or mode.  Error handlers, logging, etc. are all good candidates
to be machine or mode dependent.

Isolating these into an environment module means you don't have tons of 

if PROD then ... else if UNITTEST then ... end 

all over your app.

Re: [mongrel2] Configuring Tir for different environments

From:: joshua simmons
Date:: 2011-01-30 @ 20:11

Personally I'd have config.setting-name in app code then have the values
populated by selecting the mode at startup. Then you can have a layered
config where if no site or mode specific entry is found it falls back to the
standard config file.
On Jan 31, 2011 6:32 AM, "Matt N" <mtnngw@gmail.com> wrote:
>>> - I wish I had a better way to configure a PROD vs DEV environment.
config.lua might be the right place for this, but i've spent the last two
weeks learning Lua. Very little time learning tir.
>>
>> Can you lay out what you might want on this? There's not much to
>> configure in Tir itself, so I haven't ran into needing a difference
>> except for unit tests. There's some gear for it, but not the best for
>> doing automated deploys and such.
>>
>
>
> I usually have settings that are dependent on one of two things:
> - the machine: (laptop, test-server, prod-server, etc.)
> - the mode:(DEV, PROD, UNITTEST, etc.)
>
> After giving it some though, I can imaging something like:
>
> require 'environment.machine.constants'
> require 'environment.mode.constants'
>
> local baseURL = environment.machine.constants.baseURL
>
> where on the laptop, baseURL is "localhost:6767"
> but on the test-server, baseURL is "beta.example.com"
> and on prod-server, baseURL is "example.com"
>
> similarly,
>
> local dbindex = environment.mode.constants.dbIndex
>
> for DEV, dbindex is 1, and filled with garbage data. just a sandbox.
> for PROD, dbindex is 0, which contains actual production data (or a copy
if on the laptop)
> but for mode UNITTEST, we use dbindex 15, since we would be constantly
flushing that particular db to get it to a known state.
>
> Just my ideas though and certainly specific to my workflow. Don't get too
hung up on my semantics, but I'm curious if this type of organization would
be useful.
>
> Lastly, despite the example, you wouldn't necessarily be limited to
constants. It seems perfectly reasonable that a function like connectToDB()
might have a completely different implementation depending on machine or
mode. Error handlers, logging, etc. are all good candidates to be machine or
mode dependent.
>
> Isolating these into an environment module means you don't have tons of
>
> if PROD then ... else if UNITTEST then ... end
>
> all over your app.
>
>