The deploy resource is idempotent (like the rest of Chef)…you can target a
commit sha, branch, or tag and rest easy knowing your nodes will only update
their copy of the code when it has changed in the repo. If you don’t want
to update a data bag entry for every deploy (as mentioned by Brian), you
could also have a branch that is for production deployment only…a lot of
people use master for this.
Also be sure to take a look at the “application” cookbook:
It uses the deploy resource but also adds some extra logic on top including
a capistrano-style deployment structure. The goal of this cookbook is to
create a way to deploy applications that is completely data-driven vs being
hardcoded inside the cookbook.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: email@example.com
Twitter, IRC, Github: schisamo
On Thu, Oct 21, 2010 at 8:12 AM, Brian McKelvey firstname.lastname@example.org wrote:
I just reference a specific commit hash or tag name in the data bag. No
more unexpected deploys!
Sent from my iPhone
On Oct 21, 2010, at 3:34 AM, László Bácsi email@example.com wrote:
One thing I’m working on at the moment is to prevent the deploy_revision
resource from taking action when the chef client runs periodically. We
wouldn’t want to deploy every time there’s something pushed to the
repository. The trick I will use here is to check Chef::Config[:interval]
and/or Chef::Config[:daemonize] values in the deploy_revision resource to
decide on the action to take.