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,JayOn 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 syncI am on a team of 3 infrastructure devs, i am the (relative) expert, the other 2 guys are smart but n00bsI want us to have one common Cheffile in our one common chef-repothe cookbooks we develop independently each have their own git repo, unfortunately, private ones for the most partWhen 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 versaHowever, 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.