The web side of the company is doing something like the environment cookbook pattern, where each rev of an application has its own environment, and there ~150 apps. If I'm understanding this correctly, that means there are maybe ~500-1000 environments. So how does a heartbleed-type fix get rolled out? Just overwrite the existing cookbook? Iterate over the environments and update them with the new openssl cookbook?
I can see two ways Policyfiles might fit into The Customer's workflow (web-side, at least):
The operations team works on the "common substrate" cookbooks, and publishes these to some location (internal supermarket, SCM repo, etc.) from which the app teams consume them. App teams keep both the Policyfile.rb and Policyfile.lock.json in-repo. "Fix it now" updates, like a heartbleed, would be addressed by a Policyfile "patch" feature which would provide a "back door" to updating a single cookbook within an existing Policyfile lock JSON document.
Pros:
- Infrastructure builds are repeatable for any commit in the app's source repo. When a dependency (e.g., tomcat) is upgraded, that's reflected in the Policyfile.lock.json in the same source repo, so it's possible to correctly build the infra for the app both before and after the version bump in a repeatable way.
Cons:
- Updates to the "common substrate" roll out at the pace of application deployments.
In this workflow, the Operations team owns the Policyfile.lock.json.
Apps may include a Policyfile.rb, but the lock is excluded from source
control. When an app artifact is produced, ops produces the
Policyfile.lock.json (pulling in the common substrate) and keeps the
cookbooks, Policyfile.rb, and Policyfile.lock.json somewhere. Ops can
upgrade the common substrate by running chef update.
The exact mechanics of this approach need to be worked out.