[chef] Re: What is the cookbook development workflow in your team?

[Zuhaib Siddique < >]

Peter,

Your idea sounds similar to what we at Oxygen Cloud use, which is changes 
made to Chef cookbooks and checked in to git and at the same time uploaded to 
our chef server (we have a small bash script that helps you do both at the 
same time, saves a lot of time).  At which time using Jenkins we would kick 
off an integration server to make sure it runs correctly and deploys our code 
correctly.  If that passes I manually bump the version and we call it stable 
till I make some changes/hack.  And then we have a script that kills all old 
servers and clear their Node/Client.

The thing I would like to do is is stop deploying servers for quicker Chef 
testing use Shef but from my short time testing the thing it seems only good 
for unit testing blocks of code but it wont help you do a full test of a 
cookbook or recipe.  If someone has some tips or guides on doing that I am 
very much open to it.  Also it seems Shef is not sandbox which mean changes 
it makes will apply to your system which is bad as you would need to run it 
in a VM which from my point of view more of a PITA then spinning up new 
servers and killing them.

Zuhaib
On Jan 5, 2012, at 1:32 PM, Peter Norton wrote:

> I'm interested in using chef+gerrit+jenkins to test new cookbooks in
> our environment.  I'm thinking of a workflow like this:
> 
> git checkin of a cookbook.
> 
> The cookbook will have an associated unit test suite that jenkins will
> run by deploying to a VM (probably an amazon EC2 t1.micro unless a
> particular architecture is needed).  The cookbook will be run and if
> it checks out, the version will be recorded as a candidate to become
> elevated to the next environment.  I'm thinking of:
> 
> sandbox (least reliable)
> dev (someone's at least looking at it, may get incorporated in
> integration tests)
> staging (will be used for pre-producting integration testing)
> production (the real thing)
> 
> My only question is how to inject version numbers into the metadata in
> a sane manner.  I can create/manipulate metadata.rb, but I can't see
> an easy and clean way to put basic assurances with the X.Y.Z
> versioning.
> 
> The closest I've gotten is something like this:
> 
> checkin foo with metadata.rb's version == 0.1.1.  All X.Y.Z releases
> where (X%2 == false) are submitted by the dev/user, so can never be
> part of dev, staging, or production.
> 
> When it's committed and pushed to the git/gerrit server a jenkins job
> is kicked off which uploads the new cookbook and launches a server
> with this cookbook version explicitly in the run list to verify that
> the job passes.  If it passes, then the jenkins server increments the
> metadata so that version = 0.2.1 (matching Z values) and commits that
> to a branch that doesn't require review.  That branch then gets
> uploaded to the chef server again, but now with the new version
> number.
> 
> When moving from unit test to integration tests (e.g. with
> cluster_chef/metachef, doing an entire environment or facet build)
> then the Y value will get incremented to 3, 4, or 5 as testing
> proceeds.
> 
> The thing I'm trying to solve is being able to use the same chef
> account for the life of the cookbook so that version X.Y.Z will always
> be the same if called in any environment.  The issue I'm having is
> that fencing off particular minor (Y) revision numbers seems to invite
> mis-understandings and casual mistakes.
> 
> Has anyone else dealt with this issue, or does anyone have a more
> enlightened way of looking at the problem?
> 
> -Peter
> 
> On Thu, Jan 5, 2012 at 2:15 PM, James Litton 
> <
 >
>  wrote:
>> The git repo clone on the host is not necessary. It could certainly be
>> done from a dev box or build server. Doing that from a build server
>> would make a lot of sense, actually. The reason has just been a matter
>> of convenience. We don't have to run multi-knife or a similar system
>> because dev boxes always push to dev, test to test and so on. This
>> also prevents an accidental push to prod in the case that someone
>> forgets to branch after push, etc.
>> 
>> versioning of cookbooks has been entirely haphazard(at best) with no
>> ill effects so far, but this approach has only been in place a month
>> or so. none of our cookbook depends specify version numbers. The
>> biggest problem with this approach has been that it makes it more
>> difficult to commit back to public cookbooks.
>> 
>> No, that situation has not come up. If it were to come up, we would
>> roll back to that point in the git repository not just the cookbook.
>> 
>> James
>> 
>> On Thu, Jan 5, 2012 at 1:12 AM, Torben Knerr 
>> <
 >
