[chef] Re: Re: How do you use Chef for Release Management?

["steve ." < >]

I've set up a few of these now.  Jenkins/Bamboo deploys to
Artifactory/Nexus and uses orchestration (doesn't matter what it is,
but I really like Rundeck for this, especially with an awesome
chef-rundeck fork that builds project XMLs out of specific Chef search
queries!) to kick off Chef runs on the appropriate systems in the
appropriate order and run whatever deployment steps don't yet fit into
your Chef environment.

Final piece of the puzzle (for us) was an Artifactory/Nexus LWRP, so
you can declare "artifactory_file 'some-app.war'" in your app recipe
and have it notify all the deployment steps when a file matching its
search criteria (group/version/artifact/classifier search, particular
build number, etc.) changes and needs to be downloaded/deployed.

Oh yeah, and _don't forget to run tests on the deployed environment!_

As Thom says, the ability to continuously build, test and deploy an
artifact across all your environments is insignificant compared to the
power of interpersonal dynamics.  Make sure you're building a process
that's in the comfort zone of your target audience (release managers,
devs, business stakeholders).

On Tue, Oct 16, 2012 at 3:30 AM, Thom May 
<
 >
 wrote:
> On Mon, Oct 15, 2012 at 11:33 PM, Farzad FARID
> <
 >
>  wrote:
>> Hi,
>>
>> The use of Chef, or similar software like Puppet or Cfengine, for
>> Configuration Management is an undisputed choice (in my opinion of 
>> course!),
>> but what about Release Management?
>>
>> An IT facilities management company's architect tried to convince me that
>> tools like Chef are not adequate from handling software releases &
>> deployment (here I'm talking about Java/Tomcat applications) and that we
>> should use their costly proprietary platform instead...
>>
>> What is your opinion? Do you use Chef for Release Management, is it the
>> perfect tool in this field too?
>
> Perfect? no. as AJ says, it's a piece of the puzzle. My experience is that
> Release Management is far more tightly coupled to a company's process
> than CM, and you're much more likely to build something using off the shelf
> components (like Jenkins and Artifactory and Chef and probably an MQ)
> that will work for you than paying big dollar for a generic solution.
> -t