[chef] Re: Chef best practice for multiple developers

[Brad Knowles < >]

On Dec 27, 2013, at 7:50 AM, "Keckler, Ray" 
<
 >
 wrote:

> How do multiple developers make, update and recipes? 
> I know about cvs, git and all that but what it the best practice with Chef?

There are multiple facets to this question.

One has to do with the development of the code itself, and how you keep one 
developer from stepping on the toes of another one.  The answer to that 
question depends on a lot of factors, including the size of the team of 
developers you're working with, the methods that they tend to apply when 
developing code, and others.

For example, if it's a two-man team of highly skilled/talented Agile 
developers who know each other well and are very familiar with their chosen 
shared methods, then the answers are likely to be very different compared to 
a large group of disparate people who are not well-versed in a given method.

Speaking only for myself, I would recommend the use of git, in part because 
there are some workflow tools out there that can help you with this job, and 
they were developed assuming that you would be using git.  If you can host 
your cookbooks on github (maybe in private repos), then you can use the 
github standard methods of issue tracking, pull requests, etc....  That would 
also allow you to relatively easily keep a small number of long-running 
branches (maybe just "master" and "develop"), and then for each "chunk" of 
code functionality could be done in a feature branch that starts off life as 
a fork of one of these branches, and ends up being merged back in and then 
being deleted immediately thereafter.


Another facet has to do with how you test your code to make sure that it's 
working as desired.  Here, I think the recommendation would be to use a 
variety of tools, including "knife cookbook test" to do basic syntax checking 
before you upload a cookbook, the "foodcritic" code style checker, writing 
chefspec tests for each cookbook before you actually write the cookbook code 
itself (i.e., Test-Driven Development), Berkshelf to help you manage your 
dependencies on other cookbooks that you use but for which you don't want to 
maintain your own forks, and Test Kitchen to help you do integration testing 
on a vagrant-based VM on your local box before it gets put onto a separate VM 
or machine of its own.


You could also do some work to integrate these two facets, by using git 
commit hooks, so that no code is allowed to be committed to the repo unless 
it at least passes the basic syntax checking performed by "knife cookbook 
test" and basic code style checking as performed by foodcritic.  You might 
also want to set up a Continuous Integration or maybe even a Continuous 
Delivery system using tools like Jenkins and/or Travis-CI, so that you can 
build up a large library of automated tests at various levels that are run 
against your code on a regular basis, and that may go so far as to include 
automated deployment of code that passes all the tests.


There's lots of workflow tooling that is available, and you should check that 
out and see what makes sense in your environment.

The suggestions above are just a bunch of ideas thrown off the top of my 
head, based on work that my co-workers and I have done for some recent 
clients, and our ideas of what we think Best Practices are, and how we 
continue to tweak that concept as we do more development and we learn more 
about what works well for us in our environments.

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