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

[Torben Knerr < >]

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?

Cheers,

Torben

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

@resetexistence

https://github.com/reset

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

ohai, just saw this:

https://github.com/RiotGames/berkshelf

On 23 June 2012 20:45, Bryan Berry < " target="_blank"> > wrote:

Jay,

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:

Bryan,

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.

Cheers,

Jay

On Fri, Jun 22, 2012 at 5:28 PM, Bryan Berry < " target="_blank"> >

wrote:

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?