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
>
Archive powered by MHonArc 2.6.16.