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


Chronological Thread 
  • From: Bryan Berry < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: application builds/ci involving Chef
  • Date: Mon, 28 Jan 2013 21:16:54 +0100

tks Adam, this is quite helpful

On Mon, Jan 28, 2013 at 9:02 PM, Adam Jacob 
< >
 wrote:
> Essentially it's:
>
> * Gated trunk style repositories with code review by Gerrit
> * Hypothetical-master-merge testing for proposed code
> * Cookbook/data bag/role/etc changes get automatically uploaded and the
> development environment gets equality pinned
> * Development environments promote to a single integration environment
>
> If a repository in Gerrit has a chef-repo directory in it, the above takes
> place.
>
> We also have been doing application development and deployment in a
> similar workflow, that includes tracking build information in a data bag
> per application, that maps to a desired application version in an
> environment default attribute. This comes together in the deployment
> recipes to allow you to select the right deployment assets for an
> environment.
>
> Deployment beyond integration happens by taking the environment cookbook
> pins and the application revisions from the previous environment and
> setting the next environment to those values, then kicking off chef runs.
>
> Best,
> Adam
>
>
> On 1/28/13 11:44 AM, "Bryan Berry" 
> < >
>  wrote:
>
>>Adam,
>>
>>can you provide some more info on how you do this? do you use custom
>>git hooks + ruby script to update the data bag values ? Also, by
>>"promoting through with asset revisions" or you referring to promoting
>>cookbooks through environments or something else?
>>
>>On Mon, Jan 28, 2013 at 5:59 PM, Adam Jacob 
>>< >
>> wrote:
>>> I've been embedding the cookbooks/roles/data bags that are directly
>>>related
>>> to an application in the application repository itself, and using CI to
>>> update development environments (or organizations) at build time, then
>>> promoting through with asset revisions.
>>>
>>> Adam
>>>
>>> From: Sascha Bates 
>>> < >
>>> Reply-To: 
>>> " "
>>>  
>>> < >
>>> Date: Saturday, January 26, 2013 10:14 PM
>>> To: 
>>> " "
>>>  
>>> < >
>>> Cc: Gourav Shah 
>>> < >
>>> Subject: [chef] Re: Re: application builds/ci involving Chef
>>>
>>> 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.

§