[chef] Re: Re: Re: Re: application builds/ci involving Chef


Chronological Thread 
  • From: Sascha Bates < >
  • To:
  • Cc:
  • Subject: [chef] Re: Re: Re: Re: application builds/ci involving Chef
  • Date: Sun, 27 Jan 2013 10:23:59 -0600

Interesting that you say that about Noah.  My current client is looking at a service management model to deal with configuration files, eliminating Chef entirely from the mix. I have also discussed with a dev team shipping in config files from artifact repository and we did it with overrideable attributes, allowing someone else to use either a default template in the library cookbook or supply their own in another cookbook or drop a template on the server from elsewhere.  I guess my preference would be to eventually have the templates parametrized so that anyone could use the same template.

But then the question arises, how do you deal with changing data?  For this we have been using a combination of attributes and data bags. Chef solo would be a viable option for workstation testing, but they'd still have to check these things in and have build scripts that dealt with getting them into the Chef server/org.  We have a lot of this now and it's just not connected.

Maybe this is something that would actually work if you could get in front of the development and build process and hand a dev team a working CI process that involved Chef.  Lately I only get involved when it's too late to do anything besides panic.

Sascha Bates | "> | 612 850 0444 | | |
On 1/27/13 9:14 AM, John E. Vincent (lusis) wrote:
" type="cite">

One idea that EJ (your cohort on the podcast had) that I thought was brilliantly simple is to have the applications ship ERB templates for any conf files by default and let chef do its template magic with a local file instead of one in the repo.

The disconnect is always going to exist unless your dev team is willing to work with the chef repo. Frankly it's pretty unfair to ask that out id the gate and keeping the two in sync is painful.

The first motivation I had for the (sadly languishing) Noah was this exact use case.

On Jan 27, 2013 1:14 AM, "Sascha Bates" < "> > wrote:
>
> Thanks. I'm in an environment where we use jenkins and maven for a lot of this at the moment. There's also some Vagrant/vbox in the mix as well as Eclipse/STS. I'm not looking for pointers so much as being interested in what others have found to be successful.
>
> One of the problems I see is that Chef code and Application code are decoupled: different repos, different teams managing collections of cookbooks, diverse environments. Dev teams don't think of Chef as part of the code base and I believe that this has led to some dysfunctional attitudes and behaviors. At the moment I'm noodling on methodology for introducing a tool like Chef that decouples configuration code from application logic. 
>
> So I guess I'm maybe not looking for deployment solutions so much as wondering what people are doing to get their chef and app code working together and how it's working out for them.
>
>
>
>
> Sascha Bates | "> | 612 850 0444 | | |
> On 1/26/13 9:59 PM, Gourav Shah wrote:
>>
>>
>>
>>> Is anyone here doing application builds (either yourself or for devs) that involve any of the following:
>>>
>>> -Local (workstation) testing of a developed app with Chef housing configuration files
>>
>>
>> For local development with chef managing configs, you could try using vagrant + chef 
>>  
>>>
>>> -Application bundling with ant, maven, groovy, scripts, whatever that also includes parallel check-ins to Chef code?
>>> -CI testing of an application that builds an artifact but also has configurations in Chef?
>>
>> I have used Jenkins + chef.  You could also add capistrano in the mix for deployment. 
>>
>> Thanks
>> Gourav
>
>





Archive powered by MHonArc 2.6.16.

§