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?
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?
Yes we do, no it is not. We combine it with other systems. It's near
trivial to manage any number of (free, non-free) release management
systems / continuous integration facilities / archive storage systems.
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
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).
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
Is that Artifactory LWRP public? We have been discussing writing one to
homogenize use across the org, but the devtools team backlog stretches
nigh to infinity. It may never happen.
Sascha Bates | sascha.bates@gmail.com | 612 850 0444 |
sascha.bates@skype | sascha_bates@yahoo |
On 10/17/12 1:54 AM, steve . wrote:
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).
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
Sorry, I'm afraid it's not public and the code belongs to my patrons.
However, you should know that it only took me about four hours to get
the LWRP working.
At the same time, it was the first LWRP I ever wrote. It could really
use a rewrite and full chefspec coverage before it sees the light of
day.
(Which is on my to-do list. Once that's done, I'll seek approval for
releasing the work to the community... )
Is that Artifactory LWRP public? We have been discussing writing one to
homogenize use across the org, but the devtools team backlog stretches nigh
to infinity. It may never happen.
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).
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
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?