[chef] Re: Re: Re: Re: version locking and roles

[< >]

I have to preface my answer with the statement that we are just rolling out
Chef and haven't had to live with this solution for any significant amount of
time, so I don't know how sustainable it is, but this is what we are doing.

Another preface is that in this context we are using Chef as a software
configuration management tool, not a system configuration management tool.

We have a number of cookbooks, databags and roles that are dependent on our
product version. Some releases of our code can create conflicting 
configuration
changes with prior releases. Environments have been a godsend in versioning
cookbooks, but we came up with our solution before 0.10 and it works for roles
as well. We call it "branching in name" or "versioning in name". For example a
role file can be called "product-apptier-vX" So with one release of code the
node has the role "product-apptier-v1" and when before we upgrade the code we
change its role to be "product-apptier-v2" and it will pick up the new
attribute, and other changes. Then, we can have some nodes running v1 and
others running v2 and they live happily side-by-side. Dev and QA can run the
newer version until you are ready to push it to production. (This also works
for databags)

Since we are using this for application configuration, we don't run Chef as a
daemon so all changes are prepared beforehand and chef-client is run in a
planned window. Yes, there is some manual step to change the roles as an
environment is upgraded. Since we have a fairly manual release process it is
not burdensome to us. I don't know what this would look like in a continuous
deployment shop.

Thoughts?

Dan