[chef] Re: conflict between using environments to manage cookbook releases and to manage application environments

[Joseph Holsten < >]

Think of them as isolated data centers. I can understand you don't want your 
production mixing with your in development setup. But your 5-phase pipeline 
sounds a bit overkill.

Your devs have a reasonable level of forgiveness to each other when someone 
pushes code to master with a bug, yes? Push a fix and all is well. I strongly 
recommend you get a culture that lets you have a single master/prod and many 
short lived one-off feature branches/envs.

The more phases there are between dev and prod, the more differences there 
will be, the more likely something that seems to work in dev will not work in 
prod.

--
josephholsten.com

On 2012-05-01, at 09:17, Bryan Berry wrote:

> I would like to see chef_environments renamed to something like "zones" and 
> only manage cook versions and no other attributes, and then see 
> environments as a place to hold values specific to your 
> application_environments
> 
> On Tue, May 1, 2012 at 11:06 AM, Nikolay Sturm 
> <
 >
>  wrote:
> * Bryan Berry [2012-05-01]:
> > Some cookbooks, such as the haproxy cookbook, treat chef_environments
> > like application_environments
> >
> > I would love to treat chef_environments like application_environments
> > but that would completely break my workflow. How are others dealing w/
> > the issues I have brought up here?
> 
> I hate this mixup of chef and application environments, maybe I just
> haven't seen the light yet. Anyways, we use the opscode platform and
> introduced a second organization for cookbook tests. Big PITA and I
> would really love to see a clean solution.
> 
> cheers,
> 
> Nikolay
> 
> --
> "It's all part of my Can't-Do approach to life." Wally
>