| Hey Mark,
In the mean time, I use multiple opscode platforms which is equivalent to multiple chef-servers for each 'environment'. I use a single cookbook git repo with qa/staging/production branches and promote cookbooks through the branches.
I also have my knife config determine what branch I'm on and configure the knife client to communicate with the corresponding server, setup correct keys, etc.
Alex
On Oct 19, 2010, at 12:11 PM, Charles Sullivan wrote: Mark,
I think the next major version of Chef will include the ability to have environments. This will probably help you roll things out like you're describing. You can track some of this work here: http://github.com/sdelano/chef/tree/environments
On Tue, Oct 19, 2010 at 12:30 PM, Mark J. Reed <
">
> wrote:
What techniques do you use for controlling the deployment of recipe
changes via Chef server? We're looking for a way to automate canary
deployments, rolling changes to first one, then a few, and then the
rest of the affected nodes.
New templates etc. can take advantage of file specificity (though it'd
be nice to have other options there for giving an arbitrary set of
nodes the same non-default file), but it's not much help if you have a
new version of the actual recipe code or a whole cookbook or a role.
One option is to give the new version a different name and shuffle run
lists around, then move it into place and shuffle back, but that can
be awkward to automate, especially if you're modifying something that
gets pulled in by other roles that depend on it.
You can copy cookbooks out and try them with chef-solo, but I don't
trust that to get the same results as a full chef-client run against
the server; it feels like more of a unit test than a deployment step.
We've thought about migrating nodes between two different Chef servers
(or two different Opscode Platform accounts), but that seems like an
awfully heavyweight solution.
Other ideas?
--
Mark J. Reed <
">
>
--
Charles Sullivan
">
|