[chef] Re: Re: Re: Re: Re: Environments vs. Metadata vs. Policyfile for locking cookbook dependencies

[Daniel DeLeo < >]

On Friday, June 20, 2014 at 10:36 AM, Maxime Brugidou wrote:

> I am not sure I understand correctly the Policy system but we clearly work 
> by environments. Actually we wanted all our cookbooks pinned by environment 
> so we went all the way to have a separate chef server and the 
> Berksfile.lock of the git branch corresponds to the pinned cookbooks.
> This way promoting is simply a release of our development branch to 
> preprod/prod.
> We really don't want to have heterogeneity within the environment. If we 
> upgrade a basic cookbook like apt it must go everywhere. This is because we 
> consider our chef repo as a specific app within the company that gets 
> released just like any other app. This is actually very different than use 
> cases where a role is tied to an app and you want to upgrade the app's apt 
> cookbook without impacting other apps.
> Not sure if I make sense here.

Is there a specific requirement that leads you to consider the entirety of 
the chef repo as the shippable artifact that you release? The idea of the 
policyfile is that you have shippable artifacts at a functional role level of 
granularity.

That said, you can still create a workflow and process that results in 
homogeneity at the environment level out of a set of tools that allow 
heterogeneity at the environment level, but trying to do the opposite doesn’t 
work well.

Also, we’re exposing all of the building blocks that the high level 
policyfile experience is built on so you can create something totally 
different if that works for you. For example, it would be relatively easy to 
just convert your chef-repo into a policy lock, upload it and move the exact 
cookbook versions around between your deployment stages.


--  
Daniel DeLeo