Bryan’s scenario is fairly normal for an company with multiple teams and projects that have a bit of crossover in their codebases. In our company we also have to support multiple ‘production like’ environments for application support and users who want to try ‘what if’ scenarios without impacting production data. From: Bryan Berry [mailto:
Sent: Tuesday, May 01, 2012 4:15 AM
To:
Subject: [chef] Re: Re: conflict between using environments to manage cookbook releases and to manage application environments hey, pls let me clarify that the 4 different environments was the decision of the project's software architect, not my own. I have to live with it and support it regardless of how I feel about it. I agree with your notes on culture and on version control, but these are things that I have tried to affect with little success so far. I practice what you recommend in terms of environments by having only two Chef environments QA and PROD
basically stable and unstable. On Tue, May 1, 2012 at 1:09 PM, Joseph Holsten <
" target="_blank">
> wrote: 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
>
|