On Jan 13, 2014, at 8:28 AM, Ritesh Angural firstname.lastname@example.org 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 email@example.com
LinkedIn Profile: http://tinyurl.com/y8kpxu