[chef] Re: Chef best practice for multiple developers

[Brad Knowles < >]

On Jan 13, 2014, at 8:28 AM, Ritesh Angural 
<
 >
 wrote:

> Great question & thanks for the informed reply Brad.
> 
> I've been pondering about this myself. My team is in the initial stages of 
> our Chef implenetation. We're currently a team of 15 developers.We have 
> staging & production environments for all our applications that directly 
> map to develop & master branches in their respective git repositories. We 
> also use Jenkins for integration & deployment across our services so a push 
> to develop or master triggers a deployment to our staging or production 
> servers.

Generally speaking, I would say that the bigger your development team, the 
more you're going to need standards that are automatically enforced, and you 
may need more tools to help you cover all the various different areas of 
concern.

But each tool you use is going to have a certain cost to it, and you will 
want to make sure that you balance that against the benefits that it provides.

> My question is how do we do a similar setup for Chef? Does it make sense to 
> have two different chef servers per environment? My initial guess would be 
> no because chef itself is used to manage the different environments.

Well, for one thing -- application developers are not necessarily system/chef 
developers.  So, you've presumably got a different community of people who 
would be your developers in this case.  Everyone else would be a "user" of 
the services provided by your system developers.

You could certainly have separate Chef servers for your application 
developers to interface with, and then an "air gap" to the Chef servers for 
the production network that is only touched by your most trusted and 
experienced systems developers.

> But, on the other hand it would be ideal to have git branches as the single 
> point of truth such that everything on master branch in the chef-repo is 
> the exact replica of what's on the chef-server.

That's basically what we're doing with several of our customers.  I think the 
issue is how do you get there, and what methods do you use along the way?

What gatekeepers do you have built into that process to try to help ensure 
that all of the code that makes it that far will actually do what you want, 
and that any code refactoring that might occur along the way doesn't 
introduce any new bugs.

Of course, those gatekeepers could be automated tools, but they could also be 
things that are done by humans.

> How are you guys doing it currently?

We start with git hooks for low-level syntax and style checking (e.g., knife 
cookbook test, foodcritic, rubocop, etc...).  We are in the process of 
creating spec tests for all of our cookbooks, as well as test kitchen 
definitions for running all the tests that can be run.

That's combined with proprietary tools to do automated discovery of what's 
defined on the Chef server versus what is in the git repo, automatic creation 
of Jenkins jobs to run all the appropriate tests, creation of a dashboard to 
show the current status of all jobs, etc....

But we don't do deployment of the whole multi-thousand node cluster that this 
is all designed to build.

We're a small system tools developer team, but we're supporting a much larger 
systems development/deployment team, and we're hoping that all of these tools 
and methods can help them get more work done better and faster, and with less 
pain in both the near term and in the long term.

--
Brad Knowles 
<
 >
LinkedIn Profile: <http://tinyurl.com/y8kpxu>