[chef] Re: Re: Re: Re: Re: Re: Re: Re: Better workflow for actively-developed cookbooks

Chronological Thread 
  • From: Torben Knerr < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Better workflow for actively-developed cookbooks
  • Date: Sun, 24 Jun 2012 11:24:46 +0200

I'm using librarian-chef and wouldn't know how else I should manage my cookbook dependencies. It is great for resolving / downloading dependencies from various sources (community site, git, local path) if you treat them as "binaries" and I'm pretty happy with it.

But I'm also experiencing some friction when it comes to actively developing on cookbooks which I want to upload to chef server during my test / devlopment cycle. With librarian-chef I see only a few, all not ideal, alternatives:
 - do the full  `git add . && git commit -am 'foo' && git push origin master && librarian-chef update` cycle as mentioned by Bryan
 - do active development using a `:path` dependency, then when you have changes do the `librarian-chef update` cycle. When you are done testing do `git add . && git commit -am 'foo' && git push origin master` and switch to a `:git` dependency
 - do the changes directly in the $CHEF_REPO/cooksbooks directory (dangerous: don't do `librarian-chef update / install` or you will lose everything!!!), and when you are done testing replay the changes to your original cookbook source (might be suitable for tiny changes only)  

@Jamie: can you give us a quick comparison on the differences of librarian-chef and berkshelf? would berkshelf better support the scenario above?


On Sat, Jun 23, 2012 at 12:13 PM, Jamie Winsor < " target="_blank"> > wrote:
That's the piece that I mentioned earlier today. We'll make a better announcement once we've got the proper documentation and examples in place.

Jamie Winsor

On Saturday, June 23, 2012 at 3:06 AM, AJ Christensen wrote:

ohai, just saw this:


I don't quite understand your point.  Are you are saying that Librarian-chef
isn't meant to meet the particular use case I have described and should be
looking for a separate tool?

On Fri, Jun 22, 2012 at 11:44 PM, Jay Feldblum < " target="_blank"> > wrote:


The various rigorous practices that developers have are often
well-supported by their tools.

The same practices are not as well-supported by the devops tools because
these tools are still being built and because the ideas and practices are
still coming across. Devops as a field is still under construction.

In the meantime: you mix and match, you pick your battles, and you do what
you have to do.



alright, I have a pretty heterodox idea of how I would like to use
librarian-chef so that a team of infrastructure devs can work in sync

I am on a team of 3 infrastructure devs, i am the (relative) expert, the
other 2 guys are smart but n00bs

I want us to have one common Cheffile in our one common chef-repo

the cookbooks we develop independently each have their own git repo,
unfortunately, private ones for the most part

When I create a new git repository for application-foo, I want to add the
git repository link, branch name/tag/commit name, to Cheffile so that when
the other guys are working, they can easily pull in the cookbooks that I am
working on and vice versa

However, I dont want to do the `git add . && git commit -am 'foo' && git
push origin master && librarian-chef update`  dance when I am actively
working on a cookbook that is within an "active" cookbook.

I don't need librarian to resolve any dependencies for my active
cookbooks, I just want a common file w/ the list of all cookbooks we are
working on as a team and i want librarian to download them if they don't
exist already.

Perhaps this is a perversion of all things bundler but this is what I
want. It also would get much more complicated if we didn't have git repos w/
shared commit access.

Is this crazy or a good idea or both?

Archive powered by MHonArc 2.6.16.