The requirement of having the entirety of the chef repo as deployable artifact comes naturally when you have it in git. You want to ship that specific branch/commit.
This actually led us to have multiple chef repos (and chef servers, called "perimeters") because we needed to deal with large teams and different deployments.
So basically we are enforcing the policy system to the extreme by having one chef repo/server (we currently have 6 of them (+preprods) and try to not add more unless a team is dedicated to maintain it).
I don't see how we could work it out with proper git workflow if we didn't split the repos. The best solution would have been using chef organizations (not open source) to have a single chef server.
The current workflow is actually very satisfying, we just have a simple internal tool using former knife-essentials to sync all objects from git to chef. We could have gone with pure role cookbooks and locking all versions but that seemed way too dangerous. We needed the guarantee of segregating at least perimeters.
We never encounter dependency management issue. Just need upgrading the Berksfile.lock.
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
Archive powered by MHonArc 2.6.16.