>>  wrote:
>>> Hi James,
>>> 
>>> thanks for sharing! Interesting to see the different approaches you can go
>>> for.
>>> 
>>> Few questions about your approach:
>>> 
>>> 1) as you describe you have a git repo clone of your chef repository on 
>>> each
>>> of your chef servers, then check out locally on the chef server and then
>>> knife upload to localhost if i understood correctly. Why do you need a git
>>> repo clone of your chef repository on the chef server? Wouldn't it be 
>>> enough
>>> to knife upload from an external box (e.g. developer's box, build server) 
>>> to
>>> either of your chef servers?
>>> 
>>> 2) as far as i understand your cookbook dependencies are versionless 
>>> during
>>> delevopment/upload/test/fix cycles and you always release the whole chef
>>> repo instead of single cookbooks. As soon as you do a release, does the
>>> script you mention update the Version number of all your cookbooks? Does 
>>> it
>>> at this point in time also add this version number to the cookbook depends
>>> statements (and remove it afterwards for the next dev/upload/test/fix
>>> cycle)?
>>> 
>>> 3) do you ever have the situation that you need to set up a node with an
>>> older cookbook version (e.g. for regression testing)?
>>> 
>>> Cheers,
>>> Torben
>>> 
>>> 
>>> On Thu, Jan 5, 2012 at 4:24 AM, James Litton 
>>> <
 >
>>>  wrote:
>>>> 
>>>> Torben,
>>>> 
>>>>  Thank you for bringing this up. I have also been puzzling about this
>>>> recently.
>>>> 
>>>> Right now the process that I am using involves 3 chef servers.
>>>> 
>>>> Development:
>>>> - Branch git
>>>> - Test/Deploy on Chef Solo (dedicated dev box with separate role in
>>>> prod chef server)
>>>> 
>>>> Test:
>>>> - Checkout branch on test chef server
>>>> - Push entire configuration (via shell script that I wrote)
>>>> - Force a chef-client run on a hosts in test by environment (Load
>>>> Test, staging, preview)
>>>> - Complete testing
>>>> 
>>>> Code Review
>>>> - Review the changes in the branch as well as the test cases
>>>> 
>>>> Prod (hosts developer environment and production hosts):
>>>> - Merge branch to master
>>>> - git pull on prod
>>>> - Push config via script
>>>> - Force chef-client run here only if required due to external requirement
>>>> 
>>>> The only issue really is the Test Chef server sharing, but testing can
>>>> generally be done quickly by maintaining smaller updates.
>>>> 
>>>> cookbook versions number changes aren't as important due to re-upload
>>>> of the cookbook with each push and splitting environments across chef
>>>> servers
>>>> 
>>>> The release process is not currently automated other than the script
>>>> that updates all roles, environments, data bags and cookbooks with
>>>> each release.
>>>> 
>>>> Generally the entire chef repository is treated as a version/release
>>>> in order to avoid version dependencies within each cycle.
>>>> 
>>>> I'd also love to hear what other people are doing.
>>>> 
>>>> James
>>>> PagerDuty
>>>> 
>>>> On Wed, Jan 4, 2012 at 11:58 AM, Torben Knerr 
>>>> <
 >
>>>>  wrote:
>>>>> Hi everybody,
>>>>> 
>>>>> Happy New Year! :-)
>>>>> 
>>>>> This is my first post to this mailing list. I'm trying to implement a
>>>>> proper
>>>>> workflow for developing cookbooks within a small team. Coming from a
>>>>> slightly different background (Java, Maven and the like) I'm looking for
>>>>> some experience on how to implement a typical develop/test/release cycle
>>>>> in
>>>>> a Chef environment.
>>>>> 
>>>>> So, assuming you are developing cookbooks in a team, how would you go
>>>>> for
>>>>> adding a new feature to a cookbook:
>>>>> 
>>>>>  (a) develop -> test (using Vagrant/Chef Solo) -> repeat
>>>>> develop/fix/test
>>>>> cycle until done -> upload to team's chef server
>>>>>  (b) develop -> test (upload to a private chef server) -> repeat
>>>>> develop/fix/test cycle until done -> upload to team's chef server
>>>>>  (c) develop -> test (upload directly to team's chef server) -> repeat
>>>>> develop/fix/test cycle until done
>>>>> 
>>>>> 
>>>>> I'm especially interested in:
>>>>> 
>>>>>  1) at which point in time do you share your sources (git push)?
>>>>>     - are you working on feature branches, then merge + push when done?
>>>>>     - when do you increase the cookbook version? in the commit where you
>>>>> merge back to master?
>>>>>     - when do you create the tag? everytime you commit something on
>>>>> master?
>>>>> 
>>>>>  2) at which point in time do you upload the cookbook to the team's chef
>>>>> server (knife upload)?
>>>>>     - whenever you want to test something?
>>>>>     - strictly only after creating a tag (i.e. releases only)?
>>>>>     - do you always freeze uploaded cookbooks?
>>>>>     - do you allow to overwrite cookbooks at all?
>>>>> 
>>>>>  3) how do you handle releases?
>>>>>     - is every upload to the chef repository automatically a (public?)
>>>>> release for you?
>>>>>     - do you have the release process (roughly: "run tests -> create tag
>>>>> ->
>>>>> upload cookbook") automated?
>>>>>     - how do you handle cookbook dependencies when you release? do you
>>>>> allow
>>>>> for versionless cookbook depends?
>>>>> 
>>>>> 
>>>>> Eager to hear your experiences. Any help is appreciated!
>>>>> 
>>>>> Cheers,
>>>>> Torben
>>> 
>>